Blog
Blueprint: how we design before we build
A good technical drawing saves weeks of work. Software behaves like a building site in one respect: moving a line on the drawing is cheap, moving a wall is not. So before the first line of code, we draw. System boundaries, data flows, integration points, and a written list of what we are deliberately not building in version one.
What does a custom software project actually look like?
Four stages. A technical call of 60 to 90 minutes. The blueprint: a drawing of the solution plus a clickable prototype. Construction in two-week slices, each ending in something you can click. Then deployment and maintenance. The blueprint usually takes a few days to two weeks, depending on the number of integrations.
Each stage closes one class of unknowns before we spend money on it. The call answers "which problem are we really solving". The blueprint answers "where will this break".
What gets produced before any code is written?
Six things: system boundaries, a data model, flows, integration points, a risk register, and the list of features deliberately postponed. Three to five pages plus a clickable prototype. Not a twenty-page specification nobody finishes reading.
System boundaries
What sits inside, what stays outside, who owns which record. The cheapest decision in a project and the most expensive one to reverse. In BARVEA: we review and version models under ISO 19650, but we are not an authoring tool.
Data model
Which entities exist, how they relate, and which system is the source of truth for each field. Most arguments that sound like "it was supposed to work differently" are arguments about the data model, unlabelled.
Flows
The user path and the data path, with intermediate states and exceptions. States matter more than screens: in BARVEA a document is not done or not done, it moves through the S0–S6 statuses of ISO 19650 under fixed transition rules.
Integration points
Concrete APIs, formats, rate limits, authentication. Verified, not assumed: we send real requests and read what comes back. In autoPolar that meant pushing real NMEA 0183 sentences and a SignalK stream through the AWA-to-TWA conversion before any interface existed.
Risk register and the list of things we are not building
Every risk carries a fallback, otherwise it is a worry list. The second document is the underrated one: three months in, nobody asks "what happened to module X", because it is on paper that module X was left out on purpose.
Why do IT projects run late?
Almost always for three reasons: scope discovered mid-flight, an integration nobody tested, and postponed decisions. The drawing removes the first, mostly removes the second, and moves the third to the start, when changing your mind still costs hours instead of weeks.
A project starts as "an order handling system". In week eight it turns out there are three order types, two need a separate approval path, and one reaches accounting through another channel. That is not a change of requirements. It is a requirement that existed all along and was never drawn.
Integrations fail the same way every time. Documentation says one thing, production does another. You find out on day three or in month three, and the difference is a multiple, not a percentage.
Clickable prototype or written specification?
The prototype wins where the goal is understanding and sign-off. The document wins where the goal is boundaries, decisions and things that never appear on a screen. We do both, in different proportions than the industry default.
| Criterion | Twenty-page specification | Clickable prototype |
|---|---|---|
| Time to first client reaction | Days, it has to be read | Minutes, it has to be clicked |
| Who can judge it | Technical readers | Anyone who will use the thing |
| Catching misunderstandings | Rarely, both sides read their own version | Immediately, the missing step is visible |
| Records decisions and limits | Yes, that is its job | No |
Changing a line on a drawing is cheap. Rebuilding a wall is not.
What do I get after the first call?
A one-page outline: what we would build, what it connects to, what we would postpone, and the risks we can already see. Plus a quote, usually within one business day. Not a twenty-page proposal, because at that stage it would be guesswork in a nice template. After that, every two weeks, something you can click. Not a status report — a working slice. It is the only progress report in software that cannot be invented.
When can this stage be shortened, and when should it never be?
Shorten it when the scope is small and closed, there are no third-party integrations, the data is not regulated, and one user group sits in one room. Then the blueprint is half a day and a sketch. No sense drawing for a week what we can build in a week.
Cutting it becomes the most expensive decision in the project when any of these apply:
- An integration you do not control. ERP, payment gateway, someone else's API. An unverified assumption gets costlier every week, because the rest of the code already stands on it.
- Hardware. In ClimaBox a software change takes hours. A board change takes weeks and a new production run.
- Personal data or regulation. The data model decides what is stored where and for how long. Fixing that after go-live is a migration, not a refactor.
- User groups with conflicting interests. Client, contractor, quality control. Settle their conflicts on the drawing, or the code will settle them at random.
- Migration from a legacy system. Old data is always dirtier than anyone remembers.
Why does a two-person team draw more, not less?
RIDOA is two people. We say so plainly, because it changes how the work runs, not just the size of the invoice. Whoever draws the system is the one who builds it, so there is no handover between analysis and delivery and no place for context to leak. We also have no spare headcount to absorb a design mistake. That is why the drawing has to be right.
Our four products were built this way: BARVEA (BIM/CDE platform, IFC, BCF 2.1, COBie, Revit plugin), ClimaBox (IoT device for temperature, humidity and CO2 with a live dashboard), Let'Zapp (a live event map) and autoPolar (a sail trim assistant that works offline on board). Each started with a drawing and a list of what we were not building. See projects.
What we do not do: template WordPress sites, hosting without a project behind it, staff augmentation inside someone else's team, or jobs below the threshold where this process pays for itself. Our scope is described under services. If you have a workflow problem and no idea where to start, write to us. The first call is technical and ends with a drawing.