DEV Community: Aryaman Gandhi

We Had Six Ideas for One Game. So We Shipped All Six.

Aryaman Gandhi — Tue, 06 Oct 2026 20:01:39 +0000

Here's a conversation we had about four times:

"What if holds were shorter?"

"Shorter than what?"

"I don't know. It just feels slow."

That's not a conversation you can win. Nobody in it is wrong, and nobody can prove anything. The only way out is to play the thing.

We were building a stock market draft game. You pick stocks by sector, hold them for a few years, and find out how you did. The game worked fine. What we couldn't settle was how it should play.

The pile of unanswerable questions

Every rule had at least two defensible answers:

Rounds: 5? 8? 10?
Hold length: 3 years, 10 years, or until the game ends?
The board: one stock per sector, or five stocks from the same sector?
Money: split evenly, or let players bet big on one pick?
Selling: locked in forever, or can you dump a loser and reinvest?

That's roughly 500 combinations. We argued about maybe four of them.

The approach we didn't take

The obvious plan is to fork the real game a few times and change the rules in each copy. Real market data, real scoring, the whole thing.

We thought about that codebase a month out. Multiple versions drifting apart. A bug fixed in one and still live in three others. And once we picked a winner, most of that work goes in the trash.

That's a lot of engineering to answer a question that's really about feel.

What we built instead

An app store.

The home page is a grid of cards. Each card is a different version of the game. Tap one, read its rules, play it. Nothing has a backend. The companies are invented, the prices are generated, and there's no score at the end. You're not trying to win. You're trying to notice which version you want to play again.

Six presets shipped:

Classic Draft is the original. One stock per sector, money split evenly, 10-year holds.

One Shot shows you exactly one stock a year. Take it or leave it, and decide whether it deserves 10% of your budget or half of it.

Budget Boss is about allocation. Minimum spend per pick, everything above that is your call.

Active Trader throws ten stocks at you every round, holds for three years, and lets you sell whenever.

Sector Swap lets you sell, but the replacement has to come from the same sector. It costs you your pick for the round.

Sector Focus makes every round a single sector. You're not choosing where to invest. You're choosing who's best in one room.

The part that made it cheap

None of those are separate apps.

Every mode is one object:

{
  rounds: 8,
  stocksPerRound: 5,
  holdYears: 10,
  boardDistribution: "onePerIndustry",
  pickDistribution: "onePerIndustry",
  allocation: { kind: "equal" },
  selling: "none"
}

One engine reads that and plays by it. Adding a seventh mode means writing seven lines, not building a seventh game.

This is the whole trick, and it costs almost nothing up front. Every version of this game needs the same machinery anyway: draw a board, buy a stock, track holdings, sell when a hold expires. The only decision is whether the rules are baked into that code or handed to it. Handing them in isn't more work. It's the same code reading a variable instead of a hardcoded number.

Then someone pointed out we were doing it again

Our first plan had five fixed modes. During review, a teammate flagged the obvious problem: picking five combinations is committing to our guesses before anyone had played anything. That's the thing we were supposedly avoiding. And if someone wanted a sixth combination next week, that's another engineering cycle.

So we added a seventh card.

Custom Mode is a form with every setting exposed. Pick your rounds, your hold length, how money works, whether selling is allowed. The rules update in plain English as you change them.

Two details I like:

Impossible setups get caught before you start. Ask for a board with one stock per sector but ten stocks per round, and it tells you there are only eight sectors and keeps the Start button off. Setups that technically work but will surprise you get a softer warning, like a 10-year hold in a 5-round game where nothing ever sells.

Your settings live in the URL. Find a combination you like, send the link, and everyone plays the identical setup. That turned out to matter more than we expected. "Try this" became a link instead of a paragraph of instructions.

Because the engine already took a config object, this was a form and a URL serializer. Not a rewrite.

A market that doesn't exist

For the real game we pull historical prices, which means API limits, missing tickers, and data cleanup. For a prototype, that's overkill.

