01. discovery.md
Discovery
One call. We map the problem, the users, the constraints, and what done looks like. By the end of the call we know whether we're a fit.
v2.0 — accepting fixed-price engagements for Q3
We write the spec,
We write the spec,
then we build it.
2–3 weeks.
Production software, delivered fixed-price. The spec is the contract. The build follows. No moving goalposts. No timesheet meetings.
~/specshop/build — bash
$ specshop build –status
reading config from ./engagement.toml…
model
spec_first
duration
2–3 weeks
price_floor
$5,000
scope_creep
0.0%
code_ownership
client
spec_is_contract
true
$
// 01 — how it works
Five stages. Two to three weeks. Fixed price.
Every engagement runs the same way. The spec is written before any code is committed. Once approved, it becomes the contract.
02. spec.md
Spec
We write the spec the way a senior engineer wishes a product team would. Problem, constraints, non-goals, user journeys, success criteria. You read it. You sign it.
03. build/
Build
Spec-first, AI-assisted, human-supervised. Every commit traces back to a clause in the spec. No scope creep — because there's nothing to creep into.
04. qa/
Verify
Three layers: automated unit and integration tests, AI-assisted end-to-end, and a senior engineer review against every clause in the spec.
05. ship.sh
Ship
Production deploy. Full source code, tests, documentation, and the spec — all transferred to you. No lock-in. You can hand it to another team the next day.
// 02 — the math
Spec-first delivery is faster. Measurably.
// scope changes
0%
Mid-build scope changes since we adopted spec-first delivery. The spec is the contract — anything new is a new spec.
// time to ship
2–3 wks
From signed spec to production. Not a sprint estimate. The fixed window we commit to in writing.
// price floor
$5k+
Fixed. Quoted before any work begins. The number on the spec is the number on the invoice.
// 03 — what you get
Production software. The whole thing.
Not a prototype. Not a demo with hardcoded data. The thing you can put in front of users on Monday.
- ◆ The signed spec — your contract and your reference
- ◆ Full source code, all rights transferred
- ◆ User journey maps for every flow
- ◆ Automated test suite (unit + integration)
- ◆ AI-assisted end-to-end tests
- ◆ Senior engineer code review sign-off
- ◆ Production deployment, configured and live
- ◆ Technical documentation written alongside the code
// 04 — fit check
Build is for some people. Not everyone.
// good fit
- Founders shipping a first version that needs to work, not just demo
- Operators who know the problem cold and need someone to render it in code
- Product owners who’d rather pay a fixed number than manage a sprint board
- Teams that want the spec they can hand to whoever maintains it next
- Anyone who’s been burned by an open-ended t&m engagement
// not a fit
- Discovery projects where you don’t yet know what you want
- Pure design exercises with no production target
- Long-running platforms with shifting requirements every sprint
- Engineering orgs that want to install the methodology themselves → see Transform
- Teams that need someone on payroll, not a delivery contract
// 05 — pricing
Fixed-price. Quoted upfront. No surprise lines.
The price comes out of the spec, not the timesheet. You see the number before you sign anything. The number on the spec is the number on the invoice.
from$5,000
// fixed. one number. no t&m.
// 06 — questions
Things people actually ask.
What does "spec-first" actually mean?
We write the full specification — problem, constraints, non-goals, user journeys, success criteria, technical approach — before writing code. You read it, push back, sign it. Once signed, the spec is the contract: every commit traces back to a clause in it. No scope creep, because there's nothing to creep into. If something genuinely needs to change, it's a new spec, not a re-negotiation.
Is this AI-generated code?
AI-assisted, not AI-unsupervised. Every line of code follows a spec we wrote with you. A senior engineer reviews and signs off before anything ships. Three layers of testing run before delivery. The difference between "vibe-coding" and what we do: we spend the first half of the engagement writing the spec before an agent writes a character. The spec is the product. The code is the output.
Who owns the code?
You do. Source code, tests, documentation, and the spec all transfer to you on delivery. No lock-in. You can hand the codebase to your own team or another studio the next day.
What if I want to change something mid-build?
Small things — copy edits, minor flow tweaks — get folded in without renegotiation. Anything that materially changes the spec is a new spec, with a new fixed price and timeline. We're transparent about which is which the moment it comes up. The reason the model works is that this rule isn't bent.
Why not buy training seats and have my team do this?
That's a different question — and a fair one. If you're an engineering org wanting to install spec-first delivery as your team's way of working, Build isn't the right offer. Transform is. Build is for founders and operators who want the software, not the methodology.
What if I'm not technical?
We write the spec. Your job is to explain the business problem and validate the journeys we design. You bring the domain expertise — we bring the engineering. If you can describe what your users need to do, we can map it.
Ready to see what it would actually cost?
30 minutes. We tell you whether it's a fit and the exact fixed price for your project. No deck. No pitch. Just the number.