Most of the engagements we take on at Nexus Dev are six weeks long. That's not because six weeks is magical — it's because it's long enough for a small team to ship something real, and short enough that the client can keep a clear mental model of what's happening week by week.

This post is a tour through how one of those engagements gets scoped — from the first discovery call to a signed statement of work. Most of the value here is in doing the steps, in the same order, every time. Nothing in this post is new; it's just what's worked for us across roughly thirty engagements since 2021.

Why six weeks

Two weeks is a sprint; a sprint is barely enough time to debug an environment, let alone ship. Three months starts to feel indefinite — momentum slips, and mid-engagement rewrites become tempting. Six weeks is the sweet spot where we can do meaningful work without the scope creeping sideways.

It's also, bluntly, the shortest engagement length where we can price in the unavoidable messiness of real systems and still come out fair on both sides. Anything shorter starts to look like consulting-theater: lots of slides, not enough shipped code.

A six-week engagement isn't a deadline — it's a shape. It tells us what the work can afford to include and what it has to leave out.

— from our internal engagement playbook

Step 1 — Discovery call

The first call is always a conversation, not a pitch. We don't present slides. We ask three questions and then mostly listen:

  • What does "done" look like? If the answer is fuzzy, we work on making it concrete before talking about timelines.
  • Who inside your company has to say yes for this to ship? Knowing the approval chain up front prevents surprise rewrites in week five.
  • What have you tried already, and why didn't it work? This one surfaces constraints — technical, political, budgetary — that don't come up in a pitch.

We take notes during the call and share a written summary within 24 hours. The client responds with corrections. That written summary is the seed of everything that follows — if we get it wrong, everything downstream drifts.

Step 2 — Shaping the work

Before writing any estimate, we spend a day or two shaping the problem — essentially, writing a short document that describes the solution at an architectural level, not a task level. What systems are touched, what integrations are needed, what's deliberately out of scope.

A shaping document usually ends up around a page and a half — short enough to read in a single sitting, detailed enough to catch the big surprises before they become invoices.

The shaping document is the most valuable artefact we produce. It's where we decide the engagement is feasible, or where we decide it needs to be smaller. We share it with the client before any numbers are quoted.

Side note

We occasionally write shaping docs we don't get paid for. It's worth it — half the time the client can use the document as-is to shop around, and the half that come back to us come back with a much clearer ask.

Step 3 — Writing estimates

Only after the shaping document is accepted do we produce an estimate. Our estimates are deliberately coarse — we quote in weeks, not hours, and we quote ranges, not points. "Two to three weeks" is an honest estimate; "17.5 hours" is theatre dressed up as precision.

We also track a small set of categories where our estimates historically go wrong:

  • Integrations with third-party systems we haven't touched before (add 30%).
  • Anything that involves a client’s internal auth or SSO layer (add 50%).
  • Data migrations where we can't see the source data in advance (add 100%).
  • "It should be easy, we just need…" followed by anything (reread the shaping doc).

Every engagement gets a verdict sheet at the end where we compare the estimate to what actually happened. Over three years that sheet has become our most accurate prior.

Step 4 — The SOW

The statement of work is short — usually two pages. It contains exactly four things: what will be delivered, what will not be delivered, the timeline, and the cost. It does not contain a list of tasks. Tasks change; outcomes don't.

Signing the SOW is gated on one thing: the client and we both can restate the scope out loud without reading from the document. If we can't, the SOW isn't specific enough yet and we keep working on it.

{
  "engagement": "checkout-v2",
  "duration_weeks": 6,
  "deliverables": ["payments-refactor", "pci-audit-prep"],
  "out_of_scope": ["mobile-app", "subscription-pricing"],
  "price_range": "USD 72,000 - 84,000",
  "signed": "2026-04-19"
}

What we deliberately skip

We don't do fixed-bid contracts for work that's less than 90% clear up front. That's not an ideological position; it's a scar. We lost money on our first two fixed-bid engagements because we underpriced the risk we were absorbing, and the client wasn't any happier for it.

We also don't do engagements shorter than three weeks. A two-week engagement is just a consulting-call with extra typing.

Takeaways

If you're thinking about adopting something like this — either as a studio yourselves, or as a client procuring engineering work — the three things that matter most, in order:

  1. Shape before you estimate. Most bad estimates are actually bad shaping in disguise.
  2. Quote in weeks, not hours. Coarse estimates are more honest and easier to defend.
  3. Keep the SOW short and outcome-oriented. Task lists turn into arguments; outcomes turn into shipped work.

We're still iterating on all of this. If you run a similar process and want to compare notes, drop us a line. Especially interested in how other studios handle the shaping-doc step, which we still think has room to improve.