No Work Without Intent: The Contract We Write Before We Write Code

This week a startup founder pushed back on a requirement in their Intent Contract.

The team is days from their MVP launch, working through the onboarding flow: the steps a new user takes from signup to their first meaningful action in the product. The founder’s position was clear: minimize friction, get users into the system fast, no email verification gate before access. Sign up, get in, experience the value. Every extra step is potential drop-off.

It’s a reasonable instinct. But we had an IC open in front of us, and two fields made the argument the founder needed to hear.

Thanks for reading! Subscribe for free to receive new posts and support our work.

“Known constraints” had captured that the system’s core value depends on users being real and reachable: spam accounts and fictitious users don’t just inflate a number, they break what the product is actually trying to do. And “What success looks like” — which the founder had written — read: “A new user reaches their first meaningful action in under three minutes.”

Put those two fields together and the question answers itself. Can the product deliver that outcome to a fictitious user? No. The value depends on the user being verified. We didn’t debate it. We went back to the intent, and the intent settled it. Email verification before access.

The IC didn’t make that call — the founder did, when they wrote down what success actually meant. This is what the Intent Contract is for.

The pattern that makes it necessary

Skip opened this series by naming the failure mode he’s watched repeat across client engagements: teams moving fast, getting real output, and then fraying around week six because the system underneath isn’t holding the work together.

In my experience, the failure usually starts earlier than week six. It starts at the beginning, when the team doesn’t write down what they’re actually trying to do.

This isn’t negligence. The people who skip this step aren’t lazy. They’re confident. They’ve talked through the feature. Everyone nodded. The vision feels shared. And then someone starts building what they understood, which turns out to be slightly different from what the person next to them understood.

When that divergence surfaces three weeks in, nobody’s wrong and nobody’s lying. They just had different mental models, and nobody made those models explicit at the start.

The CRAFT Constitution’s first law is “No work without Intent.” The Intent Contract is the artifact that makes that law operational. It’s a structured document that every piece of work at InTech is required to produce before a keyboard gets touched. Not because we don’t trust our teams. Because making intent explicit before work starts is the cheapest time to do it.

What the Intent Contract is (and isn’t)

The IC is not a requirements document. It’s not a product spec. It’s not a project plan.

It’s a single page that captures the minimum shared understanding needed to start work without flying blind. Seven fields. Most teams can fill it out in twenty to thirty minutes.

The goal is not completeness. The goal is surface area: finding the gaps, misalignments, and open questions before they become expensive.

It is not a contract in the legal sense.It’s a contract in the coordination sense. A shared agreement about what we’re doing and why, documented so we can hold ourselves to it and revisit it when something changes.

It does not replace conversation.It creates better conversation. The fields are designed to ask questions that don’t get asked in a typical kickoff, and the gaps in the document tell you exactly where the team needs to slow down.

It changes when the work changes.If a new constraint surfaces, a scope change gets approved, or an open question gets resolved in a way that shifts direction, the IC gets updated. A stale IC is worse than no IC. Date the document. Set a review trigger.

The seven fields

What we’re building.Not the feature name. Not the Jira ticket title. A specific description of what will exist when this work is done that doesn’t exist now. “A dashboard” is not an answer. “A client-facing dashboard that shows week-over-week revenue by product line, filterable by date range and account, accessible to users with the ‘reporting’ role” is an answer. The specificity is the point.

For whom.Not “users.” A specific person or role, with enough context to understand their situation. “Our ops team, who currently exports a CSV every Monday morning and reformats it in Excel for the weekly business review” is useful. “Users” is not.

What success looks like.The measurable outcome. What changes, for whom, and by how much.

If you can’t write a sentence that would let someone outside the project verify whether this feature succeeded three months from now, you don’t have a success definition. You have a hope.

What we are NOT building.This is the field teams skip most often, and the one that saves the most rework. Explicitly naming what’s out of scope removes the assumptions that generate the most expensive disagreements. In the onboarding session above, an explicit entry like “No access before email verification; guest mode is not in scope” would have surfaced that constraint conversation before anyone had written a line of code toward the other assumption.

Known constraints.Technical constraints, timeline constraints, compliance requirements, dependencies on other systems or teams. These are non-negotiable facts about the environment the work lives in. If AI is going to be writing code for this feature, note which parts of the stack have constraints on how it can be used.

Open questions.Things that must be answered before work starts, with a named owner and a deadline.

