The Four Questions We Ask Before Every Build

The Freedom Ag spray card took one session to build. The application log pre-populate took another. Each one looked simple from the outside.

None of it started with "here's a feature idea." It started with four questions we fill in before we scope anything.

We won't start a build without answers to all four. Not because we need the paperwork. Because without them we're guessing at whether the problem is real, whether the solution is measurable, and whether we'll know in 60 days if anything actually changed.

The Four

Bucket. What category of problem is this? Compliance documentation, billing accuracy, field communication, manual re-entry, reporting delay, AI feature, portal. Naming it places the problem in a shape we either recognize or don't. Compliance documentation for ag applications is a known shape. Medicaid session note documentation is a known shape. Knowing the shape tells us what we're adapting vs. building from scratch.

KPI. What one number proves this worked? Not a list of benefits. One number. Time per spray card, documentation rate before billing cutoff, days between session and submitted note, denial rate on submitted claims. If you can't name the KPI before we start, we won't be able to tell you in 60 days whether the build was worth it.

Baseline. What is that number right now? The actual number, not an estimate. Freedom Ag: 15-20 minutes per spray card, generated from memory at end of day, often wrong. Homefront: 15-20 minutes per session note, written without reference to the specific child's IFSP goals. The baseline is what we're measuring against. It has to exist before we can promise anything.

60-day target. Where should that number be in 60 days? Not "better." Spray card under 2 minutes. Session note drafted in under 5. Zero sessions logged with authorization already exhausted. The 60-day window is short enough that the target has to be plausible from the baseline, and specific enough that we know when we've hit it.

What This Stops

If a prospect can't answer all four, one of a few things is true: they haven't isolated the problem yet, the current workflow isn't measured so the KPI doesn't exist, or the 60-day target is unrealistic relative to where they are now.

Any of those is useful. A build that can't be measured can't be justified. Better to know that before the first design session than after the first invoice.

The scoping call is where we fill in the blanks together. But we need to know the bucket before we can tell you whether a blank is even fillable.

What Good Answers Look Like

Both projects we've written about most gave us clean answers to all four.

Freedom Ag: compliance documentation, time-to-compliant-spray-card, 15-20 minutes from verbal job description, under 2 minutes from the same description by reading the product label database instead of relying on memory.

Homefront: AI-assisted documentation, time-from-session-to-submitted-note plus billing denial rate, 15-20 minutes per note with frequent goal citation errors and no authorization check, under 5 minutes with IFSP goal reference built in and authorization status visible before logging.

Both shipped. The clarity on all four questions at the start is a large part of why.

If you're looking at a workflow that costs your team time every day and wondering whether it's buildable, the answer to that question starts with whether you can fill in those four blanks. The scoping call is free.