Not sure where AI would pay off? Take the 3-minute opportunity check →
Case study · BUSTA · 2021–2022

Six companies built one game. We kept track of what actually worked.

BUSTA was a gaming platform on Binance Smart Chain with a crash game, a token exchange and an affiliate program, built by six organizations at the same time. We owned product direction, project management, DevOps and QA, and after a public four-day outage we replaced guesswork with measured limits.

  • Product direction
  • Project management
  • DevOps and cutover
  • QA and test records
  • Load testing
120Recorded smoke-test runs on the live game
350Safe concurrent users after the second load test
44Scenarios in the partner-token mainnet pass
BUSTA project screens

The challenge

Six organizations worked on BUSTA at once: the product owners, a core game studio, an exchange team, a smart contract shop, an interface team, and us. Work was split across Trello and Asana. Each team could do good work and the product could still fail, because no single party saw the whole thing.

Then it did fail in public. Starting 3 September 2021, players could not deposit or withdraw on the crash game for four days, and the manual workaround did not help. Every game instance shared one database, blockchain writes were running ten times a second, and the exchange launched the same week, adding traffic to servers nobody had measured.

What we did

  1. One shared picture of the build

    From July 2021 we merged feature lists from every vendor into one view with an owner and a status per task. We wrote weekly status reports and recorded sprint demos on staging, so the product owner heard one account of progress instead of five.

  2. Launch by checklist

    The mainnet cutover ran off a written list: the exploit fix merged, secrets moved to a managed store, the database rotated, the endpoint moved to its live address. Outside auditors tested the beta before launch, and their findings arrived on beta day rather than after go-live.

  3. Write the failure down

    Three days into the outage we wrote an internal failed transactions report. It named the shared database, the write rate, a risky library upgrade and unanswered load-test requests. Its conclusion was that load testing would have prevented it.

  4. Measure, then keep measuring

    We ran a formal load test in September and again in October with the same method. We also kept a production smoke-test workbook of nine steps per run, from wallet connect to withdrawal, against the live game rather than staging.

The result

The first load test set the safe ceiling at 120 concurrent users. Four weeks later the second put it at 350. The smoke-test workbook holds 120 production runs and 1,422 result cells: 1,312 passes, 9 failures and 101 not tested. The first run failed at step one because the wallet would not connect. Most runs after it are green.

A 44-scenario mainnet pass covered partner-token listing before any partner used it. When we checked in September 2026, busta.gg and the crash game were both still live.

What this means for your business

When several vendors build one system, someone has to own the true state of the whole thing, not just their slice. Know your capacity before you add users, and keep test records that show failures as plainly as passes. That record is what lets you fix problems instead of arguing about them.

This project was delivered by the Innovation Theory team, the Denver firm behind InTheory, before InTheory existed as its AI practice.

Next step

Bring one expensive workflow. Leave with a clear next step.

In 30 minutes we look at one recurring workflow, what it costs you today and whether there is a credible case to improve it. If there is not, we will say so.

Book a 30-minute workflow review Not ready to talk? Take the 3-minute check

30 minutes with Phil or Martin. No technical brief, no pitch deck. Phil or Martin replies personally, usually within one business day.

Book a 30-minute review