Deployment Options for Little Redfox

1. Login codes (OTP)

When a parent, staff member, or admin signs in with their phone number, we send them a one-time code. The way we send that code matters for cost and for how real customers reach us. We can send codes by Text message (SMS), by email, or run a mix of both.

Local Thai SMS providers (ThaiBulkSMS, ExSender, etc.)

Recommended

SMS services based in Thailand that send codes through Thai networks (AIS, True/dtac, NT) directly. Since our customers are all in Thailand, this is where the savings live.

Setup: a few hours + sender-ID approval Cost: ~฿0.10–0.15 per message (~$0.004) Upkeep: vendor

Advantages

Roughly 5–10× cheaper than Twilio for Thai numbers.
Direct routes to Thai networks — fast, local delivery.
Billed in Thai baht; local support and Thai-language help.
No monthly fee — pay per message (some start as low as ฿0.10).

Disadvantages

Delivers only to Thai numbers — can't reach foreign phones.
Requires a Thai sender name (Sender ID) that must be registered/approved with carriers.
Some providers ask for a Thai-company contract — check before signing up.
Smaller documentation and support than the big international services.

Why we recommend it: for a strictly-Thai customer base, a local provider slashes the biggest recurring variable cost. It needs a short trial to confirm delivery, then becomes the default sender.

Twilio — the international option

Backup / global fallback

The most widely used texting service in the world. Reaches phones in Thailand and everywhere else, so it doubles as the safety net for non-Thai numbers.

Setup: a few hours Cost: ~$0.0305 per message in Thailand (~฿1.05) Upkeep: vendor

Advantages

Text messages arrive on any phone, any country.
Battle-tested at huge scale; very reliable.
No monthly fee — pay only per message sent.
One dashboard for codes, reporting, and troubleshooting.

Disadvantages

5–10× more expensive than a Thai provider for Thai numbers.
Per-message cost adds up for large volumes.
Spam-filtering rules can occasionally delay delivery.
We depend on a third-party service for every login.

Use as the fallback, not the default. Route Thai numbers to the local provider and non-Thai numbers (rare) to Twilio. This "smart routing" needs a small backend change — one SMS interface, two providers behind it, chosen by country code.

Email / SMTP (Amazon SES, SendGrid, Postmark, GMail)

Send the login code as an email instead of a text message.

Setup: an hour or two Cost: from ~$0 per month (SES ~$0.10 per 1,000 emails) Upkeep: vendor

Advantages

Very cheap — pennies per thousand.
No phone number needed; works internationally.
Good for quiet periods or mixed login methods.

Disadvantages

People check email far less often than texts — slower logins.
Codes can land in a spam folder and be missed.
Not everyone has an email address linked.

Best as a backup channel, not the main one — e.g. for staff without a phone, or when SMS fails.

In-app / printed code (dev-only)

How we run it now

During development we display the code on the screen so testers can sign in without a real network.

Setup: done Cost: $0 Upkeep: us

Advantages

Free and fast for testing.
No dependency on outside services.

Disadvantages

Not usable by real customers — codes are printed to logs.
Security risk if accidentally left on in production.

Development only. It must be turned off before going live — the app is built to refuse to work without a real sender.

2. Taking payments

Parents pay for haircuts when they book. A payment provider safely handles the money: it shows the payment screen, processes the card or QR scan, and tells us (and the bank) it succeeded. Every provider charges a small percentage of each payment — that's how they earn their fee.

Opn (formerly Omise) — our current partner

Already integrated Recommended

A Thai payment platform, already built into our app. Handles Thai cards, PromptPay QR, and mobile-banking payments.

Setup: mostly done — code is written Cost: ~3.65% cards · 1.65% PromptPay · flat ฿10 mobile banking Upkeep: vendor

Advantages

Purpose-built for Thailand: PromptPay, local cards, mobile banking.
Our integration is already built and tested (webhooks, refunds).
One provider covers cards + QR + bank apps together.
Fees charged per successful payment only — no monthly fee.
Auditable: we only trust confirmed, signed payment notifications.

Disadvantages

Every card payment costs ~3.65% — the biggest single fee.
Our checkout form is currently a simplified stand-in; a fully-branded card form needs finishing.
Fees are set by the provider and may change.

Why we recommend it: it's already integrated, Thai-specific, and needs no monthly fee. Stripe matches its domestic rates (below), so switching would add work with no cost benefit. Finishing the real card form here costs far less than switching providers.

