Software that runs isn’t the same as software you can trust.
Viya’s own people build the software the business runs on. Someone who knows exactly how a rebar schedule is calculated, or how a punch list moves between an architect and a contractor, can build the software for it directly.
From the outside, the software looked finished. People logged in and the screens loaded. What you couldn’t see was whether one customer’s data could reach another’s, whether a former employee’s access really ended, or whether something the screen said was saved had actually been saved.
Two projects and two ongoing services.
Review and raise the standard
Check everything already built, rank whatever could stop it running as a real business system, and explain the cause and the fix for each. The first review is the starting point. After that, it’s a weekly check.
Build two new modules
Payroll, and a rebar schedule tool with paid access per project, approval for offline payments, and export. Built to the standard from the first line, not fixed afterward.
Move to company-owned hosting
Code and hosting moved off personal accounts and outside platforms onto accounts the business owns, with access that doesn’t depend on any one person.
Rules and support
Turn repeat problems into rules that reach the team while they build, and be on call for decisions that are expensive to get wrong.
“An app” turned out to be several: one platform serving staff, homeowners, contractors and architects; an admin app split out with its own logins; and the two new modules we built. Working out the real size of the job is always the first step.
They build. We hold the standard.
A six-step loop, every week. The step that matters most is the last one.
- 1Build:The team builds on its own priorities. For payments, logins or sensitive data, they check the approach with us first.Who: Viya, with us on call.
- 2Review:Everything new is checked for security, customer separation, correctness, tests and release setup.Who: us, weekly.
- 3Report:Same day, same format. Each finding with how serious it is, why it happened, what it risks and how to fix it.Who: us.
- 4Clarify:Questions on the report get answered, so nobody starts fixing from a misunderstanding.Who: both.
- 5Fix:The team fixes things in the order the report sets. The next review checks the actual fix, not a note saying it’s done.Who: Viya.
- 6Lock it in:Anything that showed up twice gets an automatic check. This is the step that makes each week cheaper.Who: us.
Between reviews
We’re on call for the decisions that are expensive to get wrong. A review can’t help with these, because it comes afterward. The AI tool offers several designs with the same confidence, and picking the safe one takes experience.
For a builder without an engineering background, this is where they’re most on their own. It’s also the cheapest hour in the whole arrangement.
- How to handle a payment that only half goes through, and refunds
- Access rules for four kinds of user, decided before the data structure sets
- Data imports and deletions that can’t safely run twice
- Three reasonable-looking designs, one of which ages badly
A fix lands where it was found. The next new feature doesn’t get it.
One pattern showed up so often it’s closer to a law. A problem gets found and properly fixed. Then something new is built, like a new type of user or a second data importer, and the same problem is there, untouched. In the third review, eight of the twelve new findings were exactly this.
The fixes got much better. Carrying each fix to every place it belonged did not, because that depended on memory. This is how AI-assisted building fails: not randomly, but predictably, on whatever was built last.
It’s also why rules the computer enforces held every single time, and rules that relied on memory held only until the week got busy.
Two reviews, five days apart. Both were right.
The weekly review asks whether the code is safe, separated and tested. It doesn’t ask whether a feature does what its screen says.
Medium-to-low risk
No high-risk findings. The best result so far.
48 findings, 16 that should have stopped a release
Including a drawing upload that said “success” and never sent the file anywhere.
Both were true because they measured different things. Finding that out was the most useful result of the work so far. It changed what we check, not just how often. We now check both.
The rules went in eleven days before the first review.
Five roles. One of them sets the pace.
We list roles, not names, because the setup is what you can copy.
Findings arrive faster than one person can fix them. Knowing that early is better than finding out in month three.
4 applications, now under regular review.
Every result below was confirmed by checking the actual code, not by taking a note’s word for it.
The work isn’t finished.
Findings are still being worked through, including the feature problems from the late check. The first phase was a floor, not a finish line.
They still build. We never took over.
The know-how stayed inside the company, the team kept shipping at its own pace, and now someone can say, with evidence, whether it’s safe to run the business on.
Two other projects, same company.
ProjectSignal for Viya
The project management platform the business now runs on.
Bleno for Viya
14 workflows that carry the work that used to wait for a few senior people.