An unanswered open question is a decision waiting to happen. If you start work with unresolved questions, those questions will get answered eventually: by whoever gets to them first, without the rest of the team in the room, without documentation, and often at the worst possible time.

Owner.One person. Not the team. Not “product and engineering jointly.” A single person who is accountable for this intent, who will notice if the work drifts from it, and who will update the document when something changes.

Generating a first draft with Claude

One pattern we’ve built into our workflow: before the IC session, someone generates a rough draft using a Claude prompt. The draft is not the output. The gaps and mismatches in the draft are the output. They tell the team exactly where the real questions are.

Here’s the prompt we use:

You are helping a software team write an Intent Contract before beginning a new feature. An Intent Contract captures: what we’re building, for whom, what success looks like, what is explicitly out of scope, known constraints, and open questions. Based on the following conversation notes, generate a first-draft Intent Contract using these seven fields: What we’re building / For whom / What success looks like / What we are NOT building / Known constraints / Open questions / Owner. For any field where the notes don’t give you enough to fill it in confidently, write “Needs resolution” and explain what’s missing. Format it clearly. The gaps are as important as the filled fields.

[Paste meeting notes, Slack thread, or conversation summary here]

The team reviews the draft together, not to accept it, but to react to it. Every “Needs resolution” flag is a conversation starter. Most of the meaningful alignment work happens in those conversations.

What this catches

Three months is a short sample. But the pattern the IC catches isn’t new: it’s the same misalignment I’ve watched cause rework across years of client engagements. What CRAFT gives us is a name for it and a mechanism to surface it early. Across the teams running the IC since January, the same three categories of problem surface consistently: misaligned success definitions, hidden scope assumptions, and open questions that everyone assumed someone else was going to answer.

The third category is the most interesting. Most teams don’t know which questions are open. They think alignment exists because the conversation felt aligned. The IC makes open questions visible by requiring them to be named. A team that can fill in every field without a “Needs resolution” either has genuinely tight alignment, or hasn’t looked hard enough.

Both possibilities are worth knowing.

I’m not going to claim that twenty minutes on an IC will eliminate misalignment on every project. What I can say is that every significant rework event I’ve investigated across our client engagements had something in common: nobody had written down what success looked like before the work started.

Next week I’ll cover the Decision Record: the artifact that captures not just what you decided, but why, what you considered, and what would cause you to revisit it. The payoff isn’t visible in week one. It’s visible six months later, when you’re debugging something that was “decided in a meeting” and nobody can find the reasoning.

If this resonated, subscribe. We’re writing about what’s actually changing in software delivery, no hype, no hand-waving, just what we’re seeing on real projects.

Take-Home: Intent Contract Template + Claude Prompt

Intent Contract Template

Project/Feature:[Name or short identifier]

What we’re building:[A specific description of what will exist when this is done that doesn’t exist now. Not the ticket title. The deliverable.]

For whom:[Specific person, role, or user segment with enough context to understand their situation. Not “users.”]

What success looks like:[Measurable outcome. What changes, for whom, by how much. Someone outside the project should be able to verify this three months from now.]

What we are NOT building:[Explicit scope boundary. What might seem in scope but isn’t. What existing workflows stay in place.]

Known constraints:[Technical, timeline, budget, compliance, or dependency constraints. Non-negotiable facts about the environment.]

Open questions:[Things that must be resolved before work starts. Each question gets a named owner and a deadline for resolution.]

Owner:[One person accountable for this intent. Not the team. One person.]

Created:[Date]Review trigger:[What would cause us to revisit this: a new constraint, a scope change, a resolved question that shifts direction]

Claude Prompt: First-Draft IC from Conversation Notes

You are helping a software team write an Intent Contract before beginning a new feature. An Intent Contract captures: what we’re building, for whom, what success looks like, what is explicitly out of scope, known constraints, and open questions.

Based on the following conversation notes, generate a first-draft Intent Contract using these seven fields:

1. What we’re building
2. For whom
3. What success looks like
4. What we are NOT building
5. Known constraints
6. Open questions
7. Owner

For any field where the notes don’t give you enough to fill it in confidently, write “Needs resolution” and briefly explain what’s missing. Format it clearly. The gaps are as important as the filled fields.

[Paste meeting notes, Slack thread, or conversation summary here]

Thanks for reading! Subscribe for free to receive new posts and support our work.