# Resolve the question before funding the build.

> The purpose of a Decision & Architecture Sprint is to replace expensive uncertainty with a grounded implementation decision. It is not an invitation to hold unlimited strategic meetings.

Canonical URL: https://marmation.com/engagements/decision-and-architecture-sprint/

## The decision

Which unresolved choice is expensive enough to settle?

Use a paid sprint when an unresolved choice could make the build expensive to get wrong. You should finish with a recommendation you can act on, the reasons other options were rejected and a clear account of what still needs testing.

## Budget is available, but the approach is unsettled

A company has budget for an AI initiative, but who controls the data, where the AI model may run and what the first version should do are unsettled. Three teams recommend different platforms and nobody has yet defined what must be true for a successful first version.

## An estimate cannot resolve an unanswered design question

A rushed estimate will hide assumptions. An enormous transformation roadmap may take too long and still leave the real architectural decision open.

## Compare the choices and recommend the next step

Agree the question and the time allowed for answering it. Interview necessary owners, review constraints and available technical evidence, compare feasible options and produce a decision record and proposed first build milestone.

## What the decision record may cover

- A Business Job Charter: a written account of the task, who it serves and how success will be measured.
- A map of existing systems, data and user access, including risks and the dependencies the build needs.
- Build/buy/extend options with cost and implementation considerations.
- A recommended system design, a plan for checking the result and a proposal for the first build milestone.


## Use the discovery you already have

If the client has enough discovery and architecture material, do not resell it. If the answer depends on an untested technical question, agree a short practical investigation, often called a feasibility spike. Its findings should inform the recommendation.

## A recommendation you can act on

You should be able to explain the recommendation to another decision-maker: what to do, why the other options were rejected and what remains uncertain. The record should support a decision and a practical first implementation scope.

## Bring the decision that needs resolving

Share the problem, systems involved and the decision needing resolution. We can determine whether a paid sprint is appropriate.

## Related reading

- [Clarity before code. Accountability through delivery.](https://marmation.com/approach/)
- [Build, buy, extend or integrate? The AI decision that comes before the technology.](https://marmation.com/review/build-buy-extend-or-integrate/)
- [Improve the system that ships software.](https://marmation.com/engagements/ai-native-team-pilot/)