So we generated our own: 80 invented companies, 10 per sector, with 25 years of prices. Every company gets a personality. Some grind upward. Some swing wildly. Some quietly rot. Sectors have good years and bad years. There's a crash, then a recovery.

Fake turned out to be better than real here. With real tickers you're playing from memory, not reading the rules. "Obviously I'm buying the one I know went up." With invented companies, the only information you have is the thing we're actually testing.

The version that was useless

First pass, every test passed. Lint, typecheck, build, all green.

The market was still broken.

We'd asked the AI to report back some sample numbers along with the code: three example stocks at three points in time, plus the highest and lowest price anywhere in the market. Those numbers told the story the tests couldn't.

The "steady grower" had gone up 14x
One stock hit the price ceiling and sat there flat for three years, so buying it returned exactly 0%
The cheapest stock in the entire market was $8, meaning nothing ever really crashed

Returns were stacking and compounding across 25 years. Not a bug. Just a market where everything goes up, which makes a stock-picking game pointless.

Second pass, with tighter ranges and tests that assert on balance instead of correctness:

	Before	After
Median 24-year return	~14x	~3.2x
Stocks that ended lower	almost none	28 of 80
Cheapest stock	$8	$2
Stocks pinned at the ceiling	1	0

The lesson stuck: tests tell you the code runs. They don't tell you the thing is any good. If there's a number that would reveal a bad result, ask for that number.

Three people, one repo, no merge hell

We're three college students doing this between classes, so wall-clock time was about a week and a half. Actual working time was a lot less.

Previous project, we hit the classic trap: three branches cut from the same commit, all touching the same files, and an afternoon lost to untangling it.

This time the first pull request contained no features at all. Just project setup, the shared types, and placeholder functions with their final names and signatures, each one throwing "not implemented."

Once that merged, we split by folder and never crossed:

Who	Owns	Built
One of us	`lib/engine/`	board drawing, buying, holds, selling
One of us	`components/game/`	every screen, built against fixtures
One of us	`app/`, `lib/data/`	the store, the market, Custom Mode

Because the screens were built against sample data on a preview page, nobody waited on the engine to exist. Across the whole project we had essentially zero merge conflicts.

How the code actually got written

Before anyone opened an editor, we wrote out every pull request in detail: which files it touches, the rules, the edge cases, what the tests should assert.

Then each of us handed our own PR description to Cline in VS Code. I'd start in Plan mode and have it walk through its approach before touching anything. That caught more misunderstandings than code review did, for a simple reason: fixing a sentence in a plan takes ten seconds. Fixing 200 lines doesn't.

Two things made it work better than it had any right to:

The output quality tracked the input quality almost exactly. Vague PR description, vague code. The time we spent on the plan came back with interest.

We asked it to flag its own deviations. On the market PR it told me it had quietly added a correction step to force a test to pass. I would never have caught that by skimming a diff.

One thing we don't trust

On an earlier project, AI-written code sailed through lint, typecheck, 76 tests, and the build while carrying three real bugs. One fired in about a quarter of games.

So this time we wrote a test that plays a few hundred randomized full games per mode and checks invariants after every single action. Cash never goes negative. The player is never stuck with no legal move. Sector limits always hold.

It caught things the unit tests didn't. Green checks are not the same as a working game.

What we'd take from this

Build the cheapest thing that answers the question. Not the smallest version of the real product. The thing that resolves the argument. We dropped the backend, the real data, and the scoring, and none of it was missed.

Keep rules as data. Not for elegance. Because it's what made "add a seventh mode" cost seven lines instead of a sprint.

Ship presets and an escape hatch. Presets get you playing in thirty seconds. The custom option means you're not limited to what three people guessed would be fun on a Tuesday.

What's next

We play. Everyone runs the presets, builds a few custom setups, and sends links to the combinations they like. Whatever survives gets built into the real game with real data and real scoring.

