Turn Your Idea Into
a Build-Ready Spec
You've run the business for years and you can describe it perfectly out loud. Nobody has ever asked you to write it down the way a developer needs it. We do that with you, in plain English, and the document belongs to you.
45%
OF BUILT FEATURES ARE NEVER USED
37%
NAME REQUIREMENTS AS THE MAIN CAUSE OF FAILURE
3%
SUCCESS RATE FOR LARGE WATERFALL PROJECTS
Nobody teaches you how to brief a developer
You can explain your business to a new member of staff in twenty minutes and they'll get it, because people fill gaps automatically. Software doesn't. It needs the gap filled in advance, by you, in writing.
So the conversation with a developer goes well until the question arrives that you've never had to answer. If a client pays half up front and cancels, is that one job or two on the system. You know what should happen commercially. You've never had to decide what the software remembers about it.
There are usually about a dozen of them. Answering them before anyone starts is what stops the build being rewritten six months in.
WHAT YOU CAN ALREADY DESCRIBE
- How the business actually makes money
- Which part of the week wastes the most time
- What customers ring up complaining about
- The exceptions everyone in the trade knows
- Why the last piece of software was dropped
WHAT NOBODY HAS ASKED YOU
- Can two people edit the same job at once
- What a part-paid, cancelled order becomes
- Who may change a price after approval
- What staff see after someone leaves
- Which of these you'd launch without
What's actually inside it
Five parts. A developer reads it and knows what to build. You read it and recognise your own business, because it's written in your words rather than ours.
Jobs, with a way to check them
Each thing a person needs to do, written as a sentence, with the test that proves it was built properly. No arguments later about whether it's finished.
What the system remembers
Every record it keeps, in plain English, and how they hang together. A job has a customer, a customer has many sites, a site has one live contract.
Every screen, including the ugly ones
The list of screens, plus what each shows on day one when it's empty, when something fails, and when the person looking isn't allowed to see it.
Who's allowed to do what
A grid of roles against actions. Who approves, who only views, who can change a figure after it's been signed off, and what gets recorded when they do.
What you're leaving out
The cut list, with reasons. This is the section that keeps the first build small enough to finish, and the one most specifications never include.
Four steps, no technical vocabulary
No technical vocabulary required at any point. If we use a word you don't recognise, that's our mistake and we'll swap it for a better one.
Alex co-founded and built AccountancyManager before its sale to Hg-backed Bright, so most of these questions come from having got them wrong the expensive way first.
BOOK A SPEC CALLExplain it like you would to a new starter
Two hours, no preparation, no slides. Walk us through the job the way you'd train someone on their first week. We record it, and the recording does the remembering.
We come back with the questions
Usually thirty or forty, mostly about edge cases and money. Some you'll answer instantly. A few will take a phone call to your accountant or a look at last year's exceptions, and those are the valuable ones.
A draft you can actually read
Written in the language you use for the business. You mark up what we've misunderstood, and we're normally wrong about two or three things, which is why this step exists.
Priced, sequenced, handed over
The final document, a build order that puts the risky work first, and a price per phase. Yours to keep, quote against, or put in front of a board.
Take it to whoever you like
The specification is yours the moment it's paid for. Get three quotes against it, or sit on it for a year until the timing and the cash flow suit.
We write it that way on purpose. A document only its author can interpret is a way of keeping a client, and it produces worse software, because nobody else can sanity check it.
WHAT YOU WALK AWAY WITH
- The written specification, in a format you can edit
- A build sequence, riskiest work first
- A price per phase you can put to three suppliers
- The decisions log, so you know why each call was made
- No obligation to use us for a single line of it
The case for a short first build
The research on wasted build effort is old and the samples are thin, but it points the same way each time. We've noted where each one is weak.
Nearly two thirds go unused.
Jim Johnson of the Standish Group reported that 45% of features in the products studied were never used and a further 19% were rarely used. The figure is widely quoted and worth treating carefully: it came from four internal applications.
Success rates fall sharply with size.
CHAOS 2015 put the success rate of small projects at 58% under agile methods, against 18% for large agile projects and 3% for large waterfall ones. Standish grades projects on its own criteria, which academics have challenged, but the gap by size is hard to argue with.
Requirements, named by the people running it.
In the Project Management Institute's Pulse of the Profession research, 37% of organisations named inaccurate requirements as the primary cause of project failure. Self-reported by project professionals rather than measured independently.
Sources: Standish Group (Jim Johnson, XP2002), Standish Group CHAOS 2015, Project Management Institute Pulse of the Profession.
Our own ventures started as somebody else's expertise
RiskMapped began with financial-advice expertise. BuildManager is being developed with experienced construction and quantity-surveying partners. In both cases the useful product boundary came from writing down how they already worked.
When this is worth discussing
We work best when there is a real operating problem, enough volume to measure and people from the affected teams who can make decisions.
Usually a good fit
- An established UK business, usually with annual revenue above £10m
- A repeated process with a known cost, delay, error rate or capacity problem
- A senior sponsor and a day-to-day owner who understand the work
- Access to the relevant staff, systems, sample records and security requirements
We may point you elsewhere
- A standard product already covers the process well
- The requirement is a one-off small build with no wider operating case
- There is no owner or access to the people and data needed to test the result
- The plan relies on AI making high-impact decisions with nobody responsible for review
Questions we get from owners
I don't know exactly what I want yet.
That's the normal starting point and it's fine. You need to know the problem, not the solution. If you can describe the part of the week that wastes your time and who it affects, there's enough to work with.
I asked ChatGPT for a spec and got twelve pages.
Bring it, we'll read it. Those drafts are usually strong on structure and weak on your business, because the model can't ring your operations manager to find out what happens on a part-paid cancellation. It invents a plausible answer instead, and you find out it was wrong once the code exists. We use the same tools every day. The questions are the work.
Will I understand the document?
You have to, or it isn't finished. You sign off every section, and if a page needs us in the room to explain it, we've written it badly and we'll rewrite it.
Can I use it to get board or investor approval?
It's built for that. A costed, sequenced document with the assumptions written down answers most of what a board asks, and it shows the request came from work rather than enthusiasm. Tell us up front if it's going to a committee and we'll add a summary page for it.
How long, and what does it cost?
Two to three weeks for most single-workflow ideas, and a fixed fee agreed before we start. If you go on to build with us it comes off the first phase. If you don't, you've still got the document.
What if my mind changes once it's being built?
It will, and that's normal. The specification's job is to make the cost of a change visible before you agree to it. When you ask for something new, you can see which phase it lands in and what it displaces, then decide with the number in front of you.
I have a whole project, not just an idea.
Then you want the fuller engagement, which covers multiple workflows, existing systems and integrations. That's how our discovery and scoping phase runs.
Describe it to us out loud
Half an hour on the phone, no preparation. Tell us the job you want the software to do and we'll tell you whether it's a two-week specification, something smaller, or an idea that needs more shape first.