If you run a growing business, you’re stuck in an awkward spot. Your operations are too specific for off-the-shelf software, and your budget can’t absorb an open-ended consulting engagement. When a custom technology project goes wrong at your size, the cause is rarely bad code. It’s that someone built the wrong thing.
That should be caught before anyone writes a line of code, not halfway through the budget. That’s the whole point of a diagnostic: figure out the real constraint, test the assumptions, and scope the work before committing to a build.
Every technology partner now says they “start with discovery.” This checklist helps you tell which ones actually investigate your business and which ones run a workshop before handing you the proposal they’d already written.
Why this matters more when you don’t have a CTO
Without a technology leader on staff, your partner’s judgment isn’t a second opinion. It’s the only opinion. If they skip diagnosis and go straight to building, every assumption baked into the architecture goes unchallenged — because nobody in your building is positioned to challenge it.
The cost isn’t just money. A rebuild halfway through a project resets your team’s confidence in technology altogether. The next initiative is harder to fund, harder to staff, and harder to get anyone excited about.
What a diagnostic is — and what it isn’t
A diagnostic is not a free estimate. It’s not a sales call with better questions. It’s not a requirements workshop where someone writes down everything your team wishes for.
It’s a structured, time-boxed investigation that ends in a clear recommendation. In our experience, it typically runs two to four weeks. Sometimes that recommendation is to build something new. Sometimes it’s to configure a product you already pay for, connect two systems you already own, or fix the one that’s mostly working. If a partner’s diagnostic always ends in “you need a full custom build,” you’re not in an investigation. You’re in a sales pipeline.
The checklist
Six things to verify before you hire anyone. If a partner can’t satisfy most of them, their discovery phase is decoration.
1. The diagnostic is its own paid engagement
If it’s free, it’s a sales tool. A real diagnostic puts senior time against your specific problem — interviewing your people, auditing your systems, mapping your constraints — and that work costs something.
What you pay for should be yours outright: a roadmap you could hand to a different team and they could execute it. If the deliverable only makes sense inside the partner’s own process, it isn’t a diagnostic. It’s lock-in.
Red flag: “Discovery” bundled into the project estimate with no standalone deliverable and no separate line item.
2. Senior people lead it
Ask who will actually be in the room. Not who manages the account — who evaluates your systems, talks to your team, and maps the technical constraints.
If the answer is an account manager or a junior analyst, the partner treats diagnosis as overhead. The people doing it should be the same people who will design and build what comes next.
Ask directly: “Will the people running the diagnostic be the people building the system?“
3. You get a roadmap, not a feature list
The deliverable should include:
- The business constraint you’re actually solving — not a list of features
- The recommended approach, and why the alternatives were ruled out
- A phased plan with milestones and dependencies
- A timeline tied to those milestones
- Cost broken down by phase
If you get a backlog or a proposal “to be refined during sprint planning,” the hard work of scoping didn’t happen. Clear milestones protect both sides, because everyone knows what “done” looks like at each stage.
4. They can tell you not to build
This is the most honest test there is. A partner who never recommends something smaller — or nothing custom at all — isn’t diagnosing. They’re selling.
The right answer might be configuring a product you already own, connecting two systems, or repairing a platform that’s mostly right. Ask every partner directly: “When did you last tell a client not to build?“
5. Scope and budget are defined before each phase starts
The diagnostic should remove ambiguity, not add it. Before building begins, you should know what gets delivered at each milestone and what it costs. Ask:
- What exactly is delivered at each milestone?
- What happens if a milestone is missed?
- How are changes handled — through a defined process, or informally mid-sprint?
If a partner won’t commit to deliverables per phase, either they didn’t diagnose thoroughly enough to be confident, or they prefer the flexibility of billing without an endpoint. Neither works in your favor.
6. Life after launch is planned up front
The roadmap should answer who maintains the system, how issues and requests get handled, and what ongoing support costs — before you sign the build contract. If support only comes up near the end, the partner is optimizing for project revenue, not your operations.
Diagnose first vs. build first
| Diagnose first | Build first | |
|---|---|---|
| When scope is defined | Before building starts | During the build, as you go |
| Who leads early conversations | Senior technologists | Sales or project managers |
| How it’s priced | By phase, with defined deliverables | Open-ended hours |
| Risk of a rebuild | Low — the constraint is validated first | High — assumptions are baked into the architecture |
| Post-launch planning | From day one | After launch, if ever |
| Who owns the diagnostic | You — usable by any team | Nobody — there isn’t one |
Building first isn’t always wrong. For a simple, well-understood problem with few unknowns, it can be fine. But once you have multiple stakeholders, older systems to work around, and a budget that can’t absorb rework, diagnosing first is the cheaper path.
Red flags that discovery is just for show
- It’s free or “included,” and there’s nothing you could hand to another team.
- The proposal looks the same no matter your industry, your problem, or your systems.
- No senior technical person shows up — only sales and project management.
- The roadmap has no specifics. No milestones, no timelines, no cost by phase.
- They can’t name a time they told a client not to build.
- Support appears for the first time as an add-on right before you sign.
- The people selling aren’t the people building. Every hand-off loses exactly the context the diagnostic was supposed to capture.
How to use this
- Before the first call. Share the six points with whoever else is involved in the decision. Agree up front which ones are non-negotiable, so every partner gets judged the same way.
- During evaluation. Ask each partner to walk you through their diagnostic against the checklist. Ask for references from clients who went through their diagnostic — not just clients they built for.
- After the diagnostic. Hold the deliverable up against point 3. Is there a real roadmap with milestones, timelines, and cost by phase? If not, don’t move to the build with that partner.
Frequently asked questions
Should the diagnostic fee count toward the build if we go ahead with the same partner?
Some partners credit it, some don’t. The better question is whether you own what you paid for. If the roadmap stands on its own, the fee is secondary — you paid for a plan, you got a plan, and it’s worth the same whoever builds it.
Can we take the diagnostic to a different team for the build?
You should be able to. A credible partner writes a roadmap clear enough for any qualified team to execute. If it only makes sense inside their tools or their process, it isn’t a diagnostic. It’s a dependency.
What if the diagnostic says we don’t need to build anything?
Then it did its job. Finding out you can solve the problem with what you already have, before spending a build budget, is the best outcome a diagnostic can produce.
The bottom line
The diagnostic isn’t a preliminary step. It’s the most consequential decision in the whole engagement, because it’s what prevents the two most expensive outcomes in custom technology: building the wrong thing, and rebuilding the right thing badly.
This checklist is how we expect to be judged. Every engagement we take on starts with a fixed-fee diagnostic, usually as the first step of our technology strategy work. The people who run it are the people who build it, and you own the roadmap whether you work with us or not. Partners who welcome this kind of scrutiny are the ones worth hiring. The ones who push back are telling you how the rest of the engagement will go.
Ready to talk it through? Book a strategy call.