Which is the whole point. We spent a week and a half so we don't spend a month building the wrong one.

Code: https://github.com/AryamanGandhi/app-store

We Didn't Build Multiple Versions of Our Game. We Built an App Store for Them.

Aryaman Gandhi — Wed, 16 Sep 2026 17:07:23 +0000

For the past few weeks I've been working on a stock market draft game with my teammates. You draft stocks by sector, hold them for years, and see how your picks would have played out. The core game was working, so the conversations shifted from "does it work" to "are these the right rules."

That's where things got complicated.

Too many good ideas

Everyone had opinions on how the game should play. How many rounds? How many stocks should you see each round? Should you hold a stock for 3 years or 10? Should the board mix industries, or should some rounds be all tech? Should you split your money evenly or choose how much goes into each pick? Should you be able to sell halfway through and reinvest?

Every idea sounded reasonable when someone described it. None of them could be settled by talking. You have to actually play a round to know if it feels good.

So the ask was simple: make different versions of the game so we can try them.

The obvious way (that we skipped)

The obvious approach is to copy the real game a handful of times and change the rules in each copy. Real historical data, real scoring, the full thing.

We thought about what that would look like a month later. Several codebases to keep in sync. A bug fixed in one version still broken in the others. And once we picked a favorite, most of that work would get thrown away.

That's a lot of effort to answer a question that's really about feel.

What we built instead

We built one small website that works like an app store. The home page has a grid of cards, and each card is a different version of the stock game. Tap one, read the rules, and hit play.

It's frontend only: no server, no API calls, no database. The companies and prices are fake. There's no score at the end either. The point isn't to see who won, it's to notice which version you want to play again.

There are six preset modes:

Classic Draft is closest to the original. 8 rounds, one stock per industry, money split evenly, and every pick held for 10 years.

One Shot shows you a single stock each round. Take it or skip it, and decide whether it's worth 10% of your budget or 50%.

Budget Boss is all about allocation. You have to spend a minimum on each pick, but everything above that is up to you.

Active Trader throws 10 stocks at you every round, uses short 3 year holds, and lets you sell whenever you want.

Sector Swap lets you sell a stock, but you have to replace it with one from the same industry that round.

Sector Focus shows five stocks per round, all from one randomly chosen industry. You're not picking a sector, you're picking the best of one.

And then there's a seventh card which is a Custom Mode builder.

The card we almost didn't build

Our first plan only had five fixed modes. When my teammate reviewed it, he pointed out two problems.

First, the five modes didn't cover every option we'd been discussing. Nothing showed 10 stocks in a round, and there was no way to make a board where every stock came from the same industry.

Second, and more important, picking five combinations meant we were locking in our guesses about what would be fun before anyone had played anything. That's the exact thing this project was supposed to avoid. If someone wanted to try a new combination next week, it would mean another round of development.

So we went with both. The presets stay as quick starting points, and a Custom Mode card lets you set every rule yourself.

How Custom Mode works

Custom Mode is a single page with a section for each setting: rounds, stocks shown, hold time, how the board is filled, industry limits on your picks, how money works, and whether you can sell. Everything is a big tappable button instead of a dropdown, since a lot of us test on our phones.

There's a row at the top to start from any preset and tweak from there. Below the form, a plain-English summary of your rules updates as you change things, like "5 stocks shown each round, all from one industry."

The part I like most is how it handles combinations that don't work. If you ask for a board with one stock per industry but 10 stocks per round, it tells you there are only 8 industries and keeps the Start button disabled. Setups that work but might be surprising get a softer warning, like a 10 year hold in a 5 round game where nothing ever sells.

When you hit Start, every setting goes into the URL. So when someone finds a combination they like, they just send the link and everyone else plays the exact same rules.

One engine for everything

What made Custom Mode cheap to add was that the game never knew about specific modes in the first place. Every mode, preset or custom, is just a set of settings, and one engine reads those settings and plays by them. The preset cards and the custom form both end up handing the same kind of settings to the same game.

