Building a SaaS from Indonesia

I shipped a wedding-invitation SaaS called Marryio alone. Frontend, backend, payments, infrastructure, design, customer support — all one person. This is what I learned shipping it.

The premise

Wedding invitations in Indonesia were stuck between two extremes: cheap WhatsApp-graphic services with no UX, and overpriced custom-coded sites that took weeks. Multi-tenant SaaS was the obvious gap, but nobody filled it because the market is messy: 17+ regional preferences, family-religious-event variations, and payment rails that international tools don’t speak.

So I built it.

Tech decisions, in retrospect

I picked Next.js + Supabase + Tailwind because that stack lets one person ship at three engineers’ pace if you’re disciplined. Specific calls:

Supabase RLS for multi-tenancy. Every row knows its tenant. RLS policies enforce isolation at the database, not the application. This stopped a whole category of bugs from existing.
Midtrans for payments. Foreign payment processors don’t natively support QRIS, GoPay, ShopeePay, or Indonesian VAs. Midtrans does. Webhook handling was the hard part — refund flows took two iterations to get right.
Cloudflare R2 for media. Customer-uploaded photos at unpredictable scale. R2 is S3-compatible, costs nothing for the egress patterns weddings produce.
17 templates, single source of truth. Templates are React components, not stored as DB rows. A change to the template rolls out to all customers using it on next deploy. No “template state migration” headache.

If I were starting today, I’d still use this stack — but I’d pick one thing differently: a stricter test discipline from day one. I added Vitest later. I should have led with it.

What “solo” actually means

Solo doesn’t mean working alone in silence. It means:

I am simultaneously the engineer, the designer, and the support agent.
The cost of context-switching dominates everything else.
I write the changelog, I run the campaign, I refund the customer who clicked the wrong button.

The leverage comes from accepting that and scoping ruthlessly. Every feature I refused to build was a feature that didn’t break. Every dashboard I didn’t add was an hour I shipped a real fix.

Payment rails are the moat

Foreign founders building Indonesian products underestimate this. Midtrans setup is not “install SDK.” It’s:

Sandbox onboarding (1-2 weeks of back-and-forth with their team)
Webhook authentication (must be HMAC-verified, never trust the payload alone)
Refund flow (asynchronous, requires status polling)
Settlement reconciliation (T+1 to T+3 depending on method)

Everyone who does this once has a small moat. After 12 months, you have institutional knowledge that competitors must rebuild.

What I’d tell my past self

Constraints are the feature, not the obstacle.

Indonesia-only? Good — that’s a product, not a limitation. Solo dev? Good — you can ship in a day what a team would meeting about for a week. No funding? Good — every paying customer is real signal.

The trick is to not fight the constraints. Use them as the product spec.

What’s next

AI features for invitation copy generation (when the budget permits running production LLM calls at scale)
Reseller tooling (already shipped — V1 has 3 roles)
Internationalization (deliberately not yet — focus before optimization)

Marryio is profitable on its current numbers. That alone makes the year worth it.

If you’re building something similar — solo, Indonesian, in a market the global tools ignore — talk to me. I have notes I haven’t written down yet.

Updated 2026-04-15. Originally drafted while debugging a Midtrans webhook timeout at 2am.