4 Side Projects I Killed — And What They Taught Me
Before BrainFit became a brain training RPG with 32 mini-games and BloomCard turned into a garden-themed flashcard app, I spent the better part of two years building things nobody asked for. Four side projects, to be exact. I built each one with genuine enthusiasm, poured real engineering hours into them, and eventually killed every single one.
This is not a humble-brag disguised as a failure story. These projects genuinely failed. But the technical decisions, market lessons, and product instincts I developed while failing turned out to be the foundation for everything I am shipping today. If you are an indie developer in the early stages of figuring out what to build, I hope my mistakes save you some time.
Project 1: OGmake — The OG Image Generator Nobody Needed
What It Was
OGmake was going to be an API and SaaS for automatically generating Open Graph images. You know those preview cards that show up when you share a link on Twitter or Slack? I wanted to make a service that generated beautiful, branded ones on the fly.
The idea came from my own frustration. Every time I launched a side project, I spent an unreasonable amount of time fiddling with OG images in Figma, exporting them, and making sure they rendered correctly across platforms. Surely other developers felt the same pain, right?
How Far It Got
I built a working prototype with a template system, an API endpoint that accepted parameters and returned a PNG, and a basic dashboard for managing templates. The tech was solid — I used Vercel's @vercel/og under the hood, which leverages Satori for SVG rendering. I had about five templates ready and a pricing page drafted.
I also did extensive marketing research. I mapped out a Product Hunt launch roadmap spanning four stages over seven months. I planned SEO strategies targeting bottom-of-funnel keywords. I sketched out a PLG (Product-Led Growth) funnel where a free OG Image Previewer tool would attract developers who would then convert to the paid generation API.
Why I Killed It
When I sat down and honestly evaluated OGmake against my other project ideas, it ranked 8th out of 16 candidates. The reasons were damning:
It was a "nice to have," not a must-have. No developer has ever lost sleep over OG images. They are annoying to make, sure, but annoying is not the same as painful. Painful is when your app crashes in production. Annoying is when you have to open Figma for five minutes.
The free alternatives were overwhelming. Vercel OG is free and built into Next.js. Canva can generate social images. Most modern frameworks have some kind of built-in OG image support. I was trying to sell aspirin in a hospital that was already giving it away.
The revenue ceiling was low. My most optimistic projection for three months out was $300 to $1,000 MRR. Compare that to other ideas on my list that projected $500 to $3,000 in the same timeframe. When you are a solo developer, opportunity cost is everything.
I killed OGmake before writing a single line of marketing copy. It was the right call, and it was the first time I made a project decision based on a scoring framework rather than gut feeling.
Project 2: QRPulse — The QR Code App That Was Already Dead on Arrival
What It Was
QRPulse was a QR code generator with scan analytics. The pitch was simple: create QR codes, track who scans them, see geographic and temporal data, and pay $8 per month for the privilege.
How Far It Got
This one actually reached MVP. I had a working product — you could generate QR codes with custom designs, deploy them, and see a basic analytics dashboard showing scan counts, locations, and timestamps. The frontend was clean, the backend was functional, and I was genuinely proud of the engineering.
Why I Killed It
QRPulse taught me the most painful lesson of all four projects: a working product means nothing if the market does not want it.
The SEO landscape was a nightmare. Every keyword I targeted was dominated by sites with Domain Rating 90 or higher — QRCode Monkey, Flowcode, Uniqode, Bitly. These are not startups. These are established companies with massive link profiles and years of content authority. A solo developer with a fresh domain has exactly zero chance of ranking for "QR code generator" against a DR 90 site.
But the SEO problem was just a symptom of a deeper issue: there was no recurring value proposition. People generate a QR code and they are done. Maybe they check the analytics once or twice. Nobody needs a monthly subscription for that. The scan analytics were interesting in theory but not valuable enough to justify $8 per month when the QR code itself could be generated for free on a dozen other sites.
I explored several pivot ideas — one-time payment models, B2B niche targeting for restaurants and events, an API-first approach, white-labeling — but none of them solved the fundamental problem. The technology had no moat. Anyone could build a QR code generator in a weekend. And many had.
The Numbers That Sealed It
My realistic six-month projection: $100 to $300 MRR with a 50 percent probability of even hitting that. Meaningful revenue of $2,000 or more per month was categorized as "extremely difficult." When your best-case scenario requires the word "extremely" as a qualifier, it is time to move on.
Project 3: The Mobile App Rabbit Hole — Five Ideas, Zero Shipped
What It Was
This was not a single project but rather a research phase that consumed weeks. I was seduced by the mobile app market's headline numbers — $1.2 trillion globally — and started evaluating subscription app ideas:
- An AI-powered emotion journal
- A receipt scanner that doubled as a household budget tracker
- An AI calorie recognition camera
- A habit tracker with social accountability
- A unit converter (yes, really)
I spent significant time researching the mobile app market, subscription economics, and the growing phenomenon of subscription fatigue. I built detailed financial models, analyzed competitor pricing, studied churn rates, and mapped out technical architectures.
How Far It Got
I prototyped exactly none of them. But I did produce a thorough market research document that, ironically, talked me out of the entire category.
Why I Killed It
The research was sobering. Here is what I found:
The math is brutal. The top 5 percent of apps earn meaningful revenue ($8,880 or more per month). The bottom 25 percent earn $19 or less. Eighty percent of all apps make less than $1,000 per month. This is not a market — it is a lottery with extra steps.
Subscription fatigue is real and accelerating. More than half of consumers report subscription fatigue. In Korea specifically, YouTube Premium prices rose 71.5 percent, Coupang's Wow membership increased 58 percent, and Tving's account-sharing crackdown caused a 315 percent surge in customer service complaints. People are actively hostile toward new subscriptions.
The paradox that broke my brain: consumers complain about subscriptions while spending 33.9 percent more on app subscriptions year over year. People say they hate subscriptions and then subscribe to more things. This means "subscription fatigue" is not a market opportunity — you cannot build a product that solves a problem people claim to have but demonstrably do not.
The most important insight from this research phase was a single sentence I wrote in my notes: "Complaints existing does not mean money exists." This became a filter I apply to every product idea now.
I also looked at the solo developer portfolio strategy — building 30 or more small apps to diversify risk, like some indie developers who reportedly earn $60K per month across a portfolio. But that approach requires a volume and velocity I could not sustain while maintaining quality.
What Survived
Despite killing the mobile app direction at the time, the research was not wasted. The subscription fatigue data directly influenced how I designed the monetization for BrainFit and BloomCard. I became obsessive about making free tiers genuinely useful, about making the value of premium obvious before asking for money, and about offering pricing that does not feel extractive. The monetization framework I refined across these projects is detailed in this post.
Project 4: CalcViral — The One That Pivoted Into Something Real
What It Was
CalcViral started as a straightforward bet on the ad-revenue calculator niche. The thesis: build a collection of high-CPC calculators targeting expensive keywords (legal, financial, insurance) and pair them with viral quizzes for traffic spikes. One domain, two tracks — tools for steady SEO revenue, quizzes for explosive but ephemeral traffic.
How Far It Got
This one I actually built and shipped. CalcViral at its peak had 20 calculators spanning finance (compound interest, mortgage, freelancer tax), legal (child support, alimony, divorce cost, LLC costs for all 50 US states), health (BMI, TDEE), home improvement (remodel costs for 30+ cities), math utilities, and unit converters. It also had 10 brain tests and quizzes — color vision, reaction time, CPS test, memory test, number memory, pattern IQ, typing speed, chimp test, and a personality test.
The tech stack was serious: Next.js with App Router, React, Tailwind CSS, next-intl for three languages (English, German, Spanish), Supabase for quiz result sharing and premium orders, Lemon Squeezy for payments, AdSense for ads, and Cloudflare Workers for hosting. The site generated over 1,000 pages through programmatic SEO — tools multiplied by 50 states, remodel costs by 30 cities, all in three locales. I had dynamic OG images, JSON-LD structured data, a cookie consent system, and five long-form blog posts.
I even had a premium product: a five-page personality report for $9.99, generated as a PDF with jsPDF and delivered via Resend email.
Why I Stopped Actively Developing It
CalcViral is still live at calcviral.9-87.org, but I stopped pouring active development time into it. Here is why:
The CPC dream did not materialize fast enough. High-CPC niches (legal calculators at $50 to $150 per click) sound amazing on paper. In practice, those keywords are dominated by established authority sites. A fresh domain competing for "child support calculator California" against state government websites and legal giants is like bringing a knife to a gunfight.
The viral quiz play required constant content creation. Viral content is, by definition, ephemeral. Each quiz might generate a spike, but the spike fades within days. To maintain traffic, you need a content treadmill — always producing the next viral thing. That is a media company, not a software product.
But here is the key insight: the brain tests were the most engaging part of the site. The reaction time test, the memory test, the pattern IQ quiz — these were the pages where users spent the most time, came back most often, and shared results most frequently. The calculators were utilities. The brain tests were experiences.
That realization was the seed that became BrainFit.
The Common Failure Patterns
Looking across all four projects, three patterns emerge repeatedly:
Pattern 1: Solving My Own Problem, Not Theirs
OGmake was born from my annoyance with OG images. The mobile app ideas came from my personal interest in journaling and health tracking. These are classic "scratch your own itch" projects, and the indie dev community loves to celebrate that approach. But here is the problem: my itch was mild. And mild itches do not produce customers willing to pay.
The projects that survived — CalcViral's brain tests, which evolved into BrainFit, and the flashcard mechanics that became BloomCard — succeeded because they addressed something more universal. Everyone wants to feel smarter. Everyone has something they need to memorize. These are not niche developer frustrations; they are human ones.
Pattern 2: Over-Engineering Before Validating
QRPulse had a custom analytics dashboard. OGmake had a template management system. CalcViral had programmatic SEO generating over 1,000 pages. In each case, I built the sophisticated version before confirming that anyone wanted the simple version.
For BrainFit and BloomCard, I reversed this pattern completely. BrainFit started as a single reaction time game with a hardcoded difficulty curve. I showed it to people. They played it more than once. Only then did I build the Elo rating system, the RPG progression, the 32-game roster. BloomCard started as a bare-bones flashcard app with a garden metaphor painted on top. People liked watching their garden grow. Only then did I implement FSRS spaced repetition, custom card painters, and the full botanical reward system.
Pattern 3: No Clear Audience From Day One
Who uses OGmake? "Developers" is not a market segment — it is a job title. Who uses QRPulse? "Businesses that use QR codes" is everyone and no one. Who subscribes to an AI emotion journal? I genuinely could not answer this question, which is why I never built it.
Compare this to BrainFit: people who enjoy brain training games and want to track their cognitive improvement over time. Or BloomCard: language learners and students who want spaced repetition with a visual reward system. These audiences are specific enough to find and serve, broad enough to sustain a business.
The Technical Stack That Carried Over
Not everything was wasted. In fact, the technical foundation I built across these failed projects became the backbone of BrainFit and BloomCard:
Flutter and Dart. I started learning Flutter during the mobile app research phase. Even though none of those five app ideas shipped, the framework expertise directly enabled BrainFit and BloomCard. Both are Flutter apps, and my comfort with Dart, widget composition, and platform-specific adaptations came from months of tinkering with projects that never saw the light of day.
Supabase. CalcViral used Supabase for quiz result sharing and order tracking. QRPulse used it for analytics storage. By the time I built BrainFit and BloomCard, I had strong opinions about schema design, row-level security, and real-time subscriptions. The backend patterns I established in failed projects transferred directly.
RevenueCat. My deep dive into subscription economics during the mobile app research phase led me to RevenueCat as the go-to monetization framework. I studied its API, understood its paywall patterns, and designed my pricing models around its capabilities — all before I had a product to monetize. When BrainFit needed in-app purchases, RevenueCat integration took hours instead of weeks.
Drift ORM. I needed local database capabilities in the mobile app prototypes I never finished. Drift (formerly Moor) was my choice for local SQL in Flutter. That expertise carried over to BrainFit's offline-first architecture, where game state, Elo ratings, and progression data all live locally.
Riverpod. State management was something I experimented with across multiple Flutter prototype attempts. I tried Provider, Bloc, and eventually settled on Riverpod. The migration journey — documented in a separate post — was painful but the patterns I established are now used consistently across both BrainFit and BloomCard.
next-intl. CalcViral's three-language implementation taught me everything about internationalization in Next.js — subpath routing, message extraction, locale-aware SEO. The web companion sites for BrainFit and BloomCard use the exact same next-intl patterns.
How These Failures Shaped BrainFit and BloomCard
Every major product decision in BrainFit and BloomCard has a direct ancestor in a failed project:
"Validate before you build" came from OGmake. I now spend at least a week researching competition, estimating realistic revenue, and scoring ideas against a framework before writing any code. OGmake scored 8th out of 16 ideas, and I built it anyway. I do not make that mistake anymore.
"Ship the smallest possible thing" came from QRPulse. QRPulse was feature-complete and market-dead. Now I ship the ugliest, most minimal version that tests the core hypothesis. BrainFit v0.1 was one game with no progression system. BloomCard v0.1 was flashcards with a static garden background. Both were embarrassing. Both were enough to learn from.
"Kill fast" came from the mobile app research. I spent weeks researching an entire category only to discover it was not viable for a solo developer. That experience taught me to set explicit kill criteria before starting. Now every project gets a 30-day validation window. If I cannot find 10 people who want the thing within 30 days, I stop.
"Let users tell you what matters" came from CalcViral. I built 20 calculators and 10 brain tests. The brain tests won. I did not predict that. The users showed me. BrainFit exists because I paid attention to engagement data instead of my own assumptions.
"Monetization is a design problem, not an afterthought" came from the subscription fatigue research. My deep dive into why people hate subscriptions made me allergic to dark patterns and artificial restrictions. BrainFit's free tier includes real, complete games — not crippled demos. BloomCard's free tier lets you create and study real decks — not five-card trial nonsense. Premium unlocks genuinely additional value, not hostage-released features.
The Meta-Lesson
If I had to distill everything into one principle, it would be this:
Ship fast. Validate fast. Kill fast.
Every week you spend building something nobody wants is a week you are not spending on something someone does. The four projects I killed cost me roughly 18 months of evenings and weekends. That is a lot of time. But the alternative — spending 18 months on one project that fails — is worse, because you learn one lesson instead of four.
OGmake taught me to evaluate before building. QRPulse taught me that a working product is not a validated product. The mobile app research taught me to study markets before entering them. CalcViral taught me to listen to usage data.
BrainFit and BloomCard are not successful because I am a better developer now (though I am). They are successful because I am a better decision-maker. And I became a better decision-maker by making bad decisions, recognizing them, and moving on.
If you are sitting on a side project that is not working, here is my advice: set a deadline, define success criteria, and be honest when you miss them. The next project might be the one that works. But you will never find it if you are still nursing the one that does not.
This post is part of a series on building indie apps. For a deep dive into how the monetization lessons from these failed projects shaped BrainFit and BloomCard's paywall design, see Paywall Fatigue Design.