When we changed direction, the engine needed one new board type and a function to check configs. Everything else stayed.
Making up a stock market

For the original game we pulled real historical prices, and between API rate limits and missing data it took more work than we expected. For a prototype that felt like overkill.

So we generated our own market: 80 made-up companies, 10 per industry, with 25 years of prices. Each company has a personality. Some grow steadily, some swing wildly, some slowly decline. Industries have good and bad years, and there's a crash followed by a recovery. We bumped it to 10 per industry specifically so an all-one-industry board could still show 10 stocks.

Fake companies turned out to be better for this anyway. With real ones you end up playing from memory. With made-up ones, you're reacting to the rules.

Three people working at the same time

On the original game we mostly worked one after another, and at one point we spent an afternoon untangling merge conflicts from branches that all started at the same commit. We didn't want to repeat that.
This time the first pull request was just the foundation: project setup, a shared file describing what a stock, a mode, and a game look like, and placeholder versions of every engine function with their final names. Once that merged, everyone knew what they were building against.

Then we split the work by folder. One teammate built the engine: the config checks, drawing the board, buying, holding, auto selling, and reselling. Another teammate built the screens, like the stock cards, the four spending controls, the holdings panel, and the game over screen, all against sample data on a preview page so she never waited on the engine. I handled the fake market, the store pages, Custom Mode, and the final pull request that connected everything.
Since nobody was editing the same files, merge conflicts were almost nonexistent.

How we actually built it

Before anyone wrote code, we wrote a detailed description for every pull request: which files to touch, the rules, the edge cases, and what the tests should check.

Each of us took those into Cline in VS Code. I'd start in Plan mode and have it walk through what it was going to do before touching anything. That step caught more misunderstandings than code review did, because fixing a sentence in a plan is a lot easier than fixing a few hundred lines of code. Once the plan matched what I had in mind, I'd switch to Act mode, let it build, then run lint, typecheck, tests, and build before opening the PR.

This helped a lot when we changed direction halfway through planning. We updated the PR descriptions and kept going. And because each PR said which files it owned, the changes stayed in their own lane, which matters when three people are working in the same repo.
What I'd take from this

If you're stuck choosing between versions of something, build the cheapest thing that lets you actually try them. Skip the backend, use fake data, and leave out anything that doesn't help answer the question.

Keep your rules as data instead of hardcoding them. That one decision is why adding Custom Mode was a small change instead of a rewrite.
And give people presets and a way to go off script. The presets get you playing in seconds, and the custom option makes sure you aren't limited by what the team guessed would be fun.
What's next

Now we play. Everyone runs through the presets, tries some custom setups, and shares links to the combinations they like. Whatever rules win get brought into the real game with real data and real scoring.

I Built a Stock Market Game in a Few Days

Aryaman Gandhi — Wed, 26 Aug 2026 23:52:18 +0000

The idea

You're given a random year (2019-2022), then you pick one stock per sector without seeing prices. Eight sectors, eight picks. Allocate $10K however you want. See how you would've performed in that year.
The mechanic is pure strategy. You know the year upfront. So the question becomes: which stocks will do well in 2022? Or 2019? That forces you to think about what actually happened in those markets. Tech dominated 2019-2021, got crushed in 2022. Energy was dead for years then suddenly mattered.

You can't rely on current sentiment. You have to think about historical context and sector rotation. Pick Apple for 2022 and you're in for a rough time. Pick it for 2019 and you're golden. The game forces you to actually know something about what happened in different years, not just have opinions about which companies are good.

It's interesting because most people don't think about markets this way. We know what's happening now. We have opinions about what's good now. But actually understanding how different years played out differently? That's harder. And more useful.

Building it

I started with the roughest possible version. Just enough to see if the idea was even playable. A basic draft flow, mock data, and a simple calculation to show returns. Nothing polished. No styling, minimal logic, just the core mechanic working.