Stripe

The most famous global payment platform — now operating in Thailand. Excellent tools, but it does not undercut Opn's local rates.

Setup: several days of work to re-wire Cost: domestic cards 3.65% + ฿10 · PromptPay 1.65% · international 4.75% Upkeep: vendor

Advantages

Slick, well-known developer experience and dashboards.
Worldwide reach and polished tooling.
PromptPay acceptance at the same 1.65% as Opn.

Disadvantages

Domestic cards cost the same as Opn (3.65% + ฿10) — no price advantage.
International cards cost more (4.75%), and disputes are ฿500 each.
We would have to re-write working payment code for no cost saving.

Not worth switching for our market. Same domestic rates as Opn, and re-wiring working code buys nothing. Reconsider only if we later need heavy international-card volume.

Thai bank gateways (2C2P, or bank partnerships with KBank, Krungsri, etc.)

Payment gateways run by, or partnered with, Thai banks and acquirers.

Setup: slow — paper contracts and bank onboarding Cost: negotiable; often a monthly fee + per-transaction Upkeep: vendor

Advantages

Sometimes lower negotiated rates at high volume.
Direct bank relationships can feel reassuring.

Disadvantages

Slow onboarding with contracts, paperwork, and reviews.
Less helpful dashboards, documentation, and support.
Would require new code and testing all over again.

Revisit only at high volume. At our size the savings rarely beat the setup cost.

3. The website — the part parents see

The booking website is a set of files the browser loads (frames, buttons, styles). It stays the same for everyone and just talks to our app engine for data. We have three main ways to serve those files to visitors: a managed hosting service, our own web server, or cloud storage + a delivery network (CDN).

Cloudflare Pages — managed website hosting (free)

Recommended

Cloudflare's website hosting, inside the account we already use for our domain, tunnel, and photo storage. Free, with automatic publishing and preview links.

Setup: a few hours Cost: free tier (500 builds/mo); then pay-as-you-go Upkeep: vendor

Advantages

Free automatic publishing and preview links straight from our code store.
Auto-rolls back builds that fail — a bad release never ships.
Free CDN, HTTPS, DDoS protection, and basic bot protection.
Stays in one company's account with our domain, tunnel, and R2 storage — fewer vendors and bills.
Almost nothing to look after once it's running.

Disadvantages

Couples us more closely to Cloudflare (already the case for DNS/tunnel anyway).
Free-tier limits (e.g. build minutes, bandwidth) can bite only if we ship huge sites.
No server-side code — fine, because our site is purely static.

Why we recommend it: for a purely static site, Cloudflare Pages gives us the same publish-on-save, preview links, and auto-rollback as Vercel — for $0, with no new vendor, next to the storage and tunnel we already use. This matches our lean, Thailand-only setup.

Vercel — the well-known alternative

A purpose-built hosting service for website files. Free to start; the paid plan adds team features we don't need for a static site.

Setup: a few hours Cost: $0 free (full CDN, previews, DDoS) · $20/seat for Pro extras Upkeep: vendor

Advantages

Polished preview links and developer experience.
Free tier already includes CDN, HTTPS, and bot protection.
Great if we later add serverless functions.

Disadvantages

One more service account and one more vendor to manage.
Pro tier's extras (advanced WAF rules, skew protection, RBAC) are irrelevant for a static Thai-only site.
Adds no capability Cloudflare Pages doesn't already give us free.

Only if we prefer it or later add server-side features. For today's static site it buys nothing extra over Cloudflare Pages.

Built into our own web-server image (nginx, on our own servers)

How we run it now

Ship the website files together with a small web server and run it ourselves, like a phone app you install on a server.

Setup: done Cost: part of the server bill Upkeep: us

Advantages

Everything on one server stack — fewer vendors.
The website and app engine share the same address, which simplifies logins and security.
No per-page or per-visitor hosting fees.

Disadvantages

We are responsible for keeping it running 24/7.
No built-in worldwide delivery network — may be slower for guests far away.
No easy preview links; every change is reviewed on the real site or not at all.
If we grow, we manage our own scaling.

Works fine today. Move to Cloudflare Pages when we want previews and less babysitting — both run at once if needed.

Cloud storage + CDN (S3 / R2 + a delivery network)

Store the website files in a cheap online "bucket" and serve them through a worldwide delivery network.

