Define the Business Process Before Writing Code

Here's a pattern that kills early-stage products: the team gets excited about a feature, jumps into code, ships something-and then discovers the business process underneath was never actually defined. Support tickets flood in. Edge cases multiply. Three months later, they're rewriting everything.

Software doesn't create processes. It automates existing ones. If the process can't be executed manually and documented clearly, it's not ready for code.

The Manual-First Rule

Before touching the codebase, make sure the team can answer: "How would we do this with spreadsheets and email?" If the answer is unclear or disputed, that's a red flag. Building software on top of undefined processes just automates confusion.

Companies that move fast often skip this. "We'll figure it out as we build." But code is expensive to change. A document is free to edit. The documentation step feels slow, but it's the fastest path to shipping something that actually works.

What Gets Documented

For any business feature, capture:

The outcome: Not "build a dashboard" but "reduce time-to-decision from 3 days to 4 hours." Metrics matter.

Triggers and inputs: What event starts this process? What data is required? In what format? Who provides it?

The manual flow: Step-by-step, as if no software existed. Include the exceptions-they're where complexity hides.

Roles and decisions: Who approves? Who escalates? Who gets notified when something fails?

Outputs: What does "done" look like? What artifacts are produced?

Constraints: Compliance requirements, SLAs, rate limits, audit needs.

Red Flags: Too Early to Build

• Stakeholders disagree on the steps
• No clear success metric
• Exception handling is hand-waved ("we'll deal with that later")
• The process changes weekly

When these are present, building software is premature. The team needs alignment first.

The Documentation Format

Nothing fancy:

• A flowchart or diagram (whiteboard, Miro, even paper)
• An input/output table per step
• A "what if" matrix for errors and edge cases
• Sign-off from whoever owns the process

This artifact becomes the spec. Engineers build against it. QA tests against it. When the business changes, the document updates first-then the code follows.

Why This Works

Fewer surprises: Edge cases surface before they're bugs in production.

Faster development: Engineers aren't guessing requirements mid-sprint.

Easier changes: When the process evolves, you update the doc and know exactly what code needs to change.

Better communication: Product, engineering, and ops share the same mental model.

Then-and Only Then-Code

With a clear process documented, the technical design falls into place: API contracts, database schemas, event flows, access control. The code mirrors reality instead of inventing it.

Skipping this step doesn't save time. It borrows time from the future-with interest.