2026 one-person-company tech stack: how to replace Next.js + Supabase + Vercel in China

A while back, Beijing Yizhuang put up a sign — the country's first OPC innovation community. OPC stands for One Person Company. The concept has proven itself overseas: Pieter Levels built Nomad List and Remote OK alone, passing $1M ARR; in Japan, Takuya built SaaS independently with Next.js + Supabase + Claude, a case written into various YC-recommended reads.

China is starting to see people take it seriously too. On V2EX a 41-year-old Java veteran posted about his first overseas indie project, switching his stack from the full Java suite to Next.js. His reason was pragmatic — "one person can't carry that heavy equipment."

But here's the question: if your users are in China, does that overseas standard stack still work?

The answer: it works, but you'll hit walls.

This post skips the sentiment and does the math layer by layer — where Next.js + Supabase + Vercel + Stripe each get stuck in China, whether CloudBase can replace them, and when you shouldn't switch at all.

1. The four real constraints of a one-person-company developer​

Before discussing tech choices, lay out the constraints. Building a product alone, you're not facing "which framework is most advanced" — you're facing "which combination lets me survive".

Time. A new feature must run within a day; two days at most, or you cut the requirement. A one-person company has no one to debug with you and no one to write CI/CD for you.

Cost. You must be able to run on free quota at the start, and push the payment point past the first real paying user. A fixed $99/month baseline is small change overseas, but for a domestic indie developer it's a turnoff.

Compliance. Filing, payments, invoices, real-name verification — one person shoulders all of it. Overseas developers collecting Stripe money through Payoneer back to China is too complex for most; better to go with WeChat Pay from the start.

Ecosystem. Where your users are determines where your traffic starts. The smoothest cold start domestically is the WeChat ecosystem (mini programs, official accounts, video accounts); overseas it's Twitter + Product Hunt + Reddit. The two paths barely intersect.

The overseas standard stack (Next.js + Supabase + Vercel + Stripe) became standard because it precisely matches the four constraints of an "overseas one-person company". But China's constraints differ, so the optimal solution necessarily differs — this isn't a tech problem, it's a geography and policy problem.

2. Three walls of the overseas stack in China​

First, Vercel.

Vercel's edge nodes are overseas; domestic users access through cross-border links, with measured latency fluctuating 300-800ms and packet loss at peak hours. This isn't fixable by "configuration optimization" — physical distance decides it. You can layer Cloudflare on top, but you know Cloudflare's status in China — sometimes it works, sometimes even DNS won't resolve.

Then Supabase.

Supabase has no domestic nodes; database and APIs are all overseas. Even if your front end is deployed domestically, backend calls still cross the border. The Pro plan doesn't change this physical reality. Some try self-hosting Supabase in China (it's open source), but that defeats the point of choosing Supabase — you wanted "no ops", and self-hosting brings the ops back.

Finally Stripe.

This is the hardest wall. Stripe doesn't support domestic individual developer registration. Even registering a Hong Kong company for Stripe HK, getting the money back to mainland China requires passing another layer of remittance compliance. For a one-person project, it's a bottomless pit. The compliant domestic payment paths are only WeChat Pay, Alipay and bank aggregation — WeChat Pay is smoothest for mini programs, Alipay for H5/PC.

Stacked together, the overseas standard stack's domestic experience is roughly: slow front end, slower backend, and can't get paid.

Some say, just hybrid-deploy — front end domestic, backend still Supabase, payments via WeChat. Possible; the hybrid-architecture article on 80aj.com is exactly that idea, but the cost is maintaining two deployments, two domains and two monitoring setups. For a one-person company, complexity instantly doubles.

3. Benchmarking CloudBase layer by layer​

Can CloudBase compete? Layer by layer.

Front-end deployment: real support for Next.js on CloudBase​

Many people misunderstand here — they think CloudBase can only deploy static sites and can't run Next.js SSR/ISR.

The official docs are right there (docs.cloudbase.net/cloud-function/frameworks-examples/next); Next.js is a first-class citizen on CloudBase:

The implementation path hosts next start in an HTTP cloud function, launching a Node service on port 9000 via scf_bootstrap. You change two things:

// next.config.js
const nextConfig = {
  output: 'standalone',
  images: { unoptimized: true },
};

Add a scf_bootstrap startup script:

#!/bin/sh
export PORT=9000
export NODE_ENV=production
npm start

Deploy once and it runs.

Honest downsides:

• next/image optimization must be disabled; no out-of-the-box Image Optimization like Vercel
• Cloud functions have cold starts — 1-3 seconds on first access, not as fast as Vercel's edge nodes
• Windows users hit the line-ending problem (^M) with scf_bootstrap; use nano or vim
• The "git push to deploy" mindset needs CLI V3 to match; not as foolproof as Vercel

So the conclusion: technically fully feasible, but Developer Experience (DX) is half a notch below Vercel.

Database: cloud database vs Supabase PostgreSQL​

Supabase's database is PostgreSQL with RLS (row-level security), realtime subscriptions, auto-generated REST and GraphQL APIs — still the most comfortable combo in the industry.

CloudBase's cloud database is MongoDB-style document-based, plus an optional relational database (MySQL). Big differences:

• Data model: Supabase naturally fits relational thinking; CloudBase's document model fits mini program "one document per business object" structures better
• Permission model: Supabase's RLS is SQL syntax, rigorous; CloudBase's permission rules are JSON with a short learning curve
• Realtime: Supabase's Realtime is based on PostgreSQL logical replication; CloudBase has a realtime database with equivalent functionality but a different API
• Client SDK: Supabase's TypeScript type inference is a killer feature; CloudBase has type support but not as strong

