Architecture Decision Sprint / ADS 01

The idea is valid.
Make it buildable.

A fixed-scope decision sprint for a future product, platform, or major workflow facing an expensive build, integration, rewrite, or architecture choice before production complexity becomes permanent.

Scope
One product or critical workflow
Timeline
Five working days
Output
Buildable decision package
Fee
Starting at $5,000, fixed after scope

The next architectural choice is expensive to reverse.

  • The prototype proved demand.Now the team needs a production shape that can survive real users, data, integrations, and operational constraints.
  • A critical workflow crosses boundaries.Backend, mobile, data, external services, devices, or AI all participate, but nobody owns the whole decision.
  • The team has competing designs.Strong opinions exist, but tradeoffs, constraints, and decision criteria are still implicit.
  • A rewrite is being discussed.You need to know what must change, what should remain, and how to avoid pausing product progress.

A buildable decision, not a diagram collection.

  1. 01
    System and workflow model

    Actors, state, boundaries, critical paths, integrations, and ownership in one legible model.

  2. 02
    Decision record

    Options, constraints, tradeoffs, rejected paths, and the reasoning the team can revisit later.

  3. 03
    Risk and validation plan

    The assumptions that should be tested before the team commits to the expensive parts.

  4. 04
    Implementation sequence

    A practical first 30 days with boundaries, milestones, and decisions that should wait.

Enough depth to commit without pretending uncertainty is gone.

Day 0

Frame

Goal, users, constraints, existing evidence, and the decision that cannot remain vague.

Days 1-2

Model

Workflow, state, boundaries, dependencies, failure surfaces, and viable options.

Days 3-4

Decide

Tradeoffs, validation needs, target architecture, and implementation sequence.

Day 5

Commit

Readout, challenge session, final decision package, and clear next actions.

The sprint decides week one so implementation can compound.

Week 1

Commit to a buildable decision

System boundaries, contracts, risks, rejected paths, validation needs, and an executable first sequence.

First month

Prove the architecture vertically

Run one real workflow through data, integrations, deployment, tests, observability, and failure handling.

First 6 months

Grow a platform, not a prototype pile

Add product surfaces and integrations through explicit seams, repeatable releases, and ownership the team can carry.

The sprint delivers the week-one decision package and implementation sequence. Later horizons describe the intended trajectory, not bundled implementation or a guaranteed schedule.

See how the decision
takes shape.

This illustrative example uses a fictional field-service product. It shows how the sprint narrows scope, compares options, and turns tradeoffs into an implementation sequence.

See an example deliverable

Enough structure to start without a procurement project.

What access do you need?

Usually a forty-five minute scope call plus the product brief, existing diagrams or decision notes, and focused access to the people or evidence closest to the decision. Access boundaries and NDA requirements are agreed before work begins.

What if our documentation is incomplete?

That is common. Existing documents are useful evidence, not an entry requirement. I reconstruct the critical workflow from conversations, code or prototypes, interfaces, constraints, and observed behavior.

How much team time does the sprint require?

Plan for the initial scope call, short targeted conversations during the week, and a Day 5 challenge and readout session. I do the analysis and synthesis directly.

What happens if the wrong question is being asked?

I reframe it before the sprint starts. If a five-day architecture decision is not the useful next step, I will say no-fit and explain the smaller validation or operational work that should happen first.

Can you help implement the decision?

The sprint is a decision engagement, not bundled implementation. If hands-on follow-through is useful, we define it separately after the team has reviewed and accepted the decision package.

Bring the decision
that keeps moving.

Share the product context and the decision that keeps moving. I will reply with fit or no-fit, the next useful step, and a fixed fee if the sprint fits. NDA and access boundaries are agreed before work begins.

Send me the decision