Setup: several hours of plumbing Cost: pennies to a few dollars/month Upkeep: vendor for storage; ours for connections

Advantages

Cheapest running cost of the three options.
Very fast worldwide delivery once set up.
Uses the same storage technology as our photos.

Disadvantages

Manual or scripted uploads — no automatic "publish on save."
No preview links for reviewing changes.
More setup needed (addresses, security, delivery network rules).

Sensible later if cost becomes very important (e.g. a pure R2 bucket). Cloudflare Pages already covers the static site at $0, so this adds plumbing with little benefit today.

One thing to get right no matter which front-end host we choose: our logins use a session cookie, and browsers only send it across origins when the website and the API share the same domain (e.g. the site at redfox.app and the API at api.redfox.app). The front end also needs the absolute API address baked in at build time. This applies to Cloudflare Pages, Vercel, and a bucket alike — so the change isn't about the host, it's about placing the site on a subdomain of the API's domain.

4. The app engine (API & worker)

This is the "brains" — the server that handles logins, shows availability, checks the calendar, and talks to the database and payment provider. It also runs background helpers (booking reminders, photo thumbnails). It needs to be online around the clock.

Your Raspberry Pi 5 (8 GB) — already at home

Lean pick

The Pi already runs maemoo and has spare capacity. Go runs happily on it, and since photos never touch the device, pressure stays low.

Setup: a few hours (Docker) Cost: ~฿30–40/month electricity (~$1) Upkeep: us — fully

Advantages

Near-zero cost — the Pi is already ours.
Runs both the app engine and background tasks comfortably.
Data stays physically with us.
Our Cloudflare tunnel (already running) safely exposes it to the internet.

Disadvantages

Shared box — maemoo and the salon app compete for the same 8 GB.
Single point of failure: if the Pi or its internet link dies, bookings stop.
We manage updates, restarts, and security ourselves.
Depends on home internet uptime (mitigated by the tunnel, but not eliminated).

Why it's our lean pick: it costs ~$1/month and already exists. The real rules to make it safe: (1) the nightly database backup to cloud storage, and (2) knowing how to bring it back quickly if the SD card or power fails. Start here; move to a managed service when revenue supports it.

A cheap Singapore VPS (Vultr / DigitalOcean)

Rent a small, always-on server in Singapore — close to Thailand (~30–70 ms round-trip) — and run the same Docker setup there instead of at home.

Setup: a few hours Cost: ~$5–24/month Upkeep: us — fully

Advantages

Cheap, but on professionally-run servers with guaranteed uptime.
Independent of home internet — no "the router rebooted" outages.
Easier to scale up or clone later than a home Pi.
Vultr is notably cheaper than DigitalOcean for the same size.

Disadvantages

A real monthly bill ($5–24) instead of ~$1.
We still handle updates, restarts, backups, and security patches.
No built-in health checks or rollbacks.

The "safer self-managed" option. If we want the Pi's low cost but don't trust home internet reliability, a small Singapore VPS is the sweet spot.

Render — managed app hosting

Run our app packages on a ready-made service that looks after reboots, security patches, and scaling. This is the plan in our written architecture — the "set and forget" option.

Setup: a few hours Cost: ~$7–75/month (web + worker + workspace) Upkeep: vendor — nothing for us

Advantages

Runs both the app engine and the background helper in one place.
Automatic restarts, health checks, and instant rollbacks on a bad release.
Publishes from our code store automatically.
Built-in HTTPS, logs, and security basics.
Cheap to start; clear pricing as we grow.

Disadvantages

Much pricier than the Pi or a VPS for our size.
Some advanced setup (private networks, strict regions) needs the paid plan.
We trust Render's servers — they're well-regarded, but we don't control them.

The scale-later option. When bookings grow and the ~$1 maintain-it-yourself math stops being worth it, Render removes almost all server babysitting in a few hours.

Fly.io

Place the app engine close to customers in many cities/regions. Strong for apps that need worldwide speed.

Setup: a few hours Cost: from ~$5–$30/month for our size Upkeep: vendor

Advantages

Run the same app close to customers around the world.
Generous small-scale pricing.
Solid for running long-lived background tasks.

Disadvantages

More configuration than Render for the same result.
European/US-focused culture; Bangkok speed is fine but not special.

Good alternative if we later expand to many countries. Not necessary for a Thai salon network.

Railway

A friendly hosting service, very easy to start with, priced on what you use.

Setup: a few hours Cost: roughly $5–$20/month at our size Upkeep: vendor

