Intro #
Yesterday, my hobby project — Sprytna.Cards — experienced an unexpected 8-hour outage. With only 18 active users, this may sound small, but it was an extremely frustrating and humbling experience. It also sparked some deeper reflection: where is the line between a fun little side project and something others depend on? And what responsibilities come with that shift?
The Incident #
Context #
Sprytna.Cards is hosted on Fly.io, a platform I love. Until yesterday, I was literally using their “hobby plan,” and my database was running on an unsupported “beta Postgres cluster.” It was cheap and perfect for experimenting — which made sense for what I considered a casual side project.
On the morning of July 25, 2025, I was preparing to deploy a new feature that required a database migration. Although I already had daily backups, I wanted to create one more, just to be safe. So I ran:
fly postgres backup create -a <app-name>
(Spoiler alert: don’t run this command on an unsupported Postgres cluster.)
That triggered the beginning of the end: the cluster became unstable and entered a read-only state. Any Fly command I ran afterward returned a message like, “That is only supported on x and y clusters, you have z.” There was no recovery path for the cluster I was using.
For hours, I attempted to get help — but quickly learned what “unsupported” really means. Thankfully, I was able to manually back up the data and save it locally. After upgrading my account and service level, I provisioned a managed Postgres cluster, restored the data, updated the app configuration, and brought everything back online.
The result? Sprytna.Cards now runs on a more robust setup with hourly backups, a supported database and app cluster, and — I think — a slight performance boost (but don’t quote me on that).
The Transition from Hobby to “Something Else” #
Sprytna.Cards started as a personal sandbox — a way for me to learn, experiment, and maybe offer something useful to a few friends. But I’m realizing that doing something useful isn’t just about writing good code. It’s about showing up — especially when things go wrong.
Eighteen non-paying, enthusiastic users have come to rely on this project. That number might sound small, but their trust makes it feel very real. The truth is, I wasn’t taking that responsibility seriously enough. Sprytna.Cards has outgrown the sandbox.
Responsibility in the Beta Phase #
When you build something new, the goal is often to ship fast and get feedback. You want to learn:
- Is this useful to anyone?
- What’s missing?
- Would someone recommend it?
I love Reid Hoffman’s quote: “If you’re not embarrassed by the first version of your product, you’ve launched too late.” But there’s a tension between shipping fast and earning trust. How transparent do you need to be about risks, fragility, and limitations?
Being clear about expectations — “this is still a hobby project,” or “this might go down unexpectedly” — matters. But so does recognizing when something has grown beyond that phase. Even in beta, people are trusting you with a piece of their day.
Apology and Appreciation #
To the small but incredibly supportive group using Sprytna.Cards: I’m sorry if you tried to use your card during the outage. I’ve been treating this like a toy, and that’s not fair to you.
I appreciate everyone who has taken the time to try the platform, share feedback, or even use it in real-life situations. While Sprytna.Cards is still in beta — and that comes with risks — I’m no longer treating it like just a hobby.
What’s Next #
As Sprytna.Cards grows from a hobby project into a real beta product, I’m putting more effort into making it dependable. Things can still go wrong — but I’m working hard to reduce the odds.
I am also taking the valuable feedback I received and here is my plan for the next set of features:
- A better onboarding experience with a more intuitive starting point
- More control over the external links you can associate with your card
- Improved communication around updates, issues, and progress
Final Thoughts #
Building Sprytna.Cards has been a deeply rewarding experience. I’ve learned new tech, thought more deeply about design and user experience, and met people I might never have encountered otherwise.
There’s real joy in seeing something you made being used — and real pain when it breaks. Both are part of the process.
For other builders: pay attention to when people start depending on your work. That’s the moment to shift gears — to focus not just on features, but on reliability, communication, and support. Anticipate how you’ll handle things when they go wrong — because eventually, they will.
Thanks for following along.
Reply by Email