Hand your developer a brief they can actually quote
You know what your business needs. We turn that into process maps, user stories with acceptance criteria and a product requirements document, so a developer or vendor can price the work and build the right thing first time.
You know the problem. The brief is the hard part.
You've been quoted three wildly different prices
Three developers, three numbers, and none of them are quoting the same thing, because each one filled the gaps differently. A written brief makes the quotes comparable.
The spreadsheet has stopped coping
Scheduling, approvals, stock, audits: something that lives in a spreadsheet and three people's heads now needs to become a system. Nobody has written down how the work actually flows today.
You're not sure you should build at all
There might be a product on the market that already does 80% of this. You want someone to check before you pay for custom software, and to tell you plainly if buying beats building.
A brief that survives contact with a developer
Everything below is written in plain language first, with the technical detail underneath. You should recognise your own business in all of it.
A half-day session with you and the people who do the work. We walk through what happens today, what goes wrong, and what "done" would look like. Notes come back to you within two days.
Two diagrams. The first shows how the work runs now, including the workarounds nobody admits to. The second shows how it should run once the system exists. The gap between them is the scope.
Each piece of the system written as a short story: who needs it, what they need, why. Under each one, a checklist of what has to be true for it to count as finished. Stories are ranked Must, Should, Could or Won't (MoSCoW), so the first release stays small.
A PRD is the single document a developer builds from: goals, users, the stories above, the rules the system must never break, and what's out of scope. Yours will be short enough to read in one sitting.
When an off-the-shelf tool covers most of what you need, we say so. You get a shortlist scored against your own stories, a recommendation, and a note on what you'd give up by buying instead of building.
We walk your chosen developer or vendor through the brief on a call, answer their questions, and stay available while they quote. Fewer assumptions means a tighter price.
Workshop to signed-off brief in about two weeks
A build brief typically takes two weeks, run as a research sprint. You'll spend roughly one working day of your own time across the whole thing, mostly in the workshop and the review.
Workshop
You, us, and the two or three people closest to the work. We map how things run today, list every pain point, and agree what a good outcome looks like. If a rule exists in a contract or an agreement, we ask to see it rather than guess.
Process mapping
We draw the as-is and to-be maps and send them back for a correction pass. This is where most surprises appear: a step nobody mentioned, an approval that happens by text message, a report that three people produce separately.
Stories and priorities
Every requirement becomes a user story with acceptance criteria. We rank them together using MoSCoW so the first version covers the Musts and nothing else. Scrutas ended up with 23 modules, all of which were ranked before a line of code was written.
Build or buy check
Before we write the PRD, we look at whether an existing product covers the Musts. If it does, the brief becomes a vendor selection instead. Either way you get a written recommendation.
PRD and handover
You get the finished document, a review call to sign it off, and a briefing call with your developer or vendor. If you'd like us to stay on while it gets built, that's our product ownership service.
Scrutas: from workshop to a 23-module audit tool
Scrutas, an internal audit platform, began with a requirements workshop and as-is / to-be process mapping. The hard problem turned out to be legal rather than technical, and the brief captured it as a two-stage authorization flow before any code existed. ShiftFlow ran the same way: its scheduling and break rules were encoded straight from the union agreement, clause by clause.
Read the Scrutas case study →Straight answers before you book
Do I need to know anything technical?
No. You need to know your business and be willing to show us how the work really happens, workarounds included. We handle the translation into stories, criteria and a PRD. If a developer later uses a term you don't recognise, ask us and we'll explain it.
What if you find we shouldn't build anything?
Then we tell you, in writing, with the reasoning. Sometimes an existing product covers the Musts and the honest advice is to buy it and configure it. The brief becomes a vendor shortlist and selection instead, and you've spent two weeks rather than six months finding out.
Can my existing developer work from this?
Yes, that's the point. The PRD and user stories are written in the format developers already expect, and we brief them directly. Most developers are relieved to get one; it means fewer change requests and fewer arguments about what was agreed. Read more on writing user stories with acceptance criteria.
How much of my time does it take?
Plan for the half-day workshop, an hour reviewing the process maps, and an hour on the sign-off call. Around one working day in total, spread across two weeks. The people who do the work day to day should join the workshop; their knowledge is usually where the real requirements live.
Will you build it too?
We can build a clickable prototype to test the brief with real users before a developer starts, and we can act as your product owner while the developer builds. Production code for client work is done by your developer or vendor, working from the brief. Pricing for any of it is quoted after a call.
Tell us what your business needs to do that it can't do today. In 30 minutes we'll say whether a build brief is the right next step, and what it would cover.