But that rough version was worth everything. Because the moment I had something interactive, I knew the idea worked. I wasn't building abstractions anymore. I was playing a game I'd made. And that's when you actually know if something is fun or not. You can't know that from a design document. You have to play it.

The tricky part was the data. I needed historical stock prices for ~140 tickers across 4 years (2019-2022). Not just any data either, I needed to organize it by year, handle tickers that didn't have complete data (some companies went public after 2019, some got acquired), and make it queryable without hitting an API at runtime. The whole game needed to work client-side, which meant all the data had to be baked in.

Fetching the data itself was a challenge. The API I was using had rate limits, and pulling data for 140 tickers across 4 years meant a lot of requests. Had to add delays between requests, handle failures gracefully, and retry when things timed out. Once I had all the data, organizing it into a structure that made sense for the simulation took a couple iterations. But once the data pipeline was solid, everything else fell into place.

After the data pipeline worked, I added tests because the return calculations were complex. You're buying shares on the first trading day of a year at the opening price, then selling on the last trading day at the closing price. If you mess that up, the whole game gives wrong results. Tests caught bugs that would've shipped broken.

Built a UI that didn't look like it was thrown together in an hour. Used React components, Tailwind for styling, kept it clean and simple. Restructured things a few times to make the code cleaner.
The whole process was straightforward though. I didn't overthink it. I didn't spend days planning the perfect architecture. I just built it, saw what worked, and iterated. That's faster than you'd think.

Tools

Used Cline to write most of the code. Also used Next.js, TypeScript, and Tailwind. Historical data from Twelve Data. Nothing fancy, just tools that work together.

Cline handled the heavy lifting: the simulation logic, the UI components, catching edge cases I didn't think of. I could've used other tools, but Cline's reliability mattered. It never broke something that was already working. When I asked it to refactor the data pipeline, it didn't touch the simulation logic. When I asked it to add a new feature, it didn't accidentally break the tests. That consistency matters more than raw speed when you're trying to ship something.

The other thing that helped: being able to think through problems conversationally. "Here's what I'm trying to do, here's why it's not working, what should I try?" That back-and-forth helped me understand the problem better, not just get code faster.

What stuck

Shipping something rough beats perfecting something theoretical. I catch myself trying to build perfectly all the time. Spending days thinking about architecture, arguing with myself about the right approach, optimizing before anything ships. This time I just didn't. Had something playable in hours. Everything after that was making it better, not building from scratch.

Tests give you confidence to refactor. Each change made the code better and tests made sure nothing broke. Tests aren't overhead. They're freedom.

What's interesting about the mechanic

The game actually teaches you something about markets. Everyone thinks they know which stocks are good. But "good" is context-dependent. The same stock performs completely differently depending on the year.

You realize how much sector rotation matters. Energy stocks were terrible for years. Mining stocks, oil companies, all garbage from an investor's perspective. Then 2022 hit and suddenly they were the best performers. Interest rate hikes, inflation, oil prices spiking. The entire context changed.

Tech did the opposite. Up massively for three years straight. Anything tech-adjacent was printing money. Then 2022 came and valuations compressed hard. Companies that seemed unstoppable got cut in half.

Playing the game forces you to think historically instead of just having opinions. You can't just say "Apple is good." You have to know why it was good in 2019 but rough in 2022. What changed? What was the macro environment like? Why did investors care about different things?

That's actually useful knowledge. It teaches you that markets aren't random, but they're not predictable either. Different years reward different things. Understanding that is worth more than just having strong opinions about stocks.

What's next

I want to add features like leaderboards, charts, and multiplayer eventually. But for now, I'm just sitting with having shipped something. Something that works. Something people can actually play.
That's the win. Not the perfect architecture. Not the most optimized code. Just: I had something to build, and now it exists, and people can use it.

If you're thinking about building something, don't wait for it to be perfect. Build the rough version. See if anyone cares. Then iterate. That's how everything gets made.

Check it out: https://github.com/ethantao14/cline-stock-market-game