Talk
A call about the problem and the people who live with it.
YouDescribe the problem and what good looks like
WeAsk awkward questions and give a rough range
CostFree
OutputA budget range and a yes or no
00 / How we work
How a DCM Studio project runs, from first call to handover
No spec, no start. It protects you more than it protects us. Here's every step, what you'll be asked to do and what you get at the end of it.
01 / The 4 steps
Each step ends with something you can hold us to.
Specify
We write down exactly what gets built, then price it.
YouReview the draft spec and answer questions
WeMap screens, data, integrations and risks
CostFree for most projects, [€ PRICE] for large ones
OutputA signed spec, a fixed price and dates
Build
Working software every week, on a private preview link.
You30 minutes a week to click through and comment
WeBuild with AI tools, review every change
CostAs quoted
OutputA finished, tested system
Hand over
Everything you need to run it without us.
YouBring the people who'll use it to training
WeLaunch, monitor and fix early issues
CostAs quoted
OutputCode, accounts, docs and training
02 / What a spec contains
A spec you could hand to another developer.
That's deliberate. If you could get it built elsewhere from our spec, our price has to be fair.
- 01
- The problem, in your words, and how we'll know it's solved
- 02
- Every user type and what each can see and do
- 03
- Every screen, with a rough sketch
- 04
- Integrations, with what data moves where
- 05
- What's deliberately left out
- 06
- Risks, assumptions and anything we're unsure of
- 07
- Fixed price, payment stages and dates
- 08
- Monthly running costs after launch
Why we insist on it
Most software disputes come from 2 people remembering a conversation differently. A spec ends that argument before it starts.
It also makes the quote honest. Every line of the price points at a line of the spec, so you can see what you're paying for and cut what you don't need.
03 / Changes and surprises
Things change. The price only changes when you agree.
03.1
Change requests
If you want something new mid-build, we write it up with a price and a revised date. Nothing changes until you approve it.
03.2
Small tweaks
Moving a button or rewording a label is part of the build. We'll tell you when something crosses the line into a change request.
03.3
Our mistakes
If something in the spec doesn't work as described, we fix it at no cost, during the build and for [X] days after launch.
03.4
Delays on your side
If we're waiting on content or decisions, the launch date moves by the same amount. We'll flag it as soon as it happens.
04 / After launch
Support from the engineer who built it.
04.1
Warranty
Bugs against the spec fixed free for [X] days after launch.
04.2
Support plans
Optional monthly plans with monitoring, updates and a stated response time of [X] hours. See plans
04.3
Going elsewhere
You own everything, and the documentation is written so another developer can pick it up. No exit fees, no hostage code.
Next step
Here's what it does, what it costs and when you'll have it.
Tell us what's slowing the business down. The engineer who'd build it will reply within 2 working days with a rough price range.