Nineteen days is a real number from a real project. Halo is an AI research assistant that answers questions from a team's own documents, with citations. It went from a first call to real users in nineteen working days, and it is still running.
The interesting part is not the speed. It is what the nineteen days did not include, and the four things that stayed in scope no matter how tight it got. Both lists are more useful than the timeline.
I am wary of timeline claims generally, including this one, because they are usually quoted without the scope that made them possible. Nineteen days for six features on a stack that was already settled is a different statement from nineteen days for eleven features on a stack chosen during the project, and only the first is a claim anyone should make.
What did nineteen days actually buy?#
A working product that a team could use daily and judge honestly: authentication with real accounts, billing, document upload and indexing, a question interface with streamed answers, verified citations back to source passages, per-user cost tracking, and a spend ceiling.
It also bought the boring infrastructure that determines whether something survives its first month — a staging environment, continuous integration running type-checks and tests, error tracking wired up before launch, uptime monitoring, and automated backups with a restore that had actually been tested once.
That last sentence is where most "we shipped in three weeks" stories quietly differ from this one. Those things are not polish added later. They were in scope from day one, which is precisely why the calendar held.
What got cut, and how quickly?#
The original brief had eleven features. Six shipped. The cuts happened on day two, in writing, before any code existed — which is the only time cutting is cheap.
| Feature | Decision | Reason |
|---|---|---|
| Ask questions, get cited answers | Shipped | The entire thesis |
| Document upload and indexing | Shipped | No corpus, no product |
| Accounts and billing | Shipped | Needed to charge anyone |
| Team workspaces | Cut to v2 | One workspace proved the thesis |
| Slack integration | Cut to v2 | Nice, not load-bearing |
| Admin analytics dashboard | Cut | The database answered the same questions |
| Custom branding | Cut | No user asked |
| Bulk import from Drive | Cut to v2 | Manual upload was acceptable at ten users |
| Answer history and sharing | Cut to v2 | Genuinely wanted, not required to learn |
| Mobile app | Cut | A responsive web app was sufficient |
| SSO | Cut | No prospect had asked yet |
The test applied to each one was narrow: does this feature change what we learn from putting the product in front of users? If it did not, it was not in the nineteen days. Team workspaces and answer sharing were the hardest to cut because both are obviously useful, and neither changed what the first ten users would teach us.
It is worth noticing what that test excludes. It says nothing about how difficult a feature is, or how often it will eventually be requested, or how impressive it looks in a demo. SSO was cut despite being straightforward, because no prospect had asked for it. Bulk import was cut despite being obviously convenient, because ten users uploading files manually still produces exactly the same learning as ten users importing them.
The cuts that hurt are always the reasonable ones. Anything obviously unnecessary would not have reached a feature list in the first place, so scope reduction is entirely a matter of declining things that are genuinely worth building — just not yet, and not if they cost the deadline.
Cutting on day two also meant nothing was half-built. The most expensive version of scope reduction is discovering on day fourteen that three features are each 60% complete, because none of them can ship and all of them cost real time.
Where did the nineteen days go?#
Not where people assume. The AI layer was under a third of the calendar.
| Phase | Days | AI-generated | Hand-written |
|---|---|---|---|
| Scoping and data model | 3 | A first draft only | Every decision that stuck |
| Auth, billing, app shell | 5 | Most of it | Security and roles |
| Retrieval and AI layer | 6 | Roughly half | Prompt, retrieval, evaluation |
| Evaluation and cost caps | 3 | Very little | Nearly all |
| Staging, monitoring, handover | 2 | None | All |
Five days on auth, billing and the application shell might look like a lot for something with no AI in it. It is the reason the six days on retrieval were possible: there was already a real user model to filter documents against, and a real user record to attribute cost to.
Building the AI layer first and adding accounts afterwards is the standard path and it is what produces retrieval that cannot be filtered by permission without a reindex. That mistake costs weeks, and it lands well after the deadline that made it seem sensible.
What did AI actually write?#
Most of the typing, very little of the thinking. The split was consistent enough to describe as a rule.
Almost entirely generated#
Scaffolding, forms, CRUD endpoints, the component shell, migrations from a schema I had already decided, and the first pass of tests. This is the work where the correct answer is conventional and the value is in producing it quickly.
Generated then substantially rewritten#
Business logic and the retrieval pipeline. A generated first draft is a useful starting point that gets you past the blank file, and roughly half of it survived contact with the actual requirements.
Written by hand#
Authentication, permissions, the data model, anything touching billing, and the entire evaluation harness. These fail quietly and expensively, and reviewing generated code in these areas takes longer than writing it.
That division is the whole of what an AI-accelerated workflow means in practice. It compresses the typing-heavy parts by two to three times and does approximately nothing for scoping, data modelling or deciding what to cut — which are the parts that determine whether the project succeeds.
What never gets cut?#
Four things. Every one of them was in scope on day one and none of them was negotiable when the calendar tightened.
The data model#
The schema is the expensive thing to change. Features built quickly on a sound model are cheap to replace; a rushed schema is not, and it taxes every subsequent change. Three days on scoping and data modelling was the highest-return time in the project.
Authentication and permissions#
Not just login — who may see which document. This is the constraint that has to exist before indexing, because retrieval built without a permission dimension cannot acquire one later without rebuilding the index.
Error tracking and backups#
Wired up before launch, not after the first incident. A tested restore takes an hour and it is the difference between a bad afternoon and an unrecoverable one. Backups nobody has restored from are not backups.
The evaluation set#
Fifty real questions with labelled correct sources. Without it, "is the assistant good enough" is an argument rather than a measurement, and every subsequent prompt change is unreviewed. It cost an afternoon.
Speed comes from cutting features, never from cutting foundations. The first is a product decision; the second is a loan at a punitive rate.
How does a nineteen-day timeline hold?#
Three things, none of them about working faster.
Scope froze on day two. Everything cut went onto a written v2 list rather than into a conversation. When new ideas arrived mid-build — and they did — they went on that list too, which took about thirty seconds and avoided the negotiation that normally consumes an afternoon.
The stack was not a decision. This was Template 04 from my stack: a standard web app with an AI module. No time was spent choosing a database, an auth provider or a hosting platform, because those were settled long before this project existed. That alone is worth two or three days on a build this size.
Progress was visible daily. Commits went up continuously and the client could see the app as it existed rather than as it was described. Nothing accumulated into a surprise, which is what usually causes a late-stage rewrite disguised as "feedback".
What did each week look like?#
Nineteen working days is just under four weeks. The shape of each was distinct enough to be worth describing, because the ordering is most of the method.
Week one: decide, then build the boring half#
Three days of scoping produced two artefacts: a written scope naming what was explicitly excluded, and a data model. Not a diagram — actual schema, with the decisions about identity, tenancy and money already made, because those are the ones that are expensive to revisit.
The remaining two days started the application shell. Auth, the account model, the empty dashboard. Unglamorous, fast to generate, and the foundation everything else attaches to.
Week two: the shell finishes, retrieval starts#
Billing and onboarding completed, then document upload and the first indexing pipeline. By the end of the week a document could be uploaded and searched, with no generation involved at all — which is deliberately the order, because search quality is measurable on its own and generation only obscures it.
Week three: answers, citations and the uncomfortable number#
Generation, streaming and citations. This is also when the evaluation set was run properly for the first time and returned 61%, which consumed most of two days in retrieval work rather than prompt work.
It is worth being explicit that this was the week the project felt least certain. Everything visible worked; the measurement said the answers were not good enough. Having the measurement is what turned that into two days of targeted work rather than a fortnight of adjusting prompts hopefully.
Week four: the four remaining days#
Cost caps, rate limiting, the spend ceiling, staging, monitoring, backups, restore test, handover. No features. This is the block that gets eaten when a project runs late, and protecting it is most of what "shipped in nineteen days" actually means.
What went wrong?#
Two things, and both are worth naming because they are the honest part of any timeline claim.
The document parsing was worse than expected. The corpus included two-column PDFs that interleaved into nonsense when parsed, and tables that flattened into unreadable strings. This cost roughly a day and a half that was not in the estimate, and it would have been caught by parsing twenty representative documents during scoping. I now do exactly that before quoting.
The first evaluation run was uncomfortable. Retrieval was finding the correct passage about 61% of the time, which is not good enough to ship. Fixing it — structural chunking, hybrid search, a reranker — took most of two days and lifted it to 91%. That work was in scope, but the amount of it was not, and it is the reason the evaluation set exists before the deadline rather than after.
What did it cost to run?#
About $0.02 per answer at launch traffic, plus hosting and database on an existing plan. Generation dominated that figure; embedding and reranking were rounding errors against it.
The number mattered less than the fact that it was known. Per-user cost logging went in before launch, which meant the question "which account is expensive" had an answer on day one rather than after an invoice. Reducing context from twenty unranked passages to five reranked ones cut cost per answer by roughly two thirds while improving accuracy.
What did the client have to do?#
More than clients usually expect, and it is the most common reason a timeline like this fails. A nineteen-day build requires a decision-maker available inside the same week, not the same month.
Available for the cutting conversation#
Somebody with authority had to agree, on day two, that five of eleven features were not in this build. That is not a technical decision and it cannot be delegated to a developer. Where it gets deferred, the build stretches by the length of the deferral and then some.
Reachable for the questions that block#
Roughly a dozen questions came up that only the client could answer — what happens to a document when a user leaves, whether trials need a card, how invoices should read. Each took minutes to answer and would have blocked for days if they had gone unanswered.
Willing to look at it as it existed#
Reviewing the actual app twice a week, not a demo at the end. This is what stops the late-stage surprise, and it is the fifth step of the process I run on every project for exactly that reason.
None of this is onerous — perhaps three hours a week. But it is real, and a client who cannot commit it should not be sold a nineteen-day timeline, because the calendar will be spent waiting rather than building.
Would this work for any product?#
No, and the boundary is fairly clear.
Nineteen days works when the thesis is narrow and testable by a small number of users, when the data model is genuinely understood by day three, and when someone with authority can make scope decisions in the same week they are asked. Remove any one of those and the timeline stretches regardless of how the code gets written.
It does not work for products needing regulatory review, complex multi-party workflows, or integrations with systems whose behaviour is undocumented. It also does not work when the person approving scope is unavailable, because the freeze on day two is the mechanism holding the whole thing together.
What happened after launch?#
The part that decides whether a fast build was actually good. A nineteen-day MVP that needs rewriting in month two was not fast, it was deferred.
The first month brought the usual: a handful of bugs, most of them in document parsing edge cases rather than in generated code, and a steady stream of requests from the v2 list. Two things from that list shipped in the following fortnight — answer history and bulk import — and both slotted in without touching the schema, which is the practical test of whether the data model was right.
Nothing from the foundations needed revisiting. Auth held, permissions held, the cost ceiling was never hit because the routing work had already brought spend down, and the restore was never needed. That is an unexciting paragraph and it is the entire point of the four things that did not get cut.
The one genuine surprise was how much the evaluation set earned after launch rather than during the build. Every prompt adjustment in the following month was re-run against it, and two changes that read as improvements were reverted because refusal correctness dropped. Without the harness those would have shipped, and the regression would have been reported by a user weeks later.
What would I do differently?#
Three things, all cheap.
- Parse the real documents during scoping. A day and a half of surprise, avoidable in an afternoon. This is now a standard scoping step rather than a lesson.
- Build the evaluation set before the retrieval layer, not alongside it. Having the measurement first would have made the 61% result a day-one fact rather than a day-twelve shock.
- Write the handover document as I go. Compressed into the final two days, it was the only genuinely rushed artefact in the project, and it is the one the client reads most.
Conclusion#
The nineteen days were not the achievement. Cutting five of eleven features on day two was, and so was refusing to cut the data model, permissions, backups or the evaluation set when the schedule got tight.
If you want a timeline like this, the work happens before anyone opens an editor. Decide what the product must prove, cut everything that does not change what you learn, freeze it in writing, and start from a stack you are not re-deciding. Then let generation compress the typing, and spend the time it saves on the parts that determine whether the thing survives — which are the same parts they have always been.
If you have a deadline that already passed and a feature list that has not been cut, that conversation is where a build starts, and the cutting is usually the most valuable half hour of it.