Why I shipped Royal Subz solo before pitching it

Somewhere around month two of building Royal Subz, a friend asked me when I was going to pitch it to investors. I didn’t have a good answer. The honest one was: I wasn’t. At least not yet. I wanted to ship it first — get real users, real payments, real support tickets — and only then figure out if there was anything worth pitching.

That decision shaped everything about how the product got built. This post is about what I learned from it.

The constraint forces clarity

When you’re building solo with no funding and no safety net, every feature is a choice between shipping and not shipping. There’s no team to absorb the cost of a bad call. That constraint, which felt like a disadvantage at the start, turned out to be the most useful thing about the process.

I cut probably 60% of what I originally planned for v1. Not because I didn’t want those features — I did — but because every week without revenue was a week of pure cost. The constraint forced me to ask, for every piece of work: does a user need this to give me money? If the answer wasn’t yes, it moved to the backlog.

The constraint forced me to ask, for every piece of work: does a user need this to give me money? If the answer wasn’t yes, it moved to the backlog.

Shipping before pitching changes what you know

If I had pitched Royal Subz before launching, I would have been pitching a theory. I had a market thesis (payment friction in South Asia is real), a product concept (local-payable SaaS subscriptions), and a deck. What I didn’t have was evidence.

Three months later I had:

• 35 paying users who found the product without paid ads
• $110 MRR from a cold start
• 39.9K monthly search impressions on a brand new domain
• A clear picture of which products sell and which don’t
• Two support patterns that turned into product improvements

That’s a different pitch. More importantly, it’s a different product — shaped by what users actually did, not what I assumed they would do.

What “solo” actually cost

I’m not going to romanticize it. Solo was hard. Every bug was mine to fix. Every support ticket was mine to answer. Every SEO article was mine to write. There was no one to hand off to when I was stuck on something, and no one to catch me when I missed something.

The worst part wasn’t the volume — it was the context-switching. A morning of deep coding followed by an afternoon of customer support followed by an evening of content writing doesn’t produce great work in any of those three areas. It produces okay work in all of them, which was enough to ship but not enough to feel good about.

The tech cost

Building the stack solo meant every technology choice had to be one I could debug alone. That ruled out a lot of otherwise good options. I ended up leaning heavily on Supabase because its managed Postgres + auth + storage meant I wasn’t owning three separate infrastructure problems. The bet paid off — but it also meant I hit Supabase’s RLS learning curve hard and alone.

-- The RLS policy that took me three hours to get right
create policy "Users can only see their own orders"
on orders for select
using (auth.uid() = user_id);

If you’re building on Supabase solo, start with RLS from day one. Retrofitting it onto an existing schema is painful.

Would I do it again?

Yes. The solo constraint produced a leaner product, a sharper pitch, and — unexpectedly — a much clearer personal understanding of every part of the stack. I now understand payments, server ops, content strategy, and customer support as first-hand skills, not adjacent knowledge.

The thing I’d change: start the content engine at the same time as the first line of code. SEO takes 60–90 days to compound. Every week I waited before publishing was a week of compounding I left on the table.