For a long time, I assumed building a real SaaS on my own was a multi-year project.
This time, I tried something different. I treated AI like a second set of eyes — not to write the system for me, but to help me think through architecture, edge cases, migrations, and all the boring glue that usually slows everything down. What surprised me most wasn’t that I built a small SaaS — it was that I got it into production in months instead of years.
That experience completely changed how I think about building, learning, and what’s actually possible as a solo developer.
My challenge
Outside of building the software, I like wandering through thrift stores and picking up items to resell in my eBay store. I started with a simple goal: make about $10 a day.
That goal didn’t last very long.
Once I got into a rhythm, it quietly turned into $30 a day instead. Not because I suddenly found better items — but because I started paying attention to the process. What I bought, how fast I listed it, where I stored it, how I packaged it, and how long it sat before it sold.
The more I treated it like a system instead of a side hustle, the more obvious the gaps became. Little things started adding up: items getting misplaced, having to file taxes at the end of the year using Form 1040 Schedule C, track cost of goods sold, end-of-year inventory, and purchase costs.
That’s when the original “I should track this” idea turned into “I should probably build something for this.”
And that’s the moment this small SaaS really started to exist.
The first testable version
The first version of the project was intentionally simple. A place to log what I bought, what it sold for, and whether it was still sitting on a shelf and its location (bins on a shelf).
It worked, seeing eBay orders come in and just being able to quickly grab the item and ship it was a huge improvement over my manual workflow!
As soon as it started getting used, the edge cases showed up. Batch purchases that needed to be split across multiple listings. Returns that only refunded part of a sale. Shipping costs that weren't included in eBay's API response, external shipping costs from third parties, etc.
That’s when the challenge became clear: this wasn’t just about tracking numbers anymore. It was about modeling a real workflow.
The project finally got a name — BinFlip.com — but the harder part was still ahead: figuring out how to keep the system flexible enough for humans, without letting the data turn into chaos again.
Today, I can finally put a name and a URL to this thing: the first beta of https://binflip.com.
Right now, it handles the core pieces I kept tripping over. It can manage inventory, storage locations, and purchase sources. It imports sales directly from eBay, calculates cost of goods, and pulls together a few basic reports so the numbers actually make sense in one place.
Is it perfect? Not even close.
Is it “done”? Definitely not.
There are still things on my list that feel very real in day-to-day use — like tracking mileage for trips to the post office, or keeping receipts tied to individual purchases and sales. Those problems are still sitting there, waiting their turn.
But for the first time, the system feels like something that can grow instead of something I’m constantly patching.
And that’s been a pretty good milestone to hit.
My goal with this isn’t to turn it into a big, expensive product. I want to keep it affordable — just enough to cover the real costs of running it and slowly build something sustainable.
For me, part of the appeal of building a small SaaS is creating a little bit of independence. The tech world moves fast, tools change, roles shift, and I like the idea of having something I own end-to-end — a system that can stand on its own, even if everything else around it changes.
A small bonus lesson
One unexpected side effect of building all this was that I ended up learning Kubernetes along the way.
I didn’t start this project knowing how to run a cluster. But curiosity got the better of me, and I deployed everything on a small Kubernetes setup in DigitalOcean as a learning experiment. That led me down a rabbit hole of wiring up external-dns to manage DNS records automatically, figuring out how to make services deploy automatically when I merge into the main branch, and teaching myself how to trust a system I couldn’t “see” in the same way as a single server.
What surprised me most was how fast everything started to feel. Watching pods spin up in seconds and seeing a deployment roll out cleanly after pushing code — once the GitHub Actions automation was in place — was one of those moments where the infrastructure itself became part of the fun.
There’s a whole story there about things that broke, things that worked, and things I definitely didn’t expect.
But that’s probably an article of its own!
If you’re curious to see how it works in practice, you’re welcome to try it at https://binflip.com — I’d love to hear what you think and what you’d improve first.
Top comments (2)
Great article! Keep up the good work.
Thank you!