What a six-week build actually looks like, week by week

Most software projects are opaque until they are late. You sign, people disappear, and eight weeks later something arrives that is not quite what you pictured.

Here is what six weeks actually contains, what we need from you in each, and the two places it genuinely slips. The point of publishing it is that you should be able to tell by the end of week one whether this is going badly.

Week 1 — Access and the integration reality

The unglamorous week, and the one that decides the rest.

What we do. Stand up the environment in your cloud accounts. Get scoped access to the systems involved. Then the actual work of week one: find out whether we can read from and write to what you already run.

That last part sounds procedural and is the single largest variable in the project. A case management system with a documented API you can write to is one project. The same system with a login, a support address and an export button is a different one, and the difference is weeks.

What we need from you. Someone with authority to grant access, and roughly two hours from whoever actually knows the process — not the person who bought the software, the person who uses it.

What you should see by Friday. A written statement of what we can and cannot integrate with, and any change to the timeline that follows from it. If the integration turns out to be worse than expected, you hear that in week one, not week four.

Week 2 — Extraction on your documents

What we do. Build the part that reads. Records, intake forms, bills, whatever the workflow is built on, running against a sample of your real files rather than a demo set.

What we need from you. A sample that includes the ugly ones. Not your cleanest twenty files — the illegible record, the duplicate production, the case where a provider is missing. Giving us the clean sample feels helpful and costs you week five.

What you should see by Friday. Working software producing output from your own documents. It will be rough. It should exist.

A vendor who cannot show you anything running until week five is asking you to carry all the risk to the point where it is too late to stop.

Week 3 — The rules and the review screen

What we do. Your business rules, which are the part no product can sell you: what counts as a treatment gap, which discrepancies matter, what has to be flagged before an attorney sees it. Then the interface the work actually happens in.

What we need from you. The most valuable two hours of the project. Somebody who knows the exceptions — the person who can say “we do that differently for workers comp” — because the exceptions are the product and they are never written down anywhere.

Where scope grows. Here. Week three is when somebody sees it working and says “could it also do intake.” The answer is yes and not in this project, and a vendor who says yes to that question is doing you harm.

Week 4 — Field trial

What we do. Real users, real files, running in parallel with your existing process. Nothing is switched off.

What we need from you. Two or three people using it properly for two half-days, and honest reactions. The failure mode is politeness: people who do not want to criticize the thing the firm just paid for, so they use it once and say it seems fine.

What you should see. A list of everything that is wrong. A short list here is a bad sign, not a good one — it means people have not really used it.

This is the week that determines adoption, which is what actually kills these projects. A system that is accurate and that nobody opens is worth nothing, which is most of why these projects fail.

Week 5 — Accuracy and the thresholds

What we do. Measure how often it is right, using documents it has not seen. Then set the lines: what passes automatically, what a person checks first, and what the system refuses to guess at and escalates instead.

Accuracy is a dial, not a verdict. A workflow can be genuinely useful well below perfect if the uncertain cases route to a person rather than being quietly guessed.

What we need from you. A decision about risk tolerance, which is a partner decision rather than a technical one.

What you should see. A number, a method for how it was reached, and a written account of what it gets wrong. If the accuracy report has no failure list in it, it is marketing.

Week 6 — Handover

What we do. Training for the people who use it and the person who owns it. Runbooks. Source code in your repository. Documentation written for whoever inherits this in two years, who will not be in the room.

What we need from you. The person who will own it, for half a day.

What you have at the end. Software running in your cloud accounts on your own keys, source you own outright, and a written list of what it does badly. Then you decide whether you want us on retainer, and the honest answer for most firms is the cheaper tier.

Where it actually slips

Two places, and neither is engineering.

Integration, in week one. An accounting system with no write API, a portal that behaves differently from its documentation, or rate schedules that live in forty PDFs across two shared drives will each add a week or two. We find those in week one and tell you the same day. The fixed price does not move; the date does.

Scope, in weeks two and three. This one is friendlier and more dangerous. It arrives as enthusiasm — the thing works, so why not add the other thing. A project that starts as one workflow and becomes three does not take three times as long. It takes longer than that, and often does not finish.

One workflow, shipped and adopted, is worth more than three that are nearly done. The second project is much easier to sell internally once the first one is being used every day.

What this costs you in time

Roughly two to four hours a week from one person who knows the process, plus a heavier week four.

That is the honest number, and it is the one most vendors avoid. A vendor telling you the implementation requires nothing from your firm has either never done one or is planning to build what they imagine rather than what you do.