Scope before code: how I kick off freelance MVPs

The expensive mistake

Starting a client MVP in a chat thread feels fast. It is not. Without a written scope, every new message can redefine the product. You either eat the cost or fight about it later.

I learned this the hard way on a dashboard build where "just like the mock" quietly grew into three roles, email alerts, and a reporting export. The mock never said that. The chat history did, after the fact. I shipped late and underpaid for the real work.

Now I kick off with paper (or Markdown) before a repo.

Step 1: Discovery that fits one call

I keep discovery to a single focused call when I can. I ask for:

• Who the user is and what they do today without the product
• The one outcome that means version one worked
• Must-have vs later
• Logins, payments, admin needs, and data sensitivity
• Deadline and who approves changes

If the client cannot answer those, we are not ready to estimate. I would rather reschedule than invent requirements.

I also ask what must not happen. "No payment gateway in v1" or "no native app" saves weeks of polite confusion.

Step 2: One-page scope

The scope names:

• In-scope screens and flows
• Out-of-scope items (written explicitly)
• Assumptions (APIs that exist, content the client will provide, who designs UI)
• Definition of done for the first release

I send this for written sign-off. A thumbs-up in chat is not enough. I want a reply that says the scope is accepted, or a redlined version I can merge.

When the scope is fuzzy, I shrink v1. A thin working path beats a wide unfinished surface.

Step 3: Three-band estimate

I price lean / standard / protected bands so the client sees tradeoffs.

• Lean - happy path only, client provides copy and assets on time
• Standard - realistic buffer for auth, admin, and staging polish
• Protected - unclear third-party APIs, design churn, or multi-role admin

A deposit (often around 40%) starts the work. The protected band exists so "we will figure the API out later" has a price attached.

I put calendar weeks next to each band. Money without time is half a plan.

Step 4: Change requests

After sign-off, new work goes on a change-request sheet: what changed, why, impact on timeline and price. This keeps the relationship adult when "one more button" appears.

I do not treat every idea as hostility. I treat every idea as a decision. Decisions need a record.

What I refuse to start without

• A signed or clearly accepted scope
• Deposit cleared
• Access list (domains, repos, analytics, design files)
• A single approver on the client side

Two approvers with conflicting taste will burn your buffer faster than a hard bug.

Tools I use

I packed this ritual into Scopefirst, a kickoff pack with a filled clinic example. The point is not the PDF. The point is repeating the same clear steps on every engagement so I do not reinvent the process under pressure.

After kickoff

Only then do I open the repo: Next.js or the stack the constraint requires, staging on Vercel, and a short week-one plan. Code without scope is expensive theater.

Week one usually means: auth skeleton, one primary flow, staging URL, and a checklist of open questions. I share that early so surprises surface while they are still cheap.

FAQ

What if the client hates paperwork? Keep the scope to one page. Long contracts scare people. Vague chats bankrupt freelancers.

What if they want to "start coding and refine"? I offer a paid discovery week with a written deliverable. Exploration is work. It should be paid and bounded.

What if scope changes mid-build? That is normal. The change-request sheet is the product. Without it, you are guessing who owns the delay.

Bottom line

If you are stuck mid-project without a written scope, stop coding for a day, write the one-pager, and reset expectations with the client. The repo can wait. The relationship cannot survive endless invisible expansion.

If you want help shipping a client MVP with a clear scope first, use the contact page and tell me what you are building.