How I'd Scope a Project Before Writing a Single Line of Code

Because "we'll figure it out as we go" is how simple projects turn expensive.

I used to think scoping was something you could skip if the work seemed simple enough. Two people, clear idea, why not just start building?

Here's what actually happens when you skip it: everyone's excited, the work starts fast, and a few days in, one person thinks the job is half done while the other thinks it's basically finished. Nobody agreed on what "done" looks like, so nobody's wrong, they just never had the same picture in their head. That gap gets expensive. Not just in money, but in trust.

So here's how I'd approach scoping any project before writing a single line of code.

Step 1: Ask for a Written Brief

No call needed right away. Just: what's the problem, who's it for, and what does done look like to you.

Writing forces clarity in a way a call doesn't. When someone has to type out what they actually need, half-formed ideas get caught before they turn into wasted work. A call can feel productive without actually producing anything concrete, everyone nods along, and then two different people leave with two different understandings of what was agreed.

A written brief is proof you both meant the same thing.

Step 2: Clarify Over Message

Most things can get sorted out this way. Ask the specific questions the brief left open, get specific answers back, keep it in writing.

This isn't about avoiding calls out of laziness. It's that most clarifying questions don't need a synchronous conversation, they need a clear question and a clear answer, which text handles just fine. And it keeps a paper trail. If a question comes up later about what was actually asked for, it's right there.

If the brief is too tangled to sort out in writing, genuinely too complex, too many moving parts, too much back-and-forth, that's when a call actually makes sense. Not before. The call becomes a tool for a specific problem, not a default first step.

Step 3: Send a Written Proposal

Scope, timeline, a fixed price. No surprises, no clock running while things are still being figured out.

This is the point where vague becomes concrete. Not "a website with some pages", an actual list of what's being built, roughly how long it'll take, and exactly what it costs. Fixed price matters here specifically because it removes the incentive misalignment that hourly billing creates, nobody should feel like scope creep is quietly draining their budget, and nobody should feel like they're leaving money on the table for extra work that wasn't priced in.

Step 4: One Round of Revisions, Before Signing

If something in the proposal needs adjusting, the scope's off, the timeline's tight, the price needs discussion, that happens now. On the proposal itself. Before anything is signed, before any code is written.

This is the last checkpoint where changes are free. Once the proposal is signed and work starts, changes stop being a conversation and start being a negotiation.

Step 5: Sign and Start

Once everything's agreed, the actual building begins. No ambiguity carried forward. No "we'll sort that out later." Both sides know exactly what's being built, by when, and for how much.

Why This Matters More Than It Seems

None of these steps are complicated. They're not clever tricks, they're just the basic discipline of agreeing on something before committing to it. What makes them easy to skip is that skipping them feels faster in the moment. Writing a brief feels like a delay when you could just be building. A proposal feels like paperwork when you could already be coding.

But the delay is the point. I'd rather spend an extra day getting the scope right than a week rebuilding something because it didn't get talked through first. The day spent upfront is cheap. The week spent fixing a misunderstanding is not, and it usually costs the relationship along with the time.

If you've got a project in mind and want to see if this process fits how you like to work, send me the brief. Let's see if it's a good fit.

I'm a full stack developer working in NodeJS, TypeScript, and NextJS. Find me on LinkedIn or check out my work at jealous.dev.