The Discovery Week — Landon Kuhn

If the offer sounds too fast or too cheap to be real, the right response is not more adjectives. It is a smaller first step, with the smallest commitment that still produces something useful — even if the engagement ends after that step.

That step is the discovery week. One week of work, priced flat, with a written scope as the deliverable. You spend a week's fee. You walk away with a document that describes the problem and what software would actually do about it. The build comes later, on a separate decision, with the price already set.

Why it exists

Most software engagements ask the buyer to commit before either side knows what they are committing to. The agency writes a statement of work based on a sales call. The freelancer quotes against a vague brief. Both arrangements push the risk of bad scoping onto the buyer, and neither party has a real obligation to define the work precisely before the meter starts.

The discovery week separates two things that are usually fused: deciding what to build, and building it. Decisions made under deadline pressure during a build are the source of most bad software. Moved earlier, they cost less and can be made carefully.

The shape

Five working days. One week, calendar-bounded, with a defined start and end.
Fixed price, paid up front. A flat fee for the week. No hourly meter, no overage.
One deliverable: a signed written scope. Specific to your business, specific to the problem, specific about what the build will and will not include.
The build price is set at the end of the week. If we continue, the number is already known. No re-quoting under pressure.
Either side can stop. If at the end of the week the right answer is not to build, we do not build. The discovery fee is the cap on your exposure.

What happens during the week

The week is spent understanding your business well enough to write a scope that holds up. That means looking at the actual systems you are running on, talking to the people who operate them, and watching the workflows that the software is meant to change. The point is not to gather requirements in the abstract. It is to get specific enough that the scope document describes a real change to a real operation, not a wishlist.

Day 1. On-site if practical. A working session with whoever knows how the business actually runs — not necessarily the owner, often the operator. The day is for seeing the existing tools, the spreadsheets, the manual steps, and the gaps between them.

Days 2–4. Off-site, focused work. Reviewing what was learned. Sketching the rough shape of what could change. Identifying the parts that are genuinely worth building and the parts that are better left alone, replaced with an off-the-shelf tool, or deferred. Short check-ins as needed; not a continuous meeting.

Day 5. The scope document is delivered. We review it together. Anything unclear gets clarified. Then it is either signed or not.

What you walk away with

The deliverable is a written scope document. It describes the problem, the proposed solution, what the build includes, what it does not include, the price, and the timeline. It is concrete enough to act on and specific enough that a different engineer could read it and understand the work.

That document is yours regardless of whether the engagement continues. If you decide the build is not right for you, or you want to pursue it later, or you want a second opinion from someone else — the scope is the artifact you take into that conversation. It is not a sales document. It is a working specification.

Either side can stop

At the end of the week, both parties make a separate decision. The discovery fee was already paid; nothing further is owed if we do not continue.

I will say no for the same reasons you might. If the right answer is an off-the-shelf tool, I will say so. If the problem is not actually a software problem, I will say so. If the scope is larger or smaller than I am the right person for, I will say so. The point of the week is to find the honest answer, not to manufacture an engagement.

What it isn’t

Not a sales call. The fee is paid before Day 1. The week is real work, not a long pitch.
Not a free consultation. Free consultations exist to qualify leads. This is paid because the work itself is paid for.
Not a prerequisite. If you already have a precise written scope and just want a quote, we can skip this step.
Not a commitment to build. The decision to build is made at the end of the week, with the scope in hand, not at the beginning.

The point

Skepticism about a fast, fixed-price offer is a reasonable response to an unfamiliar shape of engagement. The discovery week is the answer that does not require trusting the claim first. You are buying a week's work, with a defined output, with a clear exit. If the rest of the offer is real, the week will demonstrate it. If it is not, you are out a week's fee and you have a written scope you can take elsewhere.

That is the whole structure. It is the way the engagement starts because it is the way an engagement should start.