In Shinkansen Lines, you can change trains mid-journey. The game will still give you back 97% of your stakes.
I built a casino. Not a real one: VibeCasino is a demonstrator. It accepts no money, its Vibe Tokens have no value, and it can only be reached from my private network. The aim fits in one sentence: rather than write on a CV that I understand the business of an online gaming operator, show the platform, the maths and the back-office during an interview.
The brief came first
The brief existed beforehand. I had written it with care: five or six games, a complete platform (accounts, deposits and withdrawals, statements, European and Maltese obligations), a Japanese theme, a PWA, and an insistence on design. On 17 October, late in the afternoon, I open the session with Claude Code. Three minutes later, I settle four scoping questions. An hour after the first message, the commit goes out (94 files, 9,158 lines) and it is live. That hour only means something because the brief already carried the decisions.
Two of those decisions went against the recommendation I was given. No public access, not now and not later: I am the one who gives the demonstration. And the baccarat from the brief dropped in favour of a Plinko, more in tune with the times. In production that evening, I had only checked that the lobby displayed. Claude Code had played the games locally, on desktop and mobile. That is not the same thing.
Two games that did not exist
The next morning, I asked for something else: a game that does not exist on the market. Three concepts two minutes later, each with what comes closest to it and a useful admission (no exhaustive market study). I took two: two new games that, as far as I know, exist only on VibeCasino. Twenty minutes after my request, both games were running: 20 files, 1,246 lines, with tests, a fairness verifier and rules in English and French. The third, Daruma Otoshi, is waiting in the roadmap.
Shinkansen Lines is the one I talk about first. It is a crash game with three trains, and you can transfer all or part of your ticket (25, 50 or 100%) from one train to another mid-journey, as many times as you like. Whatever your strategy, the return is 97%. The reason fits in one line: the stopping points follow a memoryless law in multiplier space, and the probability of reaching M when you are already at m is m/M. Each segment is a fair bet. A transfer therefore never changes the expected value. The house edge comes from elsewhere: 3% of departures stop dead at 1.00×. The test replays 30,000 rounds with randomly drawn strategies and measures 97.29%.
Sumi Bleed pushes the idea further: the player paints their own wheel, and so their own volatility. A single painted cell pays 36× if the wheel stops on it, 18× if the ink trail reaches it: a 3.7% chance of winning. An almost-closed circle, forty cells, pays 0.22× but hits nine times out of ten, with a 1,000× Ensō once in 1,253. The server computes the exact probabilities of the drawing and adjusts the multiplier. The same return for the cautious and for the bold. That is exactly what a studio sells: not an animation, but a distribution of wins whose return it can prove.
What the tests could not see
Eight minutes after they went live, I sent a screenshot. The ink was bleeding on both sides of every stroke, at random, on a wheel that always turns the same way. Visually, no direction could look right. The tests were green, the RTP exact. They saw nothing, and they could see nothing. The fix was not cosmetic: the ink is now dragged backwards, with a 70% chance of reaching the first cell, then 50% per cell, three cells at most. New probabilities, new exact calculation, tests and rules rewritten. Five minutes. RTP still at 97%, but the odds moved: the single cell went from 40× to 36×.
Built to be checked
The rest is hygiene. The server decides everything; the browser animates. The engines are pure: they turn a random stream into a result without touching the database or the money, which means they can be simulated millions of times. Money is held in integers, never in floating point, and only one module can change a balance, always with its ledger line. On verifiable fairness, the server seed is committed in advance, and every round can be recomputed in the browser after a rotation, with no call to the server. 32 tests as of 18 October, all green in 12.6 seconds. 2,733 lines of Python, 4,876 of JavaScript, 1,068 of CSS. No front-end framework, no build step, no audio file (the sounds are synthesised), €0 to run.
The compliance side reproduces the obligations of a Maltese B2C licence holder without claiming anything: age and residence checks, simulated identity verification to withdraw and beyond 2,000 tokens deposited, deposit, loss and stake limits over 24 hours, 7 days and 30 days (tightening is immediate, loosening comes after 24 hours), self-exclusion from 24 hours to 5 years that cannot be revoked, and a back-office showing GGR, NGR, hold and actual versus theoretical RTP for each game. The documentation lists the gaps it accepts: no real KYC, no payments, no laboratory certification.
Next time
What I would do differently. I would check every game in production before writing ‘live’, not just the lobby; the cost is a quarter of an hour at most. I would write a game's physical rule before its maths: for Sumi Bleed, the direction of rotation was an input constraint, not a rendering detail, and I discovered it after proving the RTP. And I would add a dedicated return test for blackjack, the only game whose ~99.5% follows from the standard rules and is established neither by a calculation nor by a simulation in the repository.