About this article
As the second installment of the “Case Studies” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains the personal / startup case.
For 1-5 person, monthly tens-of-thousands-of-yen budget, product-unverified launch phase, the correct answer is “shippable design” over “correct design.” Touching heavy tech selection (own DC / microservices / complex CI/CD) melts verification time and exhausts funds. This article handles platform delegation like Vercel / Supabase / Auth0 / Stripe, compositions easiest for AI to write, and stack selection runnable by 1 person.
What is startup architecture in the first place
Imagine opening a food stall. Building a proper storefront right away, installing a commercial kitchen, and setting up a POS register - you’ll run out of money and time before you can verify whether customers will actually come. The correct move is to start with the stall, then move into a proper shop once the lines form.
Startup architecture works the same way - the minimum composition that can ship to market within 1 month is the best design. Delegate thoroughly to platforms (Vercel, Supabase, Auth0, etc.) and minimize what you build yourself.
If a startup adopts enterprise-grade design from day one, funds and time run out before validation, and the product never sees the light of day.
Why startup-specific design is needed
The risk of funds running out before market validation
The biggest risk for a startup isn’t technical failure - it’s running out of funds and time before verifying whether the product is accepted by the market. While you spend 3 months on robust design, a competitor may capture the market first. That’s why a “composition shippable in 1 month” is the best design.
The constraint of 1-5 people doing everything
Unlike large enterprises that can have specialized teams (infrastructure, security, DBA, etc.), startups must choose technology on the premise that one person handles all of development, deployment, monitoring, and incident response. Choosing operationally heavy technology (Kubernetes, self-built auth, etc.) eats up development time.
AI-era standard stacks deliver a productivity leap
As of 2026, choosing a stack like TypeScript + Next.js + Supabase - the stack AI writes most fluently - effectively multiplies development speed several times over. Choose custom tech or niche languages and you lose this benefit.
Selection basic policy
Decisions at this stage move on different principles from general corporate systems. Align all selection to compositions AI is best at, minimizing what’s written by hand. Trust platforms, don’t fear vendor lock-in, choose stacks runnable by 1 person.
| Prioritize | Postpone |
|---|---|
| Time-to-market, AI generation accuracy | Scalability, 99.99% availability |
| Existing platforms’ free tier | Vendor-lock-in avoidance |
| Operate everything by 1 person | Specialty-team division design |
| Type / schema explicit (for AI assistance) | Custom frameworks, custom conventions |
Representative profiles are personal blogs, SaaS MVP, operational-efficiency tools, portfolios, side-business services. Avoiding over-design is the biggest design decision. Unverified products don’t need full-fledged operations design.
Recommended stack (overall picture)
Choose options with fewest steps and AI most fluent per area. Below is the de facto standard for personal-to-few-person scale.
flowchart TB
USER([User])
HOST[Vercel / Netlify / CF Pages<br/>Git push to production]
APP[Next.js + TypeScript]
AUTH[Clerk / Auth.js / Supabase Auth<br/>self-implementation forbidden]
DB[(Supabase / Neon<br/>PostgreSQL)]
PAY[Stripe<br/>billing]
MON[Sentry<br/>+ Vercel Analytics]
USER --> HOST --> APP
APP --> AUTH
APP --> DB
APP --> PAY
APP -.|errors/PV| MON
classDef user fill:#fef3c7,stroke:#d97706;
classDef host fill:#dbeafe,stroke:#2563eb;
classDef app fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef ext fill:#fae8ff,stroke:#a21caf;
class USER user;
class HOST host;
class APP app;
class AUTH,DB,PAY,MON ext;| Area | Recommended | Reason |
|---|---|---|
| App form | Web app (SaaS-style) | No installation, instant delivery |
| Hosting | Vercel / Netlify / Cloudflare Pages | Git push to production |
| Language | TypeScript | Front-back unified, highest AI accuracy |
| FW | Next.js (apps) / Astro (sites) | Info volume, abundant AI training data |
| DB | PostgreSQL (Supabase / Neon) | RDB standard, schema-enforcing |
| Auth | Clerk / Auth.js / Supabase Auth | Self-implementation forbidden |
| Monitoring | Vercel Analytics + Sentry | Free tier enough |
When choosing else, you need to articulate why off-standard. Tech selection without basis is the source of regret.
System / deploy choices
Public cloud PaaS services (Vercel, Netlify, Cloudflare Pages) are the only choice. Self-built AWS, on-prem, Docker on K8s - all excessive at this phase. Vercel’s free tier covers up to about tens of thousands of PV for personal dev, and paid plans are around $20 monthly.
By riding the worldview of Git push = production deploy, deploy work, SSL management, CDN config, and preview env all auto-mate. Written on the premise of just pushing AI-generated code to run, also best chemistry with AI-driven dev.
| Choose | Avoid |
|---|---|
| Vercel / Netlify / Cloudflare Pages | Self-built VPS, manual AWS EC2 |
| Serverless functions (Edge Functions) | Self-built Express servers, persistent operation |
| Managed DB (Supabase, Neon, PlanetScale) | Self-built PostgreSQL on VPS |
If even 1 second is spent “thinking about infrastructure,” it’s the stage to redirect to product development.
Software / data choices
Backend completes within Next.js API Routes / Server Actions - don’t stand up dedicated backend servers. Choose PostgreSQL (Supabase / Neon) for DB, making schemas explicit with type definitions (Prisma / Drizzle). Avoid NoSQL safely - Firebase Firestore looks convenient but has no schema constraints, suffering in later analysis / AI utilization.
Strict typing from the start spikes AI’s accuracy in code generation. Thoroughgoing tRPC or TypeScript + Zod for type sharing between front and back lets even personal dev enjoy large-project-class type safety.
| Choose | Avoid |
|---|---|
| PostgreSQL + Prisma / Drizzle | MongoDB, Firestore (schemaless) |
| Next.js API Routes / Server Actions | Separate Express / Fastify servers |
| Type sharing via tRPC / Zod | Hand-written REST API type definitions |
Forcing schemas via types is the most effective single move for bug reduction in 1-person dev.
Frontend / auth choices
For UI, the Tailwind CSS + shadcn/ui combination is overwhelmingly strong - the stack generation tools like v0 and Bolt write with highest accuracy. There’s no margin to build custom design systems at this phase - using shadcn/ui as copy-paste basis and customizing only needed parts is fastest.
The iron rule for auth is absolutely not self-implementing - delegate to one of Clerk / Auth.js / Supabase Auth. They proxy all complex implementations of Passkey, OAuth, MFA, session management, starting at $0-25 monthly. Writing Cookie auth yourself is a “trap melting time.”
| Choose | Avoid |
|---|---|
| Tailwind + shadcn/ui | Custom CSS design, in-house UI library |
| Clerk / Auth.js / Supabase Auth | Self-built Cookie / JWT auth |
| Server Components (Next.js App Router) | Old Pages Router, hand-written SSR |
Writing auth yourself is the antipattern most to avoid in personal dev.
Monitoring / operations choices
At this phase, full-fledged monitoring foundations (Datadog, New Relic, etc.) are unneeded - excessive. The combination of Vercel Analytics (Web Vitals) + Sentry (error tracking) + Logflare / Axiom (log search) is enough, totaling around $20-50 monthly.
Full-fledged SRE operations like SLO / error budget / on-call regime can be considered after users grow - at MVP stage, “see error notifications once a day” is fine. What matters is operational discipline of not ignoring notifications when they come, not tool quantity.
| Choose | Avoid |
|---|---|
| Sentry (errors) + free log tools | Heavy monitoring like Datadog, New Relic |
| Slack / Discord notifications only | PagerDuty + on-call rotation |
| Operations of looking once weekly yourself | Fancy 10-dashboard operations |
Excessive monitoring takes time away from products.
Near-zero-cost composition example
A composition realizing JPY 0/month at idle, billed only when used in personal dev. Not constantly running servers, with functions launching only when user requests come - so no billing during unused hours. Beyond domain costs, basically startable on free tier; using services like Stripe that are JPY 0 until revenue arises for payments.
The background is each company entering the personal-developer-acquisition competition, with free tiers expanding year by year.
| Area | Service | Free tier guideline |
|---|---|---|
| Hosting | Vercel / Cloudflare Pages | Around 100GB transfer monthly |
| Edge functions | Vercel Edge / Cloudflare Workers | Around 100k requests daily |
| DB | Supabase / Neon | Around 500MB |
| Auth | Clerk / Supabase Auth | Around 5,000 MAU monthly |
| Files | Cloudflare R2 / Supabase Storage | Around 1GB |
On the premise that by the time billing starts beyond free tier, monetization prospects have stood up, composition generating tens of thousands of yen monthly infrastructure cost at 0-user stage is completely wrong selection at this phase. Choose composition of “pay after users come.”
Personal / startup numerical gates
Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.
The practical core is judging numerically where to switch to full-fledged operations.
| Metric | Startup phase | Graduation guideline |
|---|---|---|
| Monthly active users (MAU) | ~1,000 | Strengthen monitoring beyond 1,000 |
| Monthly infrastructure cost | ~JPY 5,000 (free tier) | Review beyond JPY 50,000 |
| Engineer count | 1-3 | Modularize beyond 5 |
| Paid customers | 0-100 | SLA-conscious beyond 100 |
| Release frequency | Weekly to daily | Deploy automation required |
| Allowed downtime | Monthly hours OK | Time to aim for 99.9% |
| Auth users | Within Clerk / Auth0 free tier | Switch to paid plan |
Free-tier exceeding or beyond JPY 50k monthly is the “graduation sign from startup phase.” Switch to small-mid SaaS design beyond this. Aiming for 99.99% availability at this phase is over-investment. 43 minutes monthly downtime troubles no one.
Personal / startup pitfalls and forbidden moves
Typical accident patterns at personal / startup phase. All result in playing with design and losing user-acquisition time.
| Forbidden move | Why it’s bad |
|---|---|
| Microservices-ize in 1-person dev | Just increases distributed-transaction / ops load, same as Segment 2017’s reflection |
| Adopt K8s from the start | Excessive at 1-10 server scale, ECS Fargate / Cloud Run is enough |
| Self-build auth (Cookie, JWT, MFA, password reset) | Weeks to months melt, delegate to Auth0 / Clerk |
| Build AWS from scratch with VPC / subnets / IAM / RDS | Vercel + Supabase enough, redirect learning time to product |
| Excessive monitoring foundation (Datadog $3k monthly) | No metrics to see at 0 users, Sentry + Vercel Analytics enough |
| Choose schemaless DB (Firestore / MongoDB) | Stuck on data organization / AI utilization 1 year later, move to PostgreSQL + Prisma |
| Build custom FW / in-house UI library | AI generation accuracy drops, copy-paste shadcn/ui faster |
| Future 1000-user-scale preemptive design | Product top page blank for 3 months, ends with 0 users |
| Inject PoC as is into production | Quality not production-ready, rewrite required |
| Take AWS-certification-level composition | Verification time melts, funds exhausted |
The contrast of Quibi’s 2020 business stop (raised $1.75B, custom video tech, service ended in 6 months) and Instagram’s 2010 launch (2 people, standard stack, sold for $1B in 18 months) plainly shows design luxury after hypotheses hit.
Taking dream compositions in 1-person dev ends playing with design. The correct answer is a 1-file releasable this week.
| “Must microservices-ize” — splitting as 1 person | Only increases distributed-transaction / ops load; monolith is enough | | “Must build AWS from scratch” — over-investing | VPC / IAM / RDS learning time steals from product development; PaaS is enough |
AI decision axes
| AI-favorable | AI-unfavorable |
|---|---|
| Next.js + TS + Tailwind + shadcn/ui | Custom FW, custom UI library |
| Prisma / Drizzle + schema definition | Schemaless NoSQL |
| Clerk / Auth.js (standard protocols) | Self-built auth |
| UI generation with v0 / Bolt | Hand-written CSS from scratch |
- Time-to-market — prioritize composition shippable in 1 month
- AI generation accuracy — lean to standard stack to maximize productivity
- Operations lightness — keep within range runnable by 1 person
- Cost — establish at free-$50 monthly
Author’s note - cases of “simple” producing $1B
Instagram launched in 2010 with 2 people, Kevin Systrom and Mike Krieger. The stack at the time was the extremely standard composition of Django + PostgreSQL + Redis - no custom frameworks or microservices. 25k users on launch day, reaching 1M users in 3 months, sold to Facebook for $1B 18 months later. Employees remained 13 even at acquisition - “ship fast with standard stack” produced $1B-class outcomes - told as a symbolic case.
In contrast, media company Quibi raised $1.75B in 2020, custom-developed mobile-only vertical-horizontal-switching video tech, casting many big actors with great fanfare to launch. But business stopped 6 months after service start. Excessive tech investment and lack of market verification analyzed as causes - the typical failure of “implemented full-scale before hypothesis verification.” Design luxury isn’t too late after hypotheses hit - this contrast plainly shows MVP-phase selection criteria.
What to decide - what is your project’s answer?
For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”
For projects of this scale, the ideal is deciding within 1-2 days and entering implementation. Few decisions worth long thought - if there’s no reason to deviate from standard, no need to hesitate.
- App form (Web / hybrid)
- Hosting (Vercel / Netlify / Cloudflare Pages)
- Language / FW (TypeScript + Next.js / Astro)
- DB (Supabase / Neon)
- Auth (Clerk / Auth.js / Supabase Auth)
- Payments (Stripe)
- Domain / SSL (leave to platform)
Summary
This article covered the personal / startup case, including the Vercel + Supabase + Clerk standard stack, free-tier full utilization, graduation line, and equation with AI generation accuracy.
Ship fast with standard stack, have AI write, establish on free tier, switch at graduation line. That is the practical answer for personal / startup design in 2026.
Next time we’ll cover the “small-mid SaaS” case. Plan to dig into the standard composition tolerating production operations with 5-30 person teams, and the combination of managed + IaC + SLO.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (81/89)