The Blueprint
An idea is not a specification.
Four weeks on a single initiative. We take an idea that lives in your head and turn it into documentation a development team can execute from, including the architecture, the integration map, the threat model and a budget that survives contact with a CFO.
- Time
- 4 weeks
- Terms
- Fixed price, quoted up frontHalf credited against The Build
The deliverable
What lands in your inbox.
What lands in your inbox at the end. Roughly sixty pages, written so a developer can start without asking us anything.
Contents
- 01As-isHow it runs today, including the dependencies nobody wrote down.pp. 8 to 12
- 02To-beThe future state. What the agent decides, what a human still signs.pp. 6 to 10
- 03ArchitectureEvery system, API, auth model and rate limit. Where legacy will fight us.pp. 10 to 14
- 04Threat modelWhat leaves your tenancy, what injection could reach, what needs a gate.pp. 5 to 8
- 05RequirementsUser stories with acceptance criteria. Build-ready.pp. 12 to 20
- 06Plan and budgetPhases, dependencies, build cost, running cost, and the assumptions behind both.pp. 6 to 9
Included
Everything you keep.
- 01
As-is documentation
How the process, systems and data actually work today, including the dependencies nobody wrote down and the two people who know the workaround.
- 02
The to-be solution design
What it looks like afterwards: the capabilities, the screens, the data flows, what the agent is allowed to decide and what a human still signs.
- 03
Technical architecture and integration map
Every system it touches, every API, every auth model, every rate limit. Where the legacy system will fight us, and what we will do about it.
- 04
Threat model and data-flow review
What leaves your tenancy, what a prompt injection could reach, which tool calls need a human gate, and how it is logged. Written by the person who would build it, not a checklist.
- 05
Build-ready requirements
Functional requirements as user stories with acceptance criteria, written so a developer can pick one up without asking us a question.
- 06
Milestone plan and resource estimate
Phases, sequence, dependencies, and who is needed when, including the time your own team has to find.
- 07
Budget and ROI
A build cost, a running cost, and the annual saving, each with the assumption behind it written down so you can challenge the arithmetic.
Do this if
- You have a specific system or product in mind and executive backing for it
- You need a number you can defend to a board or an investor
- You are building a new line of business, not shaving time off an existing one
- You have developers and they need a spec, not a pitch
Do not, if
- You want quick wins, in which case The Survey is the cheaper front door
- The idea is still moving weekly and nobody owns it
- You are automating something under a few hundred hours a year
The Blueprint / questions
What people actually ask.
How is this different from The Survey?
The Survey goes wide across your operation to find what is worth doing. The Blueprint goes deep on one thing you have already chosen. If you do not yet know which thing, start with the Survey.
Can our own developers build from it?
Yes, and it is written for that. The requirements, architecture and acceptance criteria are vendor-agnostic on purpose. Plenty of clients take the Blueprint in-house, and some come back for the hard part only.
Does the fee credit against the build?
Half of it does, against The Build, for 90 days. Less than the Survey, because the Blueprint is a substantial deliverable in its own right rather than a qualification step.
What does your team still do by hand?
Thirty minutes. No deck. Sometimes the answer is that you do not need us, and that is a short call.
Book thirty minutes3 engagements at a time