The two-week build diagnostic.
Before anyone responsibly scopes a build, both sides have two weeks of work to do. This is that work — with a fixed fee and a written deliverable you can take to any vendor, including not us.
Every other opening engagement has a hidden cost.
A free assessment is too shallow to be useful. A scoped implementation requires assumptions about your systems and data that nobody on either side has tested. The two-week diagnostic is the smallest unit of work that resolves both problems: it is a real engagement, with a real fee, that produces a real artifact.
If we don’t do the build that follows, the deliverable still has value — you can hand it to a different vendor or run the implementation yourself. We won’t say that’s the better outcome for us. We will say the diagnostic is honest on its own terms.
Week one discovers. Week two decides.
Week 1 — Discovery
Stakeholder interviews — four to seven people, from the budget owner to the people who do the work the build would touch. Technical inventory of the systems, APIs, and data the build would depend on, including the gap between what the documentation says and what’s in the database. Baseline measurement of the two or three metrics that matter, in writing, with methodology, before any build work begins.
Week 2 — Synthesis
Analysis of the discovery output into a current-state map: the constraint that has to be solved before any software helps, the dependencies, the risk profile. Then the recommendations document — eight to fifteen pages, a document, not a deck — and a 60–90 minute readout with your leadership team. The document is sent ahead; the meeting is for questions.
Five sections, the same shape every time.
- 01
Current state
What systems are in play, what the data actually looks like, what the baseline metrics are, and what the operating constraint is. Descriptive, not prescriptive — measured before any build work begins.
- 02
Recommendations
What we'd build, what we'd defer, and what we wouldn't do — named specifically, with the reasoning per recommendation. The diagnostic is paid even when the recommendation is don't proceed.
- 03
Scope
If the recommendations point at a build: sprints, deliverables, dependencies, the integration list, a cost band, and a timeline band — documented at the level you could hand to another vendor. If they point at don't build: what to do instead.
- 04
Risk register
What we think could go wrong, in priority order, with an honest read on each. This is the section clients reread the most.
- 05
Counsel attribution
For compliance-touching engagements only: named outside counsel reviews the framework, and the review is reflected in the document — with the disclosure, in writing, that counsel does not represent you.
Why two weeks, and what we ask of you.
Shorter than two weeks doesn’t allow real measurement. Longer invites scope creep — if the diagnostic bleeds past two weeks, it usually means implementation work has started without a signed scope, which is bad for both sides. Two weeks is the smallest window that produces a real artifact and the largest that doesn’t pretend to be more than a diagnostic.
From your side, four things: read-only access to the relevant systems and data; four to seven interviews of 45–60 minutes plus the readout; the fee — half on signature, half on readout day; and a mutual NDA.
If the recommendation is a build, the build is its own fixed-scope contract — deliverables, milestones, fee, signed before work starts. We don’t autorenew into ongoing work; we’ve written about why. Run-state support, where it’s wanted, is a defined deliverable on a defined cadence — never an open meter.
A conversation first. The diagnostic if it fits.
Tell us what you’re considering building and what’s prompting it. We’ll tell you whether the diagnostic makes sense for your situation — and if we’re not the right fit, we’ll say so.
Request a diagnostic→