Advantages

Very fast to get running.
Transparent usage-based billing.
Also hosts a database, so fewer accounts needed.

Disadvantages

Smaller company than Render/Vercel.
Usage can creep up if not watched.
Fewer enterprise-scale features.

A fine, cheaper start. We prefer Render because running two app parts + database together is smoother there.

Big-cloud computing (AWS/GCP — "cloud run", "containers")

Run app packages inside Amazon's or Google's enormous cloud. Extremely capable but aimed at bigger teams.

Setup: days, not hours Cost: cheap to start, but easy to mismanage Upkeep: vendor + our extra skill needed

Advantages

Virtually unlimited scale when we grow.
Every tool imaginable under one roof.
Pay only for what we actually use.

Disadvantages

Complicated; needs skilled engineers to run safely.
Easy to accidentally run up a big bill.
Far more setup and moving parts than we need today.

Overkill for now. Revisit only if we outgrow the simpler services.

Our own Kubernetes cluster (small self-managed cloud)

How we run it now

Kubernetes is a system for running many app packages on your own servers. We currently run one on a small home/office cluster, exposed through a Cloudflare tunnel.

Setup: already done Cost: hardware + electricity, no hosting bill Upkeep: us — extensive

Advantages

No monthly hosting bill for the app itself.
Great for learning and full control.
Everything lives with us — good for experimenting.

Disadvantages

We must manage repairs, power, network, and updates ourselves.
No 24/7 vendor guaranteeing it stays up.
If the physical machine goes down, the whole business is down.
Demands deep expertise to keep secure and healthy.

Great for development; keep it for testing. For the live business, the Pi or a managed service is simpler to run than a cluster.

