The data-services firm knew what the application had to do, but the detail lived in people's heads and no off-the-shelf product fitted the workflow. We delivered the scope first, written down, challenged in a workshop and signed. The software came second and matched the document.
The first call is free
The client is not named here, by agreement. Struan will not write a testimonial on a client's behalf, so there is no testimonial either. Ask on the call and we open the real work on a shared screen.
Everyone in the business could describe the workflow. Each person who ran the work held a piece, and the pieces had never been put next to each other. No off-the-shelf product fitted a workflow that specific.
The brief came by referral, on the strength of work we had already delivered. Before any software could be written, the scope had to exist on paper.
The client knew the scope and the named owner before the engagement started, and the scope did not move afterwards.
Every input, every output and every edge case came out of people's heads and onto paper, where the team could challenge each line. Most of the value of a bespoke build sits in the document. The document forces decisions early that the software would otherwise force late, when changing course costs more.
The scope was locked in the workshop. The client approved the final document before a single line was built, the same approval gate every Struan engagement gets.
We used what the library already covered and wrote the rest once. The new parts went into the library, so the next engagement starts from what this build proved.
We handed over working software with the documentation. The scope document that started the engagement doubles as the record of what got built.
Writing the scope down is most of the work. A disagreement caught on paper costs a conversation instead of a rebuild. The client gets a real approval gate before anything is built.
A bespoke build starts from the same 59-skill library as every AI employee, so the client pays for the parts that are genuinely new. When we improve a skill later, every client running the skill gains on the same day.
We run every bespoke build the same way: one document, one approval gate and one named owner.
The rules are the same on every bespoke build we run, and the client sees the rules before signing.
Changes go back through the document and get re-agreed in writing.
The client signed the scope before build began. Every bespoke engagement gets the same gate.
The scope is fixed and the owner is named. The client could follow the work from the workshop right through to handover.
We hand over working software and documentation. The client's data stayed the client's property throughout.
One document held the scope, and one named person owned the work. The software is in production and the document still describes exactly what is running.
now in production use, handed over with full documentation
named owner, accountable from workshop to handover
delineation document, doubling as the record of what got built
The first call is free