As case study
Royal Subz
A subscription marketplace for South Asia that grew, in a year, from one product and one manual payment method into four payment rails, an AI sales agent and a small team.
Role
Founder · Product & engineering lead
Timeline
Nov 2025 — Present
Status
Live
Live site
royalsubz.com
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, such as design tools, productivity suites and AI subscriptions, but the payment friction and pricing put them out of reach.
Royal Subz exists to close that gap: a trusted, locally payable storefront for the subscriptions people in this region already want, with support that speaks their language. A year in, it serves 200+ customers in 20+ countries.
How it started
Royal Subz went live on 15 November 2025. The first paying customer arrived on 27 January 2026, about three months after the first conversation about the idea.
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 and live chat. The content engine came later than it should have, which the SEO case study is honest about.
The year at a glance
The first version was deliberately small. Almost everything since has been about making it trustworthy at a larger size: payments that confirm themselves, promises that are true, and systems that keep running when I’m not watching them.
-
Oct 2025
The idea, tested on people first
Two weeks of conversations, no code. SaaS subscriptions blocked by payment friction came up as the strongest signal.
-
15 November 2025
Live
The smallest believable thing: one product, one payment method, manual fulfilment. The customer sends money, types a transaction ID, I approve it.
-
27 January 2026
First paying customer
About three months from the first conversation to the first payment.
-
Mar 2026
The content engine starts
A blog CMS that refuses to publish without its SEO fields, then one focused post a week.
-
Spring–summer 2026
The systems behind the store
Moved to Oracle Cloud. Rebuilt email without stopping it. Crawler snapshots for the SPA. Revocable admin sessions. A refund ledger. Invoices and payment links. Mobile performance.
-
Sep 2026
Support desk and AI sales agent
A self-hosted desk on a second server, and an agent that can only quote numbers the database just gave it.
-
1 Oct 2026
EPS live
Mobile wallets, local and international cards, internet banking, credited automatically.
-
9 Oct 2026
PassimPay live
USDT on TRC20 from a $2 minimum instead of $14.51, plus USDC, BTC and ETH.
-
14 Oct 2026
Storefront redesign launched
Twelve phases, one launch, every claim on the site checked first.
-
Next
Bangla QR
The next local payment method.
How I build
I don’t write most of Royal Subz’s code by hand any more. I plan the work, make every product and architecture decision, review every change and test it myself; AI coding agents write most of the code.
That isn’t a shortcut around the engineering. It moves my time to the parts that decide whether a system is right: reading a gateway’s documentation until I find what it leaves out, deciding what a refund means before anyone designs a table, and writing the test a customer would otherwise run for me.
The big systems of the last few months, from payments to the redesign, all ran the same loop.
- 01 Me
Research and questions
Read the vendor docs and samples, test claims against the sandbox, list every decision that is mine to make.
- 02 Me
A written plan, in phases
Each phase ships on its own and can be switched off. Decisions are recorded so nobody asks twice.
- 03 Agent
Build one phase
AI coding agents write most of the code, against the plan and the existing conventions.
- 04 Agent + me
Self-review
Completeness, bugs introduced, what might break later, refactors. Written into the plan, not skipped.
- 05 Me
Test it myself
A numbered test script including a failure path, run against real data on test invoices.
- 06 Me
Ship inert, then switch on
There is no staging database, so new paths go live disabled and are enabled deliberately.
The loop is deliberately slow where it matters. The EPS integration took three days and nine phases; the storefront redesign took twelve phases and one launch. Each phase passed its own test script before the next started, and each recorded what might break later, so the next phase could check.
The store itself is run by a small team: a support agent, a graphic designer and a content writer. That’s what lets me spend days on one system without the store waiting for me.
Architecture today
Royal Subz runs on two Oracle Cloud servers and one Supabase project. I moved the storefront from DigitalOcean to Oracle Cloud around May 2026. The support desk has its own server, so a support outage can’t take the checkout with it.
Customer
Browser, phone or desktop
20+ countries
↓ Uses the store, or writes to support
Storefront
React + Vite behind nginx
Oracle Cloud VPS · Umami analytics
↓ Reads and writes through
Supabase
Postgres + row-level security · Auth
51 edge functions · 5-min reconcilers
↓ Starts payments with, then verifies against
Payment gateways
EPS · PassimPay · Binance Pay
Our server verifies every payment
Support desk
Self-hosted Chatwoot
Second Oracle VPS, apart from the store
↓ Sends each message to
AI sales agent
Python adapter over Tailscale
No tools, no direct database access
↓ Looks up product facts in Supabase, or hands the chat to a human
The stack is still ordinary on purpose. Supabase gives one person a database with row-level security, auth and serverless functions without owning three separate pieces of infrastructure. The unusual parts are everything around money: three gateways, each with its own way of proving a payment, and reconcilers that check every open payment on a schedule.
Frontend
Backend & Services
Payments & Infrastructure
Payments: from a typed transaction ID to four rails
Payments were the hardest part of building in Bangladesh, and the part that changed most.
At launch · Nov 2025
One manual path
- 1Customer sends the money from their own wallet
- 2Types the transaction ID into a form
- 3I find it in my own payment history
- 4I press Approve; the subscription goes active
At night, the wait lasted until I woke up.
Today · Oct 2026
Four rails, one settlement path
-
EPS
Every Bangladeshi mobile wallet, local and international cards, internet banking
-
PassimPay
USDT, USDC, BTC and ETH, from a $2 minimum on TRC20
-
Binance Pay
Verified automatically against the receipt’s order ID
-
USDT (manual)
Kept as a fallback, approved by hand
- 1Every order becomes an invoice, priced and frozen
- 2Our server asks the gateway whether it was paid
- 3One transaction writes the payment, fee and commission
- 4The order waits in To Activate; a receipt goes out
Four decisions made that possible.
One invoice core. Invoices, payment links, the cart and Buy Now all became an invoice behind the scenes, settled by a single locked database transaction. A gateway retry finds the invoice already paid and does nothing; it can never pay twice. One invoice, three ways to pay →
Nothing the gateway sends is proof. A return URL can be typed by anyone and a callback can be forged, so neither credits a payment. Our server asks the gateway directly, with its own credentials, and a reconciler catches anything a lost callback missed. How EPS was integrated →
Fees that never come up short. Gateway commission is grossed up and rounded up, so the business always receives the full price, and the price a customer reads comes from the same code that charges them. The 83 customers who paid before fees existed never pay one. PassimPay and the order of two fees →
A refund is not a status. Refunds became a case and a ledger instead of a flag, so partial refunds, replacements and honest revenue reporting all fit. A refund is not a status →
Trust and safety
In a market where many shoppers approach an unfamiliar site expecting a scam, trust is a product feature, not a badge.
Promises that are true. Most orders are delivered within 4–5 hours, and the Royal Commitment guarantees delivery within 48 hours or a full refund. Every promise on the site is built from one facts file, after a review found 313 sentences that contradicted it. True before pretty →
Sessions that can be ended. Every admin and staff session is visible and can be revoked at once, enforced by the database rather than the screen. Instant logout is an authorization problem →
Email you can trust to arrive. Receipts, invoices and password resets go through one observable, budget-aware system that knows whether each message was delivered. Rebuilding email while it was still sending →
Support and the AI sales agent
Support moved from a free-tier helpdesk to a self-hosted Chatwoot desk on a server that was sitting idle. An AI sales agent now answers first. It has handled 50+ chats on its own and converted 13 customers without a human stepping in.
It can only quote a price or stock level the database handed it in the same turn, and it hands any conversation to a person when it isn’t sure. The full case study →
Growth
Search is how most customers find Royal Subz: about 70% of sales start with a search, and the site had 3.35K organic visits in the last 30 days. Google sent 5.01K clicks in the last three months, at a 2.5% click-through rate that was 0.3% in April. The blog has 17 posts, built around the price questions official sites don’t answer; the biggest, on getting Claude Pro for less, brought 1,557 clicks on its own in that time.
Keeping that traffic meant keeping search engines able to read a single-page app, with route-specific snapshots and honest status codes, and making sure no redesign changed a word Google reads. The SEO case study → · Making an SPA tell crawlers the truth →
The storefront redesign
In October 2026 the whole storefront was redesigned in twelve phases and one launch: a product page where everything needed to decide fits on one phone screen, two products per row in the catalogue, a merged Orders & Billing area, and a new look built from the logo’s own blues.
It started by making every claim on the old site true, and ended with an honest speed report: the homepage got almost three seconds faster on a phone, and the product page got a second slower, which is the next thing to fix. True before pretty → · Making mobile feel unremarkable →
Outcomes
$3,000+ since the first paying customer on 27 January 2026.
Paying customers in 20+ countries, paying in taka, by card or in crypto.
From search alone, led by a 17-post blog built around questions the official sites don't answer.
Customers the sales agent converted on its own, across 50+ chats it handled without a human.
What changed in a year
The numbers are still small by SaaS standards, and they were never the main point. In a year, Royal Subz went from one product and one manual payment method to 54 products on four payment rails, payments that credit themselves and are checked by the server, a support desk with an agent that sells, and a storefront whose every claim is true.
It also changed how I work. I no longer write most of the code by hand. I research, decide, plan in phases, review and test, while AI coding agents implement. Running a small team (a support agent, a graphic designer and a content writer) means the store keeps running while I build the next system.
What I’d do differently
Write the facts down before the first product description
For months the site promised delivery "within 15 minutes" and a "7-day refund" on dozens of products, while real delivery took 4–5 hours and the refund policy said something else. The promises lived in each product's description, written one at a time and never checked against each other. The fix was one facts file that every promise is built from, and a script that rewrote 313 sentences to match it. If I started again, that file would exist before the first product went live.
Have a staging database from the start
Royal Subz has no staging database, so every phase of the big features shipped switched off against live data and was enabled deliberately. That discipline worked, but it had a cost. Every migration had to be written defensively against a live schema that had drifted from the repository, and twice a "preview" on my own machine showed an unfinished payment method to real customers. A staging copy would have made both mistakes impossible.
Build the background check with the first gateway, not the third
The first automated gateway credited a payment only when its webhook arrived. With no background check, a lost webhook meant a customer who had paid and was never credited, and nobody would know. Every gateway since has had a reconciler that asks about every open payment on a schedule, and a log that shows it ran. It should have been there from the first automated payment.