What to expect from your first custom AI build

We've run enough first engagements to know what surprises people. Not the technical stuff — that's usually what clients worry about most and what causes them the least trouble. The surprises are almost always about process, communication, and the gap between what they imagined the software would do and what they actually need it to do.

This is a walkthrough of what a first engagement actually looks like. No euphemisms.

The discovery phase is doing more work than you think

The first two to four weeks aren't really about software. They're about developing a shared, precise understanding of the problem. This feels slow when you're eager to see something built, but it's the investment that makes everything afterwards go faster.

During discovery we're asking questions that might feel obvious — what does the current process look like step by step, what are the exceptions, who touches what data and when — because the answers are almost never what clients expect them to be. The process that exists in documentation is usually different from the process that happens in practice.

The output of discovery is a scoped roadmap. Prioritised opportunities, a proposed solution architecture, and fixed-price milestones for the build. If we can't produce that at the end of discovery, we tell you — and we don't proceed until it's resolved.

Your involvement doesn't end when the build starts

The biggest misconception about custom software is that you hand over a brief and come back when it's done. That's not how good software gets built.

During the build phase, we'll need you for: reviewing milestone deliverables and giving honest feedback, clarifying requirements as edge cases emerge, testing the software against real scenarios with real data, and making decisions when two reasonable approaches exist and the right one depends on your business context.

Plan for roughly two to four hours per week of your time during an active build. Less than that and the project drifts.

The first version will be incomplete

Not because we missed something — because that's how software works. The first version is designed to solve the core problem well. It will not cover every edge case. It will not have every feature on the wishlist. It will not be perfect.

What it will be is usable. Real users can operate it against real data and get value from it. That's the milestone that matters.

The features that didn't make it into version one are recorded and prioritised for the run phase. This isn't scope creep prevention — it's how you avoid building the wrong things and then having to undo them.

The handover is not the end

We don't have a handover moment. The run phase — ongoing management, iteration, and support — starts where the build ends. The software continues to improve. We stay close to how it's being used, what's working, and what needs to change.

This is different from most engagements you've probably had with software vendors. The accountability doesn't end at delivery. That's deliberate — it's what produces software that keeps working in the real world rather than deteriorating after six months.

What the first month of running feels like

Real users are messier than test users. They'll use the software in ways you didn't anticipate. Some of those ways will break things. Some will reveal that a feature you thought was essential isn't, and something you deprioritised is actually critical.

This is normal. The first month of running is a concentrated learning period. The software gets materially better during this time, and so does your team's confidence in using it.

First builds are rarely glamorous. They're iterative, uncertain, occasionally frustrating, and ultimately satisfying when they produce something that genuinely works. The clients who get the most out of them are the ones who come in with realistic expectations and a genuine willingness to be involved in the process.

That's the honest version of what to expect.