Context and decision
The standard story about AI and incumbents is that the incumbent is slow. It is usually wrong about the mechanism. An established software business with a large installed base, a working sales motion, and a known cost per customer is not slow because it lacks the technology. It is slow because most of its advantages are attached to the shape of its current product, and a repositioning writes some of them off.
That is the decision this scenario isolates. A fictional incumbent, RelayWorks, sells project-management seats. A fictional challenger, TaskPilot, sells completed work bundles at a price that only makes sense if the work is largely automated. Both are chasing the same 1,000 teams, split between 800 small teams and 200 enterprise teams that weigh price, switching cost, and reliability differently.
The visitor takes one side for four quarters, commits to one primary move per quarter, and watches customers, revenue, delivery cost, and cash resolve. Then the interesting part: they take the other side and attack the strategy they just recorded.
Alternatives considered
Write a strategy note instead of building a game
ForThe reasoning is the point, and prose is faster to write, easier to review, and easier to cite.
AgainstA reader cannot disagree with a note in any specific place. A reader who has committed to a decision and watched it resolve has a sharper objection than a reader who has only nodded along.
Model a real, named company
ForRecognisable revenue and margin figures would make the exercise concrete immediately.
AgainstIt would invite the reader to audit a forecast instead of the reasoning, and any numbers I picked would read as claims about that company. A fictional market keeps every assumption arguable and unambiguously mine.
Let a language model resolve each round
ForGenerated narration and competitor dialogue would make the world feel much richer.
AgainstAn outcome nobody can reconstruct is not evidence. Resolution stays deterministic; generated dialogue can sit on top of an already-resolved result later, but it cannot be the resolution.
Method and model
The engine is deterministic and small enough to read. Each quarter, segment demand is allocated by comparing the two offers on price, fit, and reliability; allocations produce revenue; revenue and volume produce delivery cost; the player's committed investment draws down cash with a stated lag before it changes capability. Nothing inside a round is random.
Three environment presets are disclosed up front rather than sprung on the player, so a run can be replayed under identical external conditions. That is what makes the role reversal meaningful: the second run differs because the strategy differs, not because the world rolled differently.
Every parameter is a fictional design assumption, written in one file and printed on a methodology page. The point is not that these are the right numbers for the software market. The point is that they are visible, so a disagreement can be about a specific number rather than about vibes.
Evidence and results
The scenario runs. It resolves four quarters of commitments into a ledger that shows the arithmetic behind each line and links it to the formula that produced it, and it states its segment totals explicitly rather than leaving them to be inferred. It is deployed and open to anyone, so everything claimed on this page can be checked against the running scenario instead of taken on trust.
There are still no results, and a demo that runs is not one. No playtest has been run, no player has been observed, and no outcome study has been recorded. Publishing a chart here would mean fabricating one.
What does exist is listed under Evidence on this page: the seeded parameter set, the resolution rules that the engine now implements, and the concept schematic above. All three are illustrative — they describe a specified and working design, not an observed outcome.
Seeded market parameters
IllustrativeTwo segments — 800 small teams and 200 enterprise teams — with fixed opening customer counts, annual contract prices, and per-quarter variable costs for both sides. Fictional scenario values held in one editable file.
Sources: src-dtb-brief
Resolution rules
IllustrativeCustomer choice, revenue, delivery cost, investment, and cash resolve from documented formulas each quarter, with no hidden randomness inside a round. Replaying identical conditions produces identical results. The rules are implemented and the engine resolves them; the ledger cites the formula behind every line it prints.
Sources: src-dtb-brief
Concept preview schematic
IllustrativeThe decision scene shown on this page. Drawn from the specification to communicate structure. It shows the shape of the exercise, not the result of one.
Sources: src-dtb-schematic
Interpretation
The interpretation this project is set up to test is that an incumbent's defensible position under a cheaper substitute is usually narrower than its current product, and that the expensive mistake is defending the whole surface rather than choosing the part worth keeping.
That is a hypothesis with a clear failure mode: if the seeded scenario lets a broad defence win comfortably under all three presets, the hypothesis is wrong for this market as parameterised, and the honest move is to say so and publish the parameters that produced it.
Trade-offReconstructible over realistic
Every quarter resolves from stated formulas. That rules out the emergent surprise of a real market, and it is what makes the model criticisable instead of merely plausible.
Trade-offTwo segments over a full market
Small teams and enterprise teams behave differently enough to create a real positioning problem. A third segment would add arithmetic without adding a decision.
Trade-offOne market over a general simulator
A tool that accepted any company would have to guess at economics it was never given. One fully specified market can be defended in detail.
Limitations
The market, the companies, and every economic parameter are fictional. Nothing here forecasts the real project-management market or any real company.
The model reports operating cash flow from a simplified structure. It is not EBITDA, not audited profit, and not comparable to a reported financial statement.
A rules-based opponent does not learn. Beating it demonstrates something about the stated rules, not about a competitor that adapts.
OpenWhether the horizon is long enough
Four quarters keeps a session under ten minutes. It may be too short for the incumbent's installed base to matter, which would quietly bias the scenario towards the challenger.
OpenWhether the reversal reads as a test
Switching sides is meant to feel like being cross-examined by your own earlier decisions. It may instead read as a fresh game with the numbers rearranged.
OpenWhether the opponent is legible
A rules-based opponent has to be predictable enough to reason about and varied enough to be worth reasoning about. Where that line sits is not yet known.
Next test
Run the first honest test — play the seeded scenario from both sides under each preset, and record whether any commitment sequence survives its own reversal. Publish the ledger alongside the analysis so the result can be checked.
Then take it to five playtesters, ask each to explain one trade-off in their own words afterwards, and report the sample size rather than a percentage.
Sources
src-dtb-brief Disrupt This Business — business requirements, version 1.0
Owner-authored specification dated 6 September 2026, held in this repository at docs/01_Disrupt_This_Business_BRD.md. Defines the market, the seeded parameters, the resolution rules, and the release boundaries. All scenario companies and figures in it are explicitly fictional design assumptions.
src-dtb-schematic Concept preview schematic (original)
Original SVG drawn for this site from the specification above, held at components/schematics/disrupt-this-business.tsx. Contains no measured values.