How We Actually Build

Most conversations about AI stay at the level of what it could do. Fewer get into how it actually gets built — and that's usually where the doubt creeps back in. If a business has been burned by a project that looked impressive in a demo and then quietly died before it ever touched real work, "we build custom AI tools" doesn't mean much on its own.

So this post is less about AI in the abstract and more about our actual process — the steps between a first conversation and a system a team relies on every day. Not because the process is secret. Because it's the part that actually determines whether something works.

It starts with a conversation, not a spec

We don't open with a questionnaire about "AI use cases." We open by asking what's actually slow, repetitive, or error-prone in the business right now. Most of the time, the person we're talking to hasn't thought of it as an "AI problem" at all — it's just the report that takes an afternoon every week, or the document review that eats a Friday, or the proposal that gets rebuilt from scratch each time because nobody trusts the template.

That's deliberate. AI applied to the wrong problem is just expensive software. The initial consultation exists to find the point where a real bottleneck meets something AI is actually good at — and to be honest when it doesn't.

The proof of concept: proving it, not performing it

This is the stage most agencies skip past, and it's the one we think matters most.

Our Proof of Concept engagements are fixed-price and deliberately narrow: one clearly defined business problem, built in weeks, not a discovery phase that drags on indefinitely. It starts with a structured session to map the current workflow and agree what success actually looks like — before a line of code gets written. A PoC that tries to solve five problems at once solves none of them well, so we hold that scope deliberately tight.

From there we design the simplest architecture that fits the business's existing stack. No unnecessary complexity, no black boxes — a client should always understand what the tool does and why it works, which is part of why we keep short feedback loops and regular check-ins running through the build rather than disappearing and reappearing with a finished product.

What comes out the other end is something real, not a slide deck: a document assistant that answers questions against a firm's own policies, an email triage tool that reads and routes enquiries, an intake agent that extracts information from a free-text submission and creates a structured record. Alongside it, a technical blueprint — how it's built, what it connects to, which models it uses — and an honest view of what happens next: scale it, refine it, or rule it out. If a PoC doesn't demonstrate clear value, that's useful information too, and considerably cheaper to learn at this stage than six months into a full build.

Production is a different job to a demo

A proof of concept proves an idea works. A production rollout is where most of the real engineering happens, and it's not a light touch on top of the prototype — it's a ground-up build that happens to start from a proven foundation. We think about it in four parts.

Infrastructure and deployment. The application moves out of its fragile local environment into a properly hosted setup — managed cloud, on-premise, or hybrid, depending on the client's data and compliance needs. That covers environment architecture, container configuration, secrets management, automated restarts, and deployment pipelines: the unglamorous work of making sure the application behaves reliably under real-world conditions rather than just on the day it was demoed.

Security and access. Proper authentication and authorisation, so only the right people can reach the tool and data is handled safely throughout. API keys secured, data flows documented, access role-appropriate — and for regulated industries, we help with the compliance conversations that need to happen internally.

Production monitoring. We instrument the application with structured logging so there's a clear record of what it's actually doing — inputs, outputs, errors, edge cases. This is the foundation that lets a team know when something isn't behaving as expected, rather than finding out from a client.

Training and handover. Often the most underestimated part of any rollout. We run structured sessions with the people who'll use the tool daily, write guides they'll actually keep and refer back to, and hand over full configuration and administration documentation. We don't consider the engagement finished until the team feels genuine ownership of it — not just access to it.

What happens after go-live

Going live is the beginning, not the end. Most clients move onto our Support & Maintenance retainer afterwards — a single monthly fee that covers proactive monitoring of the logs, small adjustments as usage reveals things nobody anticipated, and evaluating whether a newer model genuinely improves the application before ever upgrading it. Each month brings a short health-check summary: what's working, what's drifted, what would help most next. No ticket queue — if something doesn't feel right, a client tells us and we look at it.

That continuity matters more than it sounds. Document formats change, question patterns shift, staff move on — and having someone who already understands why the system was built the way it was avoids the kind of rushed, uninformed changes that quietly break things later.

We also license rather than hand over source and disappear. That's a deliberate choice: it means we stay accountable for what we've built, rather than shipping something and leaving a business to maintain a system they didn't design.

Why this matters more than the model you use

A lot of AI conversation right now centres on which model or platform is "best." It's a reasonable question, and it's also not really the one that determines whether a project succeeds. We've seen well-chosen models fail because nobody defined what correct output looked like. We've seen simpler systems succeed because someone was honest about the edge cases up front and built for them.

The model is a component. The process — scoping honestly, testing against real mess, building in the checkpoints that matter, staying around after launch — is what actually decides whether a business ends up with something it trusts, or with another tool that looked good in a meeting and never got used again.

That's the bit we care most about getting right. Not because it's the most exciting part of what we do, but because it's the part that actually earns the result.

Not magic. Just momentum.

Inzen