The Project Estimator
A live tool on this site that turns nine answers about how a business runs today into its bottlenecks, named in its own words, and the order we would build them in.
Evidence for
- AI integrations and automation
- Custom business systems
- Modern websites and web apps
Built on
- TypeScript
- Next.js
- React
- Anthropic API
- Vitest
Measured
- Questions asked
- 9
lib/estimate/questions.ts- Answer options
- 51
lib/estimate/questions.ts- Bottleneck rules
- 12
lib/estimate/bottlenecks.ts- Complexity tiers
- 4
lib/estimate/complexity.ts- Tests
- 27
vitest run, lib/estimate/estimate.test.ts
The page itself, live on this site right now — not a mock-up standing in for something you cannot reach.
The interview. Every option here is wired to a specific line the brief can later cite back.
One bottleneck from a real brief, run against nothing but the answers above it — quoted evidence included.
Try it yourself → Nine questions, about four minutes, and no address asked for until the brief is already in front of you.
The problem it was built for#
Every "project calculator" on the internet asks the same question: what do you want built? That produces a list of features restated as a quote — useful to nobody, because a business that knew exactly what to build would not need us.
The founder's brief for this tool asked for something else: find the
bottleneck, not just the wish list. So three of the nine questions are not
about the system at all — today, breaks and scale ask how the business
runs right now. A questionnaire that only asks what you want cannot surface a
bottleneck; it can only echo the request back in a longer sentence.
Every answer declares what it maps to#
There is no scoring function in this codebase that reads answers and decides what they mean. Every option, in every one of the fifty-one across the nine questions, states its own consequence at the point it is written: which component it implies, which integration class, which of a fixed set of "signals" it is evidence for. The brief that comes out the other end is assembled from those declarations and nothing else — which is what makes it possible to say, of any sentence in it, exactly which tick produced it.
The alternative — a model or a weighted formula that turns answers into a verdict — was rejected for the same reason SoftWrites turns down that approach everywhere else on this site: a conclusion nobody can trace is a conclusion nobody should have to trust.
It is built to disagree with you#
A tool that only ever agrees with what you selected is selling something. Five rules in the brief exist purely to argue back, and they fire on specific combinations rather than on a general sense that the project sounds big:
| If you selected | What it tells you |
|---|---|
| Working with no signal | This is usually the most expensive line item, and often solved by letting the app queue and sync rather than by building genuine offline support. |
| A dashboard, but reporting was not the top-ranked problem | Reporting is what people ask for first and almost never what to build first. Structure the records properly and most reports turn out to be a query. |
| An AI feature | We would ask what the model is for. If the answer needs to be explainable or identical every run, deterministic rules are the better engineering. |
| An undocumented legacy system to integrate with | That is a project of its own, with its own risk, and we would want to know whether it can be read from at all before anything else is agreed. |
A brief is a URL, not a database row#
Nothing about a submitted interview is stored on our side. The answers are encoded into the link itself — legibly, not as a wall of base64, so a reader who checks the address bar can see it holds their own words and nothing else — and the brief page is a pure function of that link: same answers in, same brief out, on any machine, forever.
That has a sharp edge, and the schema is versioned to catch it. If the question set ever changes, an old link must not silently render a different brief against the new questions — it has to say the answers it holds are stale. A brief that quietly rewrites itself underneath a link someone forwarded to a finance director six months ago would be worse than one that expires cleanly.
What we learned#
This is the site's other answer to "what do you think about AI," and it is the opposite answer from the Security Command Centre's. There, the conclusion was to use no model at all. Here, a model is genuinely useful — for exactly one narrow job.
The optional model on this page reads a free-text paragraph and ticks boxes. That is the whole of its authority: it can select from the fixed vocabulary of nine questions and fifty-one options, and it cannot write a sentence that reaches the brief, invent an option that is not in the list, or skip the step where a person checks its work before anything is derived from it.