What "built properly" means

AI coding tools have changed how software gets made. Describe what you want, and in minutes you have a working screen, an API, even a deployed app. People call it “vibe coding”, and for exploring an idea it’s brilliant. We use AI coding agents every day, and we wouldn’t go back.

But a prototype that works on a Tuesday afternoon isn’t the same thing as a product people can rely on. The gap between the two is where most of the real work lives, and it’s the part AI can’t decide for you. That’s what we mean when we say we build things properly.

Speed is no longer the hard part

For most of software history, the bottleneck was typing: turning a design into thousands of lines of working code. AI has largely removed that bottleneck. A small team can now produce in a week what used to take a whole department a quarter.

When building gets cheap, the expensive mistakes move elsewhere. They move into decisions: what to build, how data is protected, how a change reaches customers, and what happens when something breaks at 2am. Those decisions don’t come from a prompt. They come from having seen things go wrong before.

Adrian, our founder, has 35 years in software: 25 years hands-on as a developer and architect, and more than 10 years managing software projects and delivery teams, across a wide range of industries. That experience is the guide rail we put around the AI’s speed.

Vibe coding on its own

Left to itself, an AI-built project tends to drift in predictable ways:

• The prompt becomes the spec. Requirements change every session, and nobody can say what “done” looks like.
• There’s one environment, and it’s production. Every experiment happens in front of real users.
• Secrets end up in the code. API keys get committed, and every user can quietly query every row.
• Testing means “it worked when I tried it”. Fixes break other things, and progress slows to a crawl.
• AI spend is discovered on the monthly bill.

None of this is the AI’s fault. It does exactly what it’s asked. The trouble is that nobody asked it the right questions.

The right amount of control

The answer isn’t to bury a project in process. Big-company bureaucracy would throw away the very speed that makes AI worth using. What we aim for is right-sized control: the handful of practices that prevent the expensive failures, applied from day one when they’re cheap.

Requirements before code. Every product starts with a short, plain-English product requirements document. Features become numbered PRDs with clear acceptance criteria. That gives the AI a precise brief and gives clients something they can read and check.

Small, shippable increments. We ship in small slices, each of which leaves the product working, to a live dev environment you can click through.

Separate environments, defined as code. Dev and production are separate and described in infrastructure-as-code, so they’re repeatable and easy to rebuild. Nothing reaches customers untested.

Gated, password-free deployments. Pipelines build, test and deploy every change, sign in to the cloud with short-lived tokens rather than stored passwords, and wait for a human approval before production.

Security in the foundations. Proper sign-in, secrets in a key vault, and data isolation enforced by the database itself, not just the app.

Tests with evidence. Automated smoke tests run against real deployments and keep screenshots and results, so “it works” is something you can see.

AI with a person in charge. Expensive AI steps show a cost estimate and wait for approval. AI does the heavy lifting, and people make the decisions that matter.

Observable and auditable

Two more practices come straight from enterprise best practice. For production systems, we design in monitoring, for example with Azure Application Insights, so problems surface before customers notice them. We also design in an audit trail of important actions such as approvals, spending and admin changes, so you can always answer “who did what, and when?”

They’re easy to skip on a prototype and painful to bolt on later, which is exactly why they belong in the plan from the start.

Why it matters to you

Building properly doesn’t make projects slower. It makes them steadily fast. You get working software early and often, requirements in writing, a codebase and cloud account you own, and AI costs you can see before you spend them. Most of all, you get software that keeps working after the demo.

AI has made building fast. Experience is what makes it last.

If you’ve got an idea, or a prototype that’s started to creak, tell us what you’re working on. We’ll tell you honestly what it takes to build it well. And if you’d like the detail, our Built properly page sets out the whole approach.

— Adrian