Before I was building startups, I was building Roblox games. I was maybe 14. I knew nothing about software except that I wanted things to work. So I learned Lua, watched tutorials on YouTube, broke things, fixed them, and eventually shipped something.
I didn't know at the time that I was learning systems design, monetization, and behavioral economics. I thought I was just making a game. But looking back — that's exactly what it was.
Everything is an economy
A Roblox game lives or dies on its economy. You have in-game currency, cosmetics, power-ups, gamepass perks. Get the balance wrong and players either feel like everything is too easy (no reason to spend) or too grindy (quit out of frustration). The economy is the game.
This maps directly to SaaS. Your pricing tiers are your economy. Your free plan is your free-to-play baseline. Your conversions happen when players — users — hit a friction point they're willing to pay to remove. If you set that friction point too low, you're leaving money on the table. Too high, you lose them before they're invested.
The economy is the game. Get the balance wrong and the whole thing collapses — no matter how good the core loop is.
In Roblox, I learned this by watching the actual numbers. Session time went up when I added a streak mechanic. Purchase rate went up when I introduced a cosmetic that only dropped during a 48-hour event. Churn spiked when the grind between levels got too long. These aren't abstractions — they're just product data, and I was generating them in a live environment with real users.
Lua is a real language
People dismiss Lua as a "kids' language." It's not. Roblox's game engine is fully scriptable — server-side and client-side, with a clear distinction between them that matters. You write server scripts that handle game logic and client scripts that handle UI and local state. If you confuse the two, things break in ways that are hard to debug.
That's object-oriented programming. That's client-server architecture. That's state management. Nobody called it that — I just had to figure it out to make the game work.
My first serious bug: a developer product (one-time purchase) was firing its callback on the client instead of the server. Players could duplicate rewards by rapidly clicking. Fixed it by moving the reward logic server-side. Cost me a few hundred Robux in exploited rewards before I caught it. Expensive lesson in security boundaries.
I also built leaderboards, which meant understanding persistent data storage. Roblox uses DataStores — essentially a key-value database. You have to handle write failures gracefully, because if a player's data doesn't save and they quit, they lose their progress. That's a real problem with real consequences for retention. I wrote retry logic before I knew what retry logic was called.
The feedback loop that actually matters
The thing Roblox gave me that no class could: real users who don't care about your feelings. They play for thirty seconds and leave. They exploit your economy the moment you give them an opening. They post in the comments when something doesn't work. They just stop showing up if your game gets boring.
That's the harshest possible feedback environment. And it made me a better builder faster than anything else could have.
I think about this when I'm building 36.fyi. The students who use it will leave immediately if the product is confusing. They won't file a bug report. They'll just go back to Khan Academy. That feedback — a user not returning — is the signal I have to build toward avoiding. Same principle, different context.
Real users who don't care about your feelings are the best product team you'll ever have.
I don't build Roblox games anymore. But I think about that period a lot. Every system I build now has an economy — incentives, friction points, feedback loops. I learned what those things are by trying to get a 12-year-old to spend Robux on a virtual sword. Not the most elegant education. But it worked.