Documents and packs
The document someone else is waiting for.
The business plan the bank asks for. The one-pager your board signs off. The evidence pack a partner or a franchisee wants every quarter. Same shape every time, and assembled by hand every time. We build the system that gathers the numbers, assembles the pack in your template, and puts the verdict on page one. A person reviews it and sends it.
Document run
Every time
The request
The quarter closes, or someone asks for the pack.
Gather
your sourcesNumbers pulled from the systems they already live in.
Assemble
Your template, your language, your order of sections.
Interpret
Page one says what the numbers mean.
You send it
Reviewed by a person, out the same day.
The run your team gets after handover.
How it goes now
- Four exports, opened side by side, copied across by hand
- Last quarter’s file saved under a new name and edited
- A senior person losing days to assembly instead of judgement
- Figures nobody can trace back when the reviewer asks
- The pack lands late, and the person who asked for it has moved on
How it goes after
- The draft exists before anyone asks where it is
- Every figure carries the system it came from
- The senior person edits the argument, not the layout
- Page one already says what the numbers mean
- It goes out the day it was asked for
The part everyone skips: page one.
When we ask people what is wrong with the packs they produce today, the answer is rarely that a number is missing. It is that nothing in the document says whether the numbers are good. The reader has to work that out themselves, and often they do not, so the pack gets filed rather than acted on.
So a summary page is part of the build, not an extra: what changed, what it means, and what needs a decision. It arrives as a draft with a named author who can overrule it, because a verdict nobody owns is worse than no verdict.
Exactly what the build includes
- Your template, your section order, your language, not a generic layout
- Numbers pulled from the systems they already live in, with the source recorded next to each one
- A first draft assembled the moment the trigger happens, not when someone finds the time
- A summary page that says what the numbers mean, not only what they are
- Every figure traceable back to where it came from, so a reviewer can check it in seconds
- A person reviews and releases. Nothing leaves your building on its own.
Acceptance criteria, for example
Agreed in writing before the build. The system ships when it meets them; until then, we keep working at no extra cost.
- Time to first draft: measured before and after, on the same document
- Figure accuracy: every number in a sample pack matches its source system exactly
- Traceability: a reviewer can find the origin of any figure without asking anyone
- Reviewer edits: how much of the draft survives to the version that goes out
True of every build we do
- Fixed price
- Quoted once after the diagnosis, invoiced once. No day rates and no running meter.
- Criteria in writing
- We agree what the system has to do, and how it will be measured, before anything is built.
- It ships when it passes
- Tested on your data against those criteria. Until it passes, we keep working at no extra cost.
- You own everything
- Code, prompts, data, accounts, documentation. Yours from day one, so there is nothing to be locked into.
- Your team runs it
- Training and a handover built for people who did not write it. If you never speak to us again, it keeps working.
How you buy it
The same three steps for every job we take on. You can stop after either of the first two.
Step 1
Diagnosis
EUR 4,900, two weeks
What this work costs you today, what a system would take off your team, and a fixed quote with the acceptance criteria written down. Credited in full against a build that starts within 90 days. If it finds no job worth building, you get the fee back.
Step 2
Build
from EUR 14,900, fixed after the diagnosis
Built into the tools you already run, so there is no new platform to adopt. Tested against the criteria we wrote down, on your data. It ships when it passes, with training and full ownership.
Step 3
Run
optional
The answer to who owns it after we leave: monitoring, exception handling, and changes as the business changes. You own the system either way and your team is trained to run it, so this is a choice rather than a dependency.
Questions buyers ask
What if a number is wrong?
Then a person catches it, because a person still signs it. Every figure carries the source it came from, so checking is a click rather than a reconstruction. We treat traceability as an acceptance criterion, not a feature: if a reviewer cannot verify a figure quickly, the system has not passed.
Does it write the commentary too?
It writes a first draft of it, and that draft is the part reviewers change most. What buyers tell us these packs lack is a verdict: page one that says whether this is good or bad and what it means. Getting a defensible attempt at that in front of a human beats a blank page, and the human still decides what it says.
Our document is very specific to us.
That is the normal case, and it is why this starts with a diagnosis rather than a template. We build to the pack you already produce, in the order you already produce it. If the format is genuinely different every time, that is worth finding out in two weeks rather than after a build.
Which formats does it produce?
Whatever you send today: Word, PowerPoint, PDF, or a Google equivalent. If the document is assembled in a tool with an API, we build into that tool rather than around it.
Where do the numbers come from?
Wherever they are now. ERP, accounting system, CRM, a shared drive, or the spreadsheet somebody maintains. Part of the diagnosis is finding out which of those is actually the source of truth, which is a question most teams have never had to answer out loud.
Is this the same as the reporting build?
They overlap and they are often bought together. This one is about a document that goes to someone outside the team and has to be defensible. The reporting build is about the recurring internal numbers your team rebuilds every month. If you are not sure which you have, the diagnosis sorts it.
If the recurring thing is a spreadsheet rather than a document, the numbers your team rebuilds by hand is the nearer job. They are often bought together.
Bring the last one you sent.
Twenty-five minutes with the actual document tells us more than an hour of description. You leave knowing whether this is worth building, and roughly what it would cost.