Parlour Dev

The challenge

The toughest client for a software house is… another software house. Parlour Dev delivers software for a living, so they know exactly what good work looks like - and won’t accept anything below their own standards.

Their earlier subcontracting jobs kept ending the same way: they received something that worked in a demo, but once the repository was open it turned out to be cheaper to rewrite it than to maintain it. The real cost of that isn’t just the contractor’s invoice - it’s weeks of your own team’s time spent rewriting.

So the bar was unambiguous: code ready to ship to production without a rewrite, with documentation their team could maintain on their own, without calling us.

What we built

Instead of handing over a “working prototype”, we delivered a production module:

1. Built into their architecture, not next to it - the agent plugs into Parlour Dev’s existing systems as another component of their stack, not a separate service with its own lifecycle and its own maintenance burden
2. Their conventions, not ours - code matching the standards Parlour Dev uses in their own projects; their team reads it the same way they read code they wrote themselves
3. Tests as part of the delivery - not an afterthought bolted on post-handover, but a condition for calling the module finished
4. A complete set of technical documentation - architecture, API reference and a maintenance guide: everything needed to take the module over without us

How it went

Rather than one big handover at the end, we agreed the acceptance standards up front - conventions, test scope and documentation scope. That way handover wasn’t a negotiation over “is this good enough”, but a check against a list set on day one.

The deployment itself was done by the Parlour Dev team. That was a deliberate test: if the module is genuinely ready, the client ships it without us.

Results

The module went to production on handover day - no stabilisation period, no fix requests. Parlour Dev’s team needed us neither during the deployment nor after it.

For us that’s the hardest proof there is: a Basalt AI agent isn’t a demo to show in a meeting, it’s code that passes review with people who do this professionally.

What this means for you

If you have your own engineering team, the key question about an AI vendor isn’t “will it work” - it’s “will we be maintaining this ourselves afterwards”. Acceptance standards - conventions, tests, documentation scope - are worth agreeing before the first line of code, not at handover. That’s the only moment when you still have leverage over what you’ll receive.