Deciding when a side project is ready to become a product

Written By: BrainSoft In Engineering

Most side projects die quietly in a private repo, and that's fine. The awkward part is the ones that don't: you've got something running, a handful of people use it, and now you're wondering whether to keep it as a weekend thing or start treating it like a product. That decision is easy to postpone and expensive to get wrong in both directions.

A project is ready to become a product when people you don't know depend on it, at least some of them pay, and you can support, secure and host it without wrecking your week. Below are the signals I actually look for before committing, and the ones that mean keep it a hobby.

The demand signals that matter

Enthusiasm is cheap. Stars, retweets and "this is cool" messages cost nothing to give. What I watch for is friction people are willing to absorb: they sign up without being asked, they come back a second and third week, and they complain about missing features rather than the thing existing at all.

• People you have never met found it and are using it regularly.
• Someone asked to pay, or asked for an invoice, before you had pricing.
• Users work around missing features instead of leaving.
• You get bug reports with reproduction steps, which means they care enough to investigate.

The strongest single signal is a stranger asking to pay. Not a friend offering to chip in, not a "you should charge for this" comment. An actual request for a payment link. That tells you the value is real and the buyer has budget authority.

The operational checks before you commit

This is where most side projects fail the test, and it has nothing to do with the code quality. A product has obligations. If a user's data disappears or leaks, you own that. Before I flip the switch, I walk through a short list.

• Backups you have restored. A backup you have never tested is a hope, not a backup. Restore to a scratch database and check the row counts.
• Auth and secrets. No hardcoded keys, no shared admin password, sessions that expire. If you store passwords, they're hashed with something current.
• Deploys you can do half asleep. If shipping a fix takes an evening of manual steps, you'll stop shipping fixes.
• Somewhere for support to land. An email address that reaches you, or a form that doesn't silently drop messages.
• Terms, privacy policy, and a refund stance. Boring, but payment processors ask for them.

A quick sanity check on your deploy and backup story, if you're on a VPS or a small container setup:

# did the nightly dump actually land?
ls -lh /var/backups/app/ | tail -n 3

# restore it somewhere safe and count rows
pg_restore -d app_restore_test latest.dump
psql -d app_restore_test -c 'select count(*) from users;'

If that sequence makes you nervous, that's your answer for now. Fix the operations before you take money. This is the same discipline we apply on client work, and it's usually a week of effort, not a month. If you'd rather hand it off, our services cover the DevOps and hosting side.

Cost, time, and the honest math

A side project costs you evenings. A product costs you evenings plus a support inbox plus the mental load of knowing strangers are affected when it breaks. Run the numbers roughly before you commit, because the surprise is rarely the server bill.

• Hosting and database: usually small, but check egress and managed database pricing.
• Third-party services: email delivery, error tracking, payments. These add up faster than compute.
• Your time on support and incidents. Estimate an hour per paying user per month early on, then watch the real number.
• Tax and accounting overhead once money moves. Ask someone local.

If a modest number of paying users doesn't cover the running cost plus a few hours of your time, it's a portfolio piece or a gift to the community, and that's a legitimate outcome. Just name it clearly so you don't resent it later.

When to keep it a side project

Some projects should stay small. If you'd hate doing support, if the domain needs compliance work you can't staff, or if the only users are you and three friends, keep it as a tool. Open source it, write about it, move on. Turning it into a product because it exists is the wrong reason.

The opposite trap is waiting for the code to feel finished. It never will. The readiness question is about users, obligations and economics, not about whether the refactor is done. If those three line up and the code is merely okay, ship it and fix things with real feedback. If you want a second opinion before you commit, get in touch and we'll look at it with you.

Frequently asked questions

#Engineering