I Built Production Infrastructure for a Silly App

Throne Factory is a reusable skeleton for launching "pay-for-status" web apps. Instead of writing a new backend every time you want to test a strange idea, you write one config entry, drop in a theme, add a payment product, and ship. The hard infrastructure gets built once. The experiments are cheap.

The first thing I ran through it is a king-of-the-hill game called The Throne. One seat. One name. Whoever has paid the most holds it, until someone pays more. The price climbs each time. It is a genuinely silly premise, and I mean that as a compliment.

Here is the thing I want to sit with in this post. The premise is silly. The code under it is not.

The stuff nobody sees

If you looked at The Throne, you would see a name on a throne and a button that costs money. That is the whole product, as far as a visitor is concerned.

Behind that button, at last count, is 398 passing tests. Row-level security on the database, so a bad actor with the wrong key still reads nothing. Rate limiting per IP, so nobody scripts a thousand checkout sessions a second. Geo-blocking that fails closed for sanctioned regions, meaning if the country check is uncertain it denies rather than allows. And the part I am quietly proud of: an atomic takeover. When you seize the throne, that swap either happens completely or not at all. You cannot race it, you cannot underpay your way in, and two people paying at the same instant do not both walk away thinking they won.

None of that is visible. All of it is load-bearing. The moment real money moves through a thing, "it mostly works" stops being an acceptable answer, and the gap between a demo and a product is exactly this pile of unglamorous safeguards.

There is also a rule I set for myself: I do not want to approve anything by hand. No moderation queue, no me sitting there rubber-stamping names at midnight. So the moderation is zero-touch. A name or a message either clears the automated screen and gets stored, or it never gets stored at all and the buyer keeps their throne anyway. If I have to be in the loop for it to be safe, it does not scale, and I built this specifically so it would.

Why build the factory instead of the app

I could have written The Throne as a one-off. Most people would. You hack it together, you launch it, and when the next idea arrives you start from scratch and rebuild all the same plumbing.

That plumbing is the expensive part. Payments, security, moderation, geo-rules, the takeover logic. It is roughly identical whether the skin on top is a throne, a wall, a leaderboard, or whatever the next odd thing is. So the bet behind Throne Factory is that you build that once, properly, and then a new experiment costs you a config entry, a theme folder, and a payment dashboard entry. No new backend. If launching the next one requires touching the backend, the skeleton failed and I go fix the skeleton, not the app.

This is the systems version of a decision I have made in a lot of other places. Do the hard part once. Make the repeat cheap. The reason I can even entertain a silly idea is that shipping it does not cost me two weeks of the serious work every single time.

Three thrones I threw away

The design did not come easy, and I want to be honest about how much I rejected.

I started where you would expect. Royal. Gold, crests, the visual language of an actual throne room. I built three versions along that line and disliked all three. They looked like what a computer thinks "regal" means. Cheap in the way that trying-hard is cheap.

What I landed on has nothing royal about it. A black monolith with a molten-gold seam running through it, and the seam charges up as you type your name into it. It is closer to a slab of obsidian than a crown. It feels expensive and a little ominous, which is the correct feeling for handing over an escalating pile of money to sit on a digital chair. Sometimes the right answer for a thing about status is to stop depicting status and depict weight instead.

I mention the three rejects because the build-in-public version of this story usually skips them. The monolith reads like an obvious choice now. It was the fourth choice.

Viral, but not sketchy

Pay-for-status mechanics live next door to a lot of things I did not want to build. Gambling. Auctions. Lotteries. Public shaming as a growth loop. That neighbourhood is where the easy virality lives, and it is a neighbourhood I stayed out of on purpose.

So the compliance is designed in, not bolted on afterward, and it is enforced by the server rather than left to my good intentions. No pooled payouts, so nobody is betting into a prize pot. No auction, wager, or lottery framing anywhere in the product. No mechanic that publicly shames the person who lost their seat. These are not guidelines in a document I might forget. They are rules the system itself will not let me break, which is the only kind of rule that survives contact with a growth target.

You can build something designed to spread without building something designed to exploit. It takes more work up front. It is the difference between a thing I would show my kids and a thing I would quietly hope they never found.

Where it actually stands

Now the honest part, because a building-in-public post that only shows the wins is just marketing wearing a costume.

The Throne is built and it's in QA right now. This one is a work in progress I'm building partly just for the fun of it, so I'm in no rush to rush it. It is not launched. Right now it runs on test-mode payments only, which means it has never taken a real dollar and cannot, yet. Between here and its first real transaction sit a few real things: live payment keys, the legal pages, and a full wipe of the test data so no fake king survives into the real ledger.

And there is one open flaw I am still hardening. When you lose the throne to a higher bidder, your payment is supposed to be automatically refunded. That path has an edge case where, if the refund call fails at the wrong moment, someone could be charged, not crowned, and not refunded. That violates the one promise the whole compliance model rests on, so it does not go live until it is airtight. I would rather tell you it exists than discover you found it.

So: not a launch announcement. A "here is the machine, here is the thing it made first, here is what is still wrong with it" announcement.

The question I actually want to ask you

The part of this I keep turning over is not the throne. It is the skeleton.

Once the hard infrastructure exists, the cost of trying a weird idea collapses. The thing standing between most people and their strangest experiment is not the idea. It is the two weeks of plumbing nobody wants to build for the fourth time.

So here is what I am curious about. If the payments, the security, the moderation, all of it were already built and waiting, and shipping your idea was genuinely a config entry and a coat of paint, what small strange thing would you actually put into the world?

I think the answers to that are more interesting than any throne.

Frequently Asked Questions

What is a reusable app skeleton?

One properly built backend that new experiments ride on. Payments, security, moderation, geo-rules and the core transaction logic are roughly identical whether the skin on top is a throne, a wall, or a leaderboard. Build that once and a new launch costs a config entry, a theme folder, and a payment dashboard entry. If launching the next one requires touching the backend, the skeleton failed.

What infrastructure does a small paid app actually need?

More than it looks. Behind one button sit 398 passing tests, row-level database security so a bad actor with the wrong key still reads nothing, per-IP rate limiting, geo-blocking that fails closed for sanctioned regions, and an atomic takeover so two people paying at the same instant don't both walk away thinking they won. None of it is visible. All of it is load-bearing the moment real money moves.

How do you moderate user content without a human in the loop?

Zero-touch by design. A name or message either clears the automated screen and gets stored, or it never gets stored at all, and the buyer keeps what they paid for either way. If I have to be in the loop for it to be safe, it doesn't scale.

How do you build viral mechanics without building something exploitative?

Design the compliance in, and enforce it in the server rather than in your good intentions. No pooled payouts, so nobody's betting into a prize pot. No auction, wager, or lottery framing. No mechanic that publicly shames whoever lost their seat. Rules the system won't let you break are the only kind that survive contact with a growth target.

Is The Throne live?

No. It's built and in QA on test-mode payments, so it has never taken a real dollar. Live payment keys, legal pages, and a full wipe of the test data stand between it and launch. One refund edge case is still open: if the refund call fails at the wrong moment, someone could be charged, not crowned, and not refunded. That breaks the one promise the compliance model rests on, so it doesn't ship until it's airtight.