graveyard/

OurStars

“Personalized star maps of any moment in time.”

A star-map gifting store — pick a date and place, get the night sky from that exact moment as a poster. It actually shipped and made sales, but it was deeply seasonal, low-margin, and every sale was a one-off that demanded constant marketing. The upkeep outweighed the return, so I let it sunset.

One-off gifting products are a treadmill — you market hard for every single sale with no retention to bank on. Recurring value beats novelty.

ShopHealth

“Store health monitoring for Shopify merchants.”

A Shopify app that audited stores for speed, SEO and UX issues and explained the fixes in plain English. The MVP came together well — but it landed in a crowded category against well-funded incumbents, and out-marketing established store-audit apps as a solo dev was a different game entirely. Shelved before launch.

A good product in a saturated category still needs a distribution edge. Building it was never the hard part — being found was.

Codiflow

“Reusable product blueprints for Shopify.”

Let merchants define a product "blueprint" once and spin up consistent products from it. Genuinely useful, but niche enough that the addressable market never justified maintaining a full Shopify app. Parked once it was clear too few merchants would pay for it.

"Useful" isn’t "fundable." Pain has to be both real and widespread enough to support the cost of being a maintained product.

XRay

“Xcode preview crash monitor for macOS.”

A menu-bar app that caught Xcode preview crashes and handed me an AI explanation with the line to fix. Genuinely handy during SwiftUI work — but too narrow to be a product, and not worth maintaining as Xcode kept shifting the ground underneath it. Scratched my own itch, then stopped.

Scratching your own itch is a great reason to build and a weak reason to maintain. Know which one you’re doing.

Emberline

“A calm, pixel-art breathing companion.”

A guided breathing app with a pixel-art skin and session streaks. The Skia rendering was a joy to build, but the calm/breathing category is brutally saturated with polished, well-funded apps, and the retro angle was charm, not a real wedge. Stayed a prototype.

A fun visual hook isn’t a differentiator users will switch for. In a crowded category you need a reason to be chosen, not just admired.

Resist

“Put the apps you doom-scroll behind a speed bump.”

An app-blocking focus tool — pick the offenders, gate them, track your relapses. The problem: iOS hands that power to Screen Time / Family Controls behind tight entitlements, so a third-party version was always going to be hobbled. Killed once the platform limits made the core promise undeliverable.

Check what the platform will actually let you do before building the feature it’s all built around. Some walls don’t move.

Samskritam

“A Duolingo-shaped path for learning Sanskrit.”

A lesson-based Sanskrit learning app — alphabet, greetings, verbs, the usual path. The mechanics came together fast, but for a language app the content *is* the product, and building a real curriculum solo was a mountain I didn’t have the bandwidth for. Stalled at the skeleton.

For content-driven apps, the code is the easy 20%. If you can’t commit to the content, the app was never the real project.

Tweetwit

“Authentic Twitter growth, minus the guesswork.”

A Twitter/X growth tool that needed the X API to do anything useful — daily tasks, analytics, a Python niche-detector, the whole thing. By late 2024 that API had become an enterprise-priced toll booth on top of a hobby-scale idea. The product worked; the economics never would. Pulled the plug before launch and salvaged the idea into Twitalyst.

Don’t build a business on a platform that can change your unit economics overnight. Validate the cost of your hardest dependency before writing the fun parts.

Twitalyst

“Track and analyze your Twitter performance.”

Tweetwit, stripped down and rebuilt to be cheaper to run. Same X API, same enterprise pricing, same dead end — just confirmed faster this time. Killed within days once it was clear a lighter codebase doesn’t fix a broken dependency. That was the end of the Twitter-tools chapter for me.

Rewriting the code doesn’t fix a problem that lives outside the code. Sometimes the right move is to stop, not to refactor.