Show HN: Quantifying opportunity cost with a deliberately "simple" web app
shouldhavebought.com
A while ago I had a mildly depressing realization.
Back in 2010, I had around $60k. Like a "responsible" person, I used it as a down payment on an apartment. Recently, out of curiosity, I calculated what would have happened if I had instead put that money into NVIDIA stock.
I should probably add some context.
For over 10 years I've worked as a developer on trading platforms and financial infrastructure. I made a rule for myself - never trade on the market.
In 2015, when Bitcoin traded about 300 usd, my brother and I were talking about whether it was a bubble. He made a bold claim that one day it might reach $100k per coin. I remember thinking it sounded unrealistic - and even if it wasn't, I wasn't going to break my rule.
That internal tension - building systems around markets while deliberately staying out of them is probably what made the "what if?" question harder to ignore years later.
The result was uncomfortable. The opportunity cost came out to tens of millions of dollars.
That thought stuck with me longer than it probably should have, so I decided to build a small experiment to make this kind of regret measurable: https://shouldhavebought.com
At its core, the app does one basic thing: you enter an asset, an amount, and two dates, and it gives you a plain numeric result - essentially a receipt for a missed opportunity.
I intentionally designed the UI to feel raw and minimal, almost like a late-90s terminal. No charts, no images, no emotional cushioning - just a number staring back at you.
What surprised me wasn't the result, but how much modern web infrastructure it took to build something that looks so simple.
Although the app is a single page with almost no UI elements, it still required:
- Client-side reactivity for a responsive terminal-like experience (Alpine.js)
- A traditional backend (Laravel) to validate inputs and aggregate historical market data
- Normalizing time-series data across different assets and events (splits, gaps, missing days)
- Dynamic OG image generation for social sharing (with color/state reflecting gain vs loss)
- A real-time feed showing recent calculations ("Wall of Pain"), implemented with WebSockets instead of a hosted service
- Caching and performance tuning to keep the experience instant
- Dealing with mobile font rendering and layout quirks, despite the "simple" UI
- Cron and queueing for historical data updates
All of that just to show a number.
Because markets aren't one-directional, I also added a second mode that I didn't initially plan: "Bullet Dodged". If someone almost bought an asset right before a major crash, the terminal flips state and shows how much capital they preserved by doing nothing. In practice, this turned out to be just as emotionally charged as missed gains.
Building this made me reflect on how deceptive "simplicity" on the web has become. As a manager I know says: "Just add a button". But even recreating a deliberately primitive experience today requires understanding frontend reactivity, backend architecture, real-time transport, social metadata, deployment, and performance tradeoffs.
I didn't build this as a product so much as an experiment - part personal curiosity, part technical exploration.
I'd be very interested to hear how others think about:
Where they personally draw the line on stack complexity for small projects?
Whether they would have gone fully static + edge functions for something like this?
How much infrastructure is "too much" for a deliberately minimal interface?
And, optionally, what your worst "should have bought" moment was?
Happy to answer any technical questions or dig into specific implementation details if useful.