Working software before the major commitment.
- 2–3 wks
- Time to a decision
- $20–45K
- Illustrative range
- Code
- Handed to you
People about to commit real money.
A sprint is worth the most when the number is large, the claims are hard to verify, and being wrong is expensive.
A CIO weighing a multi-year platform commitment
An enterprise applications leader comparing build against a vendor
A PE operating partner pressure-testing a portfolio thesis
A product leader whose internal estimate feels like a guess
What actually happens across the sprint.
Before a line of code, we get precise about the question the money is actually riding on.
- 01Clarify the operating question in one sentence
- 02Map the current process as it truly runs
- 03Identify the people who would use the solution
- 04Select realistic data to exercise the workflow
- 05Define the criteria a good decision must meet
- 06Name the riskiest assumptions first
Four inputs. That is the ask.
The decision
The build, buy, reshape, or stop question on the table.
Access to reality
A few people who actually run the process today.
Realistic data
A representative slice — anonymized where it must be.
The commitment
The deadline, contract, or budget approaching.
We build the thing, then let reality push back.
The prototype runs on data that looks like yours — real volumes, real edge cases, real messiness — not a tidy sample chosen to make a demo look good. That is what exposes the integration assumptions and vendor gaps that slideware hides.
Then we put it in front of the people who would actually use it and watch what happens. Where they hesitate, where they route around it, and what they reach for instead is the evidence.
Process evidence
How the real workflow behaves under the new system.
User evidence
Where real users succeed, stall, or resist.
Technical evidence
Which integrations hold and which break.
Economic evidence
The honest cost of build versus buy.
Decision Evidence changes what enters the room.
The steering committee should not have to choose from documents, vendor claims, and estimates alone.
What enters today
- Requirements
- Vendor claims
- Reference calls
- Estimates
- Scoring matrices
- Assumptions
Separate, incomplete sources that never resolve into one picture.
One artifact
The Decision Record
Every fragmented input, resolved into a single evidence-backed artifact the committee can actually decide from.
What a sprint produces
- Working system
- Observed user behavior
- Tested assumptions
- Vendor gap conditions
- Technical-risk findings
- Economic scenarios
- Recommendation
- Code
We do not add a prototype to the process. We replace speculation inside the process.
The evidence, assembled into one instrument.
Change the evidence lens and watch the viable paths move with it, while the recommendation and its conditions stay in view. This is how a decision looks when it is backed by working evidence instead of assertions.
Illustrative Decision Record
Decision
Regional operations platform
Owner
VP, Regional Operations
Commitment approaching
Multi-year platform agreement
Recommendation
Buy with conditions
Confidence
Substantial
Material conditions
3 unresolved
Decision question — Should the organization buy a commercial platform, build a specialized workflow, reshape the operating model, or defer the commitment?
Recommendation
Buy with conditions
Conditions for approval
- Offline workflow must be demonstrated
- Second-review approval must be contractually supported
- Ledger integration must pass a controlled pilot
Conditions for stopping
- Offline completion cannot be supported
- Integration ownership remains undefined
- Required customization exceeds the agreed threshold
Next action
Run a controlled pilot against the three material conditions.
What was tested
The end-to-end dispatch workflow, run against realistic regional operating data.
What was observed
Dispatch coordinators treated live status visibility as essential to the workflow, and completed the core path without workarounds.
What remains unresolved
Whether the same path holds when connectivity drops in the field.
Decision paths
- BuyConditional
- BuildViable
- ReshapeViable
- PilotViable
- DeferConditional
- StopUnsupported
Path viability shown for the Workflow lens.
Illustrative evidence scope
- Multiple assumptions tested
- Material findings identified
- Three unresolved conditions
- Core workflows exercised
- Technical paths tested
- Named evidence owners
Scope and states are illustrative and internally consistent — not measurements from a real client engagement.
Four honest paths — and we will recommend against building.
Build
The gap is real and no vendor closes it. Now you have a running head start.
Buy
A vendor genuinely covers it. We will say so, and save you the build.
Reshape
The problem was framed wrong. The prototype shows the better shape.
Stop
The initiative should not proceed. Finding that out early is the win.
AI Decision Sprint
Test the workflow before scaling the technology.
A focused evidence cycle for organizations evaluating copilots, agents, intelligent automation, decision support, document intelligence, or AI-enabled operating workflows. Most organizations do not have a shortage of AI ideas — they have a shortage of tested evidence about which ideas belong in the operating model, what conditions they require, where human judgment remains necessary, and whether the economics justify scaling them.
The AI Decision Sprint uses the same Praxis Decision Evidence System — not a separate methodology. AI is treated as one possible component of an operating solution, never the automatic answer.
The question is not whether AI can be inserted into the workflow. The question is whether it improves the operating model enough to justify the data, integration, governance, adoption, and accountability burden.
Situations we are brought into
- Leadership has committed to an AI agenda, but the highest-value workflow is still unclear.
- A vendor demo appears compelling, but its performance on the organization’s data has not been tested.
- The business case assumes accuracy, adoption, and labor savings that have not been observed.
- Teams are proposing copilots or agents without defining human accountability.
- The organization cannot yet distinguish a useful AI feature from a sustainable operating capability.
Recommendations a sprint can reach
- Proceed to pilot
- Buy and configure
- Integrate with an existing platform
- Build a specialized capability
- Redesign the workflow first
- Retain human execution
- Defer
- Stop
The same honest range as any sprint — including deferring or stopping when the evidence does not justify scaling.
The AI evidence lens
Applied only when the decision involves AI, layered onto the standard evidence types.
Workflow fit
Data readiness
Model reliability
Human oversight
Integration feasibility
Security and governance
Unit economics
Operational failure modes
Conditions for scaling
Conditions for stopping
You leave with the work, not just an opinion.
Working prototype
Exercisable on your real scenarios, not a demo reel.
Real-user testing
The people who would operate it, put in front of it.
Technical-risk findings
Which integrations hold and which break.
Vendor gap analysis
Where the market genuinely covers it, and where it does not.
Economic path comparison
The honest cost of build versus buy versus reshape.
Decision Record
The evidence, assumptions, and reasoning in one executive artifact.
Written recommendation
Build, buy, reshape, defer, or stop — with the reasoning shown.
Code & asset transfer
Handed over. You keep the work whether you continue or not.
A sprint is not a full production build. It is the evidence and the working starting point that make the production decision defensible.
A fraction of the commitment being evaluated.
- $20K–$45K
- Decision Sprint
- $500K–$10M+
- Typical commitment evaluated
- 2–3 weeks
- Time to a decision
- Evidence + recommendation
- What you leave with
All figures are illustrative planning ranges, scoped against the specific decision — not a fixed price list.
The questions committees ask.
No. A sprint produces a working, data-realistic prototype to answer a decision — not a hardened, production-scale system. The point is to reduce the risk on a large commitment before you make it. If the answer is build, the sprint gives you a running head start and the code to continue from.
Engagements typically range from $20K to $45K. That figure is illustrative and scope-dependent — a narrowly framed decision costs less than one that spans several integrations and user groups. We scope against the decision, not by the hour.
The evidence, the recommendation, and the code. A sprint that ends in a well-reasoned "buy" or "stop" is a successful sprint. Deciding not to build early is often the most valuable outcome we deliver.
Consultants produce documents about software. We produce the software, put it in front of real users, and let the reactions and the integration reality generate the evidence. The recommendation is grounded in a thing that actually ran.
A decision owner, and a small number of people who genuinely understand the current process. We do the building. You bring the reality — the workflow, the data, and honest access to how work happens today.
Bring us the decision you cannot afford to get wrong.
We will scope a sprint against the specific question you are facing and tell you honestly whether a sprint is the right instrument for it.
Two to three weeks from question to evidence.