As case study
Royal Subz
A SaaS marketplace I built and launched solo — design, dev & infrastructure.
At a glance
The problem
Buying SaaS subscriptions in Bangladesh and across most of South Asia is harder than it should be. Local cards get rejected by half the global SaaS providers. PayPal accounts get flagged and frozen. Stripe doesn’t support local issuing banks. And the friends with foreign cards — who do work — are slow, expensive, and often unreliable.
For independent operators, students, and small teams, that gap is real. They want the same tools their counterparts in the US and UK use — design tools, productivity suites, AI subscriptions — but the payment friction and pricing make it inaccessible for many who simply start.
Royal Subz came to close that gap: a trusted, locally accessible storefront for the SaaS subscriptions people in this region already want, with support that speaks their language.
How I built it
A solo build, no outside help: drop a usable storefront in 90 days, then let real users decide what gets built next.
Validate before building
I spent the first two weeks on zero code. I talked to 10–15 people in my network — users who pay for the workaround, payment middlemen, and small team leads — and mapped out what they actually pay for. Third-party SaaS subscriptions came up as the strongest signal. I decided to focus on this first.
Pick a stack I can ship alone
React for the storefront, built on top of Supabase because its managed Postgres + auth + storage meant one person could own the entire stack and not get buried by infra. Every choice optimised for: ship fast, stay debuggable.
Launch the smallest believable thing
One product, one payment method, manual fulfilment. Not because I planned to keep it manual — because simplicity forces you to understand where the real friction is before automating it. That constraint shaped the first three months.
Build the trust layer in parallel
In this region, 'is this a scam?' is the first question every visitor asks. I built trust signals from the start: real pricing, transparent terms, live chat, and a content strategy that made the domain look established early. SEO from day one meant I wasn't starting from zero.
Tech & architecture
Boring stack, on purpose. Solo-built, solo-deployed, solo-operated. Every choice was made for two reasons: ship fast and stay debuggable when I’m the only person on call. The one place I went non-standard: a hybrid local-plus-crypto payment system serving a Bangladesh-first user base with international reach.
Frontend
Backend & Services
Infrastructure
Customer
Browser
React app
DigitalOcean VPS (nginx)
Supabase
Auth + Postgres (RLS)
Edge function
process-checkout
Payment rail
bKash · Nagad · Bank · Crypto
Customer
Browser
React app
DigitalOcean VPS (nginx)
Supabase
Auth + Postgres (RLS)
Edge function
process-checkout
Payment rail
bKash · Nagad · Bank · Crypto
Hybrid payment system — 70% local rails (bKash, Nagad, bank), 30% international crypto. Manual confirmation across all rails keeps fraud risk near zero at this volume.
Outcomes
Grew from $0 to $110 MRR within 3 months — without paid acquisition, with 0 ad budget.
35 paying customers found the product, trusted it, and renewed — entirely through organic search.
39.9K monthly search impressions from 0 — driven by a structured content and keyword strategy.
Idea to first paying customer in 90 days, solo, while employed full-time.
What changed
The numbers alone are small by SaaS standards. The point of Royal Subz at this stage isn't scale — it's proof. Proof that the payment friction was real, that 35 people found it worth paying for, that the SEO work was right (39.9K impressions with 0 budget), and that one person can understand payment rails, customer operations, and the technical craft of running an e-commerce platform — because I owned all of them.
What it proved: building solo forces you to make every part of the system work, not just the parts you're good at. I now understand payment rails, live customer operations, and SEO as first-hand skills, not adjacent knowledge. I understand the frontend code — because I wrote all of it.
What I’d do differently
Automate fulfillment on day one
I launched with manual order confirmation — intentional, to reduce complexity at launch. But "temporary" manual processes have a way of staying manual. Every order I confirmed by hand was time I couldn't spend improving the product. If I did this again I'd build even a minimal fulfillment webhook before taking the first payment, not after reaching 30 users.
Start the content engine earlier
SEO results took 60–90 days to materialize, which is just how search works. But I waited until the storefront was "done" before publishing content — a mistake. The content calendar should have started the same week as the first line of code. Two months of compounding I left on the table.
Talk to churned users, not just active ones
My support loop was good at keeping existing users happy. It was much worse at learning from people who tried the product and didn't convert, or who cancelled after one month. I have almost no data on them. Next time I'd instrument a lightweight exit survey from the beginning — one question, one minute, mandatory.