What's the difference between a blueprint and a spec?

A spec lists features. A blueprint explains the system: how data is structured, why those structures, what breaks at scale, what each decision costs you later. A spec tells a developer what to build. A blueprint tells you what you're buying.

Can I use this to get quotes from other developers?

Yes, that's the point. It's written to be handed over.

What if I decide to build it in-house?

Then you have a document your team can work from on day one instead of spending their first month discovering it.

Do you review existing quotes or proposals?

Yes. Send me what you've got and I'll tell you what's missing, what's padded, and what's a red flag. It's the fastest version of this engagement.

./i-need-a-blueprint

You need to know what you're buying before you buy it.

You're about to spend a lot of money on development. Maybe you've got quotes from three agencies and they're €20k apart, and you can't tell why. Maybe you've got budget approved and a deadline, and the only thing missing is a clear description of the thing itself.

This is the cheapest possible moment to get it right. Every ambiguity you leave in the brief becomes a change request later, at ten times the price.

This is you if

You have three quotes with wildly different numbers and no way to compare them
You have budget but no technical person to sanity-check what you're being sold
You're hiring your first developer and don't know what to ask for
An agency handed you a proposal full of words you'd have to Google
You want to build in-house but nobody has mapped the system yet

How it works

1. Discovery. Two to three sessions. I learn the business, not just the feature list — what makes money, what has to scale, what's actually fixed versus what everyone assumes is fixed.
2. I write the blueprint. A document that covers: the data model, system architecture, third-party services and what they'll cost monthly, the build sequence in phases, the risks nobody mentioned, and a scope boundary that says explicitly what is out.
3. We walk through it. You need to be able to defend every decision in it to a developer who pushes back. So we go through it until you can.

What you get

A document you own and can hand to anyone. Use it to brief an agency, to compare quotes on equal terms, to onboard your first hire, or to build it yourself. It's vendor-neutral — nothing in it assumes I'm the one who builds it.

Why this saves money

A quote against a vague brief is priced for risk. The agency doesn't know what you'll ask for in month three, so they pad. A quote against a precise blueprint is priced for work. In my experience the blueprint pays for itself in the delta between those two numbers, before a single line of code is written.

Timeline

One to two weeks.

FAQ

What's the difference between a blueprint and a spec?: A spec lists features. A blueprint explains the system: how data is structured, why those structures, what breaks at scale, what each decision costs you later. A spec tells a developer what to build. A blueprint tells you what you're buying.
Can I use this to get quotes from other developers?: Yes, that's the point. It's written to be handed over.
What if I decide to build it in-house?: Then you have a document your team can work from on day one instead of spending their first month discovering it.
Do you review existing quotes or proposals?: Yes. Send me what you've got and I'll tell you what's missing, what's padded, and what's a red flag. It's the fastest version of this engagement.