If your data model is strongly relational (e-commerce, SaaS, finance), Supabase is still more comfortable; if weakly relational or document-based (content platforms, IoT, utility mini programs), CloudBase suffices.

Auth: CloudBase auth vs Supabase Auth​

Supabase Auth supports 40+ OAuth providers out of the box — Google, GitHub, Apple, Twitter, Facebook all one-click.

CloudBase auth's strength is in the domestic ecosystem — WeChat, QQ, phone number and email are native, one line of code each; overseas OAuth (Google, GitHub, etc.) needs you to integrate via the standard OAuth 2.0 flow, not out of the box.

Conclusion: where your users are decides which is better. Domestic products choose CloudBase, overseas products choose Supabase — no controversy.

API / backend: HTTP cloud functions vs Vercel Serverless​

Both are serverless functions, with similar cold-start and billing. A few real differences:

• Deployment unit: Vercel auto-packages app/api/* into functions; CloudBase needs explicit declaration or whole Next.js deployment
• Local dev: Vercel's vercel dev matches production closely; CloudBase's local debugging needs the CLI
• Edge compute: Vercel has Edge Runtime executing at the global edge; CloudBase cloud functions are mainly in domestic regions

Payments: WeChat Pay integration vs Stripe​

No choice here — if your users are domestic, it's WeChat/Alipay.

CloudBase's WeChat Pay integration is official; a few cloud function lines wire up ordering, callbacks and refunds. Stripe's elegant Checkout Session API has no domestic equivalent, but you can't use it anyway.

4. CloudBase's limits, stated honestly​

Acknowledge a few things.

The community isn't as mature as Supabase. Supabase has 70k+ GitHub stars, and its Stack Overflow question volume is over ten times CloudBase's. When you hit a problem and Google it, someone has probably been there with Supabase; with CloudBase, many questions still go to the official community or tickets.

Documentation density isn't high enough. CloudBase's docs cover basic APIs comprehensively, but "complete project examples" and "pitfall summaries" are noticeably fewer. A beginner following Supabase's official tutorial can clear it end to end; following CloudBase's docs you'll fill in a lot of context yourself.

Overseas scenarios reverse. CloudBase has no overseas nodes; if 30% of your users are overseas, CloudBase becomes a disadvantage. Then Supabase + Vercel is the optimal solution.

The DX gap is real. Vercel's "connect your repo, we handle the rest" is the gold standard; CloudBase can't match that smoothness yet. You accept some manual config — scf_bootstrap, port 9000, standalone output — things Vercel users never need to know.

Listing these isn't to scare you off, but to keep you informed — if you can accept these points, reading further won't lead you into pits.

5. Scenario-based recommendations​

Different scenarios, different answers.

More concretely —

In pure domestic scenarios, if you're building a mini program + H5 dual-end product, CloudBase runs it all:

• Front end (native mini program + Next.js H5) both hosted on CloudBase
• Database via cloud database
• Login via one-tap WeChat auth
• Payments via WeChat Pay
• AI via CloudBase AI Toolkit (if needed)

The whole stack is one bill, one console, one MCP entry. Friendly to a one-person company's cognitive load — that matters more than anything.

In overseas scenarios, don't force CloudBase. Supabase + Vercel + Stripe remains optimal, and Stripe, Google OAuth, Google Pay only work smoothly in that ecosystem.

Hybrid is the most complex. My advice — first judge where 80% of your users are, pick the stack for the main scenario, and degrade the other side. If it's genuinely 50:50, accept the complexity of dual-track deployment; don't expect one stack to handle everything.

6. A 2026 variable — AI in tech selection​

A trend is rising: in 2026 tech selection, "AI understandability" carries growing weight.

Meaning: does AI write this stack's code correctly? Can MCP operate the platform directly? Does conversational deployment work?

Next.js wins on this dimension — it's one of the most common frameworks in LLM training data, and AI writes Next.js code far more accurately than obscure frameworks.

CloudBase has a chance to overtake — CloudBase MCP is live, and with the CodeBuddy extension you can do "conversational deployment" (the previous post "WeChat DevTools + AI + CloudBase deployment" covered this chain). Supabase has MCP, but Vercel's MCP integration is still on the way.

Don't over-mythologize though. AI assistance is a bonus, not a comeback factor. The core constraints remain those four — time, cost, compliance, ecosystem.

7. Final words​

A one-person company isn't "shrinking the big-company model" — it's another optimal solution under another set of constraints.

Overseas one-person companies use Next.js + Supabase + Vercel + Stripe because that matches their constraints. Domestic one-person companies shouldn't copy it as-is — not because domestic tools are inferior, but because the constraints differ.

CloudBase isn't a perfect replacement, but in the domestic scenario it converges the three hardest things — latency, compliance, payments — at once. The cost: you accept a less lively community than Supabase, less hand-holding docs than Vercel, and DX a notch below git push.

Worth switching? Do your own math —

• If your users need to pay tomorrow and you don't want to spend two weeks wiring Stripe overseas, CloudBase can save you
• If your users are in Europe/America and you write code in China to serve them, don't touch CloudBase; use Vercel
• If you need both, accept the complexity and build a hybrid architecture

This post doesn't decide for you — it lays out each layer's pits and boundaries. The rest is your call.

References

• CloudBase Next.js deployment docs: https://docs.cloudbase.net/cloud-function/frameworks-examples/next
• V2EX: 41-year-old Java veteran going indie overseas: https://www.v2ex.com/t/1185231
• Hybrid architecture balancing compliance and performance: https://www.80aj.com/2026/03/24/hybrid-architecture-vercel-supabase/
• 01MVP tech stack selection guide: https://www.01mvp.com/docs/guide/develop/tech-stack
• Indie developer guide (MaximeSHE): https://www.cnblogs.com/scy157609962/p/19044126