Going back to a previous version (rollback). We deploy with Pulumi, which pins the exact version of the app as an image tag. Rolling back a bad release is therefore simple and safe: set the config tag back to the last known-good version and re-run pulumi up — Kubernetes swaps the app back to the old image. Three rules that keep this honest: (1) always roll back through Pulumi (never a manual kubectl rollout undo, or Pulumi's record drifts from reality); (2) keep Pulumi's state backed up — it's the map of everything we run; (3) a bad database change is rolled back by restoring the nightly backup from the photo bucket, not by redeploying.

5. The database (PostgreSQL)

This is the master list of all our bookings, customers, children, and payments. It must never lose data and must be backed up automatically. We can either let a specialist company manage it for us, or run it ourselves.

Running PostgreSQL on our Raspberry Pi — with an automated cloud backup

Lean pick

Install the database on the same Pi as the app. The database stays tiny (rows, not photos), so the bundled Pi 5 microSD is plenty.

Setup: a few hours Cost: ~$0 extra (part of the Pi) Upkeep: us — plus one script

Advantages

No database bill at all.
Fast local access — the app and database are on the same machine.
Full control; no vendor limits.

Disadvantages

We must arrange backups — that's the whole game.
No automatic recovery if the SD card or disk fails.
Updates and security patches are on us.
Single point of failure: losing the Pi loses the live database.

Perfectly viable IF one rule is followed: an automated nightly backup (a simple pg_dump script) uploads an encrypted copy to the same cloud bucket that holds the photos. Then even a dead Pi or dead SD card costs nothing but a reinstall. You already do manual backups for maemoo — this one scripts itself so it can't be forgotten.

Managed database on the same platform as the app (Render Postgres / Railway / Neon)

Rent a database from a company that specializes in keeping it safe, backed up, and available — preferably the same company that runs our app for fewer accounts to manage.

Setup: minutes Cost: Render from $6 (256 MB) / $19 (1 GB) · DigitalOcean from ~$15 Upkeep: vendor

Advantages

Automatic backups — data can be restored if something goes wrong.
Point-in-time recovery: roll the database back to "yesterday at 3pm."
Security patches and TLS encryption handled for us.
Health monitoring and alerts included.
One bill with the app if hosted on the same platform.

Disadvantages

A monthly cost that grows with storage.
We don't control the underlying machine.
Free tiers are limited and not for production.

The no-maintenance alternative. If the monthly $6–25 is fine, the vendor handles backups and recovery for us — the safest, simplest option at the price of a subscription.

Neon (serverless PostgreSQL)

A modern managed database that "sleeps" when idle and wakes when needed — cheap when quiet, scales when busy.

Setup: minutes Cost: free to start; ~$19–$60/month as you grow Upkeep: vendor

Advantages

Automatic backups and instant data recovery.
Can "rewind" to any moment in the past — great for fixing accidents.
Billing scales down when unused.

Disadvantages

A separate vendor from the app — another account and bill.
Global cloud (US/EU); data travels further from a small Bangkok app.
Pricing math (compute hours) is more complex to predict.

Excellent alternative — especially the ability to roll back instantly. Choose it if we want a specialist database company.

Big-cloud databases (AWS RDS / Google Cloud SQL)

Database hosting inside Amazon's or Google's giant clouds. Very robust, heavy-duty, and aimed at larger teams.

Setup: hours to days Cost: ~$15–$50+/month plus careful setup Upkeep: vendor

Advantages

Industry-leading reliability and backups.
Almost unlimited growth.

Disadvantages

Complex to configure correctly.
Easy to over-provision and pay too much.
Overkill for our current size.

Not needed yet. The simpler managed options cover us for years.

Storage reality check — do we need a bigger card or a hard drive? No. The booking database is made of conversations and payments — the whole data set stays well under 1 GB for years (photos never go in the database). The bundled Pi 5 microSD is a quality card and is genuinely fine to launch on. The one thing that wears out cheap cards is constant writing — but a low-traffic salon writes very little. Plan: start with the bundled card at $0. If traffic grows, a small 128 GB USB SSD (~$20–30, sized for constant writes) is the upgrade. A big hard drive is wasted money here.

6. Photo storage (S3-style object storage)

Haircut photos, gallery images, avatars, and thumbnails are kept in an object store — essentially a very big, safe folder on the internet. The app keeps the folder private and hands out short-lived links only to the right people. Every option here works with our app because they all speak the same storage language.

Why this should be a cloud bucket, not on our device. The app sends photos straight from the visitor's browser to the bucket using short-lived signed links — the bytes never pass through our server at all, and the worker only creates temporary files while making thumbnails. So the Pi stores just the tiny database, and the same bucket can also receive the nightly database backup. Cheap home internet is fine for this — the device barely carries any photo traffic.

Cloudflare R2

Recommended

Object storage from Cloudflare — the same company already protecting our website. Famous for not charging for visitors reading files.

Setup: a few hours Cost: ~$0.015 per GB-month; downloads are free Upkeep: vendor

Advantages

No download/transfer charges — cheap as galleries grow.
Free tier (10 GB) covers our start.
Same company as our domain/security — fewer vendors.
Private by default; works with our short-lived-link security.

Disadvantages

Slightly less famous than Amazon S3 (but fully compatible).
Regional "hot spot" pricing for very obscure regions — not an issue for us.

Why we recommend it: no download fees means a growing photo gallery stays predictable to budget, and it slots right into the Cloudflare services we already use.

DigitalOcean Spaces

Simple object storage with a very flat, predictable price — one fixed fee covers a lot of photos and downloads.

Setup: a few hours Cost: $5/month flat = 250 GB storage + 1 TB transfer included Upkeep: vendor

Advantages

One predictable $5/month bill — no per-download surprises.
250 GB + 1 TB transfer is far more than a salon will use.
Built-in delivery network for fast gallery images.
Same S3 language — works with our app unchanged.

Disadvantages

A flat $5 even if we use almost nothing.
Another vendor account and bill.

Excellent if we prefer a flat, predictable price over pay-per-GB. Both R2 and Spaces fit the app the same way.

Amazon S3

The original, most popular object store on the internet. The safe default choice.

Setup: a few hours Cost: ~$0.023 per GB-month + download fees Upkeep: vendor

Advantages

The industry standard — most compatible with every tool.
Rock-solid reliability and eleven-nines marketing.
Fine-grained security controls.

Disadvantages

Charges for downloads, which grow with gallery views.
Pricing pages and settings are technical.
Another giant-cloud account with its own bill.

The safe classic. If the team is already comfortable with AWS, S3 is a perfectly good choice.

MinIO on our own server

How we run it now (in development)

Open-source storage software we run ourselves. Fully compatible with the standard storage language.

Setup: done for dev Cost: no service bill Upkeep: us — fully

Advantages

No monthly storage bill.
Full data control and privacy.
Great for learning and testing.

Disadvantages

We manage backups, disk failures, and updates.
If the server dies, photos could be lost.
No built-in worldwide delivery for gallery images.

Keep it for development and experiments. For customer photos in production, a cloud bucket (R2/Spaces) is safer than a device-only store.

Backblaze B2 / Google Cloud Storage

Other respected object stores, all compatible with our app. Each has a slightly different pricing style.

Setup: a few hours Cost: ~$0.005–$0.023 per GB-month + download fees Upkeep: vendor

Advantages

Backblaze B2 is the cheapest on paper.
Google has generous free tiers for new accounts.
Both speak the standard storage language.

Disadvantages

Another vendor, account, and bill each.
Download charges vary and can surprise.
Google's console is as technical as Amazon's.

All acceptable. R2 (free downloads) and Spaces (flat $5) simply fit our small-business scale best.

What about Dropbox / Google Drive? They're great for the team sharing files, but they can't run the app's storage. The app depends on two things they don't offer: an S3-style signed-upload flow (the browser uploads straight to the bucket) and per-branch, short-lived access links. Using Dropbox/Drive would mean routing every photo through our server — slower, costlier, and a re-build. Keep them for manual archiving and human sharing; the app itself uses a real bucket.

7. Three ways to run it (monthly cost)

Here's the whole picture as three ready-made bundles — from "hand everything to professionals" to "squeeze the most out of what we already own." Prices are typical monthly totals and assume a modest launch volume; SMS and payment fees scale with usage.

All-managed cloud

≈ $70–100/mo

Website: Cloudflare Pages — $0
App engine: Render (web + worker + workspace) — ~$50–75
Database: Render Postgres — ~$19
Photo storage: R2 — $0–5

Least to look after. Matches our written architecture. Pricey for launch.

Pi hybrid (our lean pick)

≈ $1–6/mo + SMS & payments

Website: Cloudflare Pages — $0
App engine: Raspberry Pi 5 — ~$1 electricity
Database: Postgres on the Pi — $0
Photo storage + backups: R2 or Spaces — $0–5

Uses what we own. Needs the nightly cloud backup and a hands-on operator.

Singapore VPS

≈ $10–35/mo

Website: Vercel — $0–20
App engine: small VPS (Vultr/DO) — $6–24
Database: on the VPS — $0
Photo storage + backups: R2 or Spaces — $0–5

More reliable than home internet, still cheap, still self-managed.

Payments and SMS are "variable" on top. Payment fees are a percentage of bookings (Opn: ~3.65% cards / 1.65% PromptPay). SMS adds up to a few dollars a month at launch, and stays tiny with a Thai provider at ฿0.10–0.15 per code. All three scenarios can start with the same payment, SMS, and storage choices — they differ only in where the app and database live.

8. One-page summary & recommendation

For a Thailand-only salon network launching on a budget, the lean path makes the most of what we already own, and every piece is a standard, well-known service that can be swapped later without rebuilding the app.

Part	Recommended choice	Why (in one line)	Typical monthly cost
Login codes	Thai SMS provider + Twilio fallback	Thai numbers at ฿0.10–0.15; Twilio catches any non-Thai number.	pennies–a few dollars
Payments	Opn (Omise)	Already built in; supports Thai cards, PromptPay, and banking apps.	~3.65% cards / 1.65% QR
Website	Cloudflare Pages	Free publishing, preview links, and auto-rollback, next to the storage and tunnel we already use.	$0
App engine	Raspberry Pi 5 (already owned)	~$1/month electricity; already running our other service; exposed safely via the Cloudflare tunnel.	~$1
Database	PostgreSQL on the Pi + nightly cloud backup	$0 to run; the automated nightly dump to the photo bucket makes it safe against device loss.	$0–$5 (backup storage)
Photo storage	Cloudflare R2 (or DigitalOcean Spaces)	R2: no download fees · Spaces: flat $5. Both store photos and the nightly DB backup.	$0–$5

When to switch each piece to "managed." The lean picks are the start. As bookings grow: move the app engine to Render when maintain-it-yourself stops saving enough ($50–75/mo), move the database to a managed service when we want backups fully on someone else ($6–25/mo), and let the website stay on Cloudflare Pages from day one.

Two extra reminders that are easy to miss: 1) Ask Opn to approve our business before we go live to customers — payment providers review merchants first. 2) Our reminder texts (appointment reminders) are separate from login codes and use the LINE messaging app, which is already wired up.

What happens to our current Kubernetes cluster? Keep it for development and experiments — it's free to keep and good for learning. We simply run the live business on the lean setup and point real customers there.