The Prototype That Earned a Build

01

The Prototype Is Not the Embarrassing Part

A pattern showed up often enough this year to be worth naming: an owner builds a working application themselves in one of the AI coding tools, puts it in front of real users, and then goes quiet about it — because somewhere along the way they picked up the idea that building it that way was cheating.

It is the opposite. Two years ago, finding out whether a piece of software would help your business meant a discovery engagement and a five-figure cheque before anyone typed a line. Building the thing and watching people use it tells you in a fortnight what a specification would have guessed at over a quarter. What that leaves you with is a prototype that earned a real build, and a much better brief than the buyer who is still trying to describe what they want.

The gap between a prototype and something a business can run on is real, but it is finite and it is specific: authorisation, a schema that can change safely, secrets out of the browser bundle, payments that survive a duplicate webhook, backups somebody has actually restored from, and enough tests to change things without gambling. That is a list, not a verdict.

02

Logging In Is Not the Same as Being Allowed

The single most common serious defect we find when reading an application somebody else built — generated, outsourced or inherited — is the same one, every time. Authentication works: users log in, sessions are real, passwords are hashed. And then the check that says this user may see this record is enforced on the screen rather than in the query.

It looks fine, because the interface only ever asks for the current user's data. It stays fine right up until a URL is edited, an export runs, a background job fires, or a report is written by someone who did not know about the rule. Then the wrong customer sees the wrong invoice, and there was never a moment where anything appeared to be broken.

If you have software running with other people's data in it, this is the one thing worth having someone check this month. It is a cheap question to ask and an expensive one to find out about from a customer.

03

Dashboards Fail by Volume

Almost every abandoned reporting project we have been asked to replace failed the same way. Somebody built forty charts, nobody could say which three mattered, so nobody opened it, and within a quarter it had quietly stopped being maintained.

The fix is not a better chart library. It is writing down the decision before building the view: what will someone actually do differently depending on this number? A number that will not change anyone's behaviour costs money to produce and attention to read, and the six that survive that question turn into a habit in a way that forty never will.

The same test works on the reports you already have. Whatever is in this month's pack that nobody acted on last month is a candidate for deletion, not for a redesign.

04

From the Build Log: Where Tenancy Actually Leaks

QuotingAI is our own product rather than a client engagement, which is why we can be specific about its internals. One codebase serving many contractors means every read and write has to be scoped to a tenant — and the interesting failure is never the obvious query on the main screen. It is the report, the export, the background job or the webhook handler, written weeks later by someone who was not thinking about tenancy at all, where a missing filter silently crosses a boundary.

Which is why it is enforced at the data layer rather than trusted to each caller. Pricing and customer data are the two things a contractor would never forgive us for mixing, and a rule that depends on every future developer remembering it is not a rule.

05

Worth Twenty Minutes

If you have never put a number on what administrative work costs your operation, the admin hours calculator does it with figures you already have. It is free, it does not ask for an email before showing you the result, and the output is usually larger than people expect.