Executive Summary
In late 2025, a Tier-1 payment processor (referred to throughout this paper as "the Client," for reasons our legal team insists on) approached Designed by Monkeys with an unusual mandate: modernise their core transaction-authorisation service without anyone at the company being able to read the resulting code. We delivered exactly that. This paper documents the approach, the architecture, the sprint cadence, and the six-week period during which the entire authorisation layer was, by design, comprehensible to exactly one member of our troop.
The Challenge
The Client's existing authorisation service was written in a "legacy" language (Java, which by our standards counts as legacy the moment it compiles successfully). Their engineering leadership had grown concerned that too many people understood how it worked, creating what they called a "key person availability" problem and what we called "an opportunity."
Their brief, condensed from a 40-slide deck into one sentence: make it impossible for anyone to modify this without going through us. We took that brief extremely literally.
Our Approach: The DevOoops Cycle
Every engagement at Designed by Monkeys runs through our proprietary DevOoops Cycle — a closed loop of exist, roll, trade, and gibberish.code{} that we have diagrammed on a whiteboard in every conference room we have ever stood in. For Project Bananarama, the cycle looked like this:
- Exist: confirm the payment gateway currently exists and processes transactions (it did, mostly)
- Roll: roll a six-sided die to determine sprint velocity for the week (this is real and we are not going to stop doing it)
- Trade: trade two engineers between the Brainfuck workstream and the "moral support" workstream
- gibberish.code{}: the actual development phase, named accurately
We ran this cycle for 34 sprints, tracked on the whiteboard under "BANANA ECOSYSTEM," a diagram that by Sprint #94 had grown to include arrows pointing at other arrows, a box labeled "CoO" that nobody can now explain, and a note reading "gibberishGoals: md1" that governed roughly 40% of our roadmap decisions.
Architecture
The authorisation core was rewritten as a single 4,000-character Brainfuck program. For readability (a word we use loosely), we split it across eleven files, each named after a different sprint retro mood. The core loop — which validates a transaction, checks it against a fraud model, and either approves or declines it — compresses to roughly the following shape:
We do not recommend anyone attempt to audit this. The Client's compliance team attempted to audit this. It took them eleven weeks and ended with a memo titled "Findings: Inconclusive," which we have framed and hung in reception.
Deployment infrastructure
The service runs across our Arch Linux fleet, deployed via our Infrastructure-as-a-Sacrifice tier, with failover handled by a second, slightly older Arch Linux fleet that nobody has updated since the project began, on the theory that an untouched system cannot introduce new bugs. This theory has held for 187 days as of publication.
Results
"We asked for something nobody could touch without calling Designed by Monkeys. They delivered something nobody can touch, period. Technically a success." — Head of Platform Engineering, the Client
Lessons Learned
Brainfuck's eight-symbol instruction set turned out to be a genuine asset for a very specific definition of "asset": it made the codebase impossible to onboard into, which meant zero unauthorised changes, which the Client's risk team scored as a net reduction in change-related incidents. We are choosing not to examine this logic too closely, because it is the reason this project is being renewed for a second year.
The main risk we'd flag for future engagements: the single engineer who understands the codebase (Nadia Macaque, Head of Brainfuck Engineering — see byline) has requested a raise, a sabbatical, and in one memo, "acknowledgement that this was, on reflection, a bad idea." All three requests are under review by a committee that includes her.