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

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
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.
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.
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.
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.
Other case studies
Product · 2021–2022WallStreetBets
From thesis to live portfolio products in thirteen months, with a campaign that logged 13,806 visits against a 1,000-a-day goal.
Read the case study →
Prototype · 2021–2022Arkade
A full marketplace rebuild with a new name and brand, while a PHP developer kept the old revenue-earning site patched.
Read the case study →Brand · 2017–2020KeepKey
Brand, manufacturing spec, honest usability review and a six-step security check for the KeepKey hardware wallet.
Read the case study →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.
30 minutes with Phil or Martin. No technical brief, no pitch deck. Phil or Martin replies personally, usually within one business day.