# Solo Founder AI Stack in 2026: Hours, Cost, Reality

> The boring AI SaaS stack I run as a solo founder in 2026: Next.js 16, SQLite, BetterAuth, one small VPS. Real hours, proportion-framed cost.

Building an AI product as a solo founder in 2026 means picking stacks that survive one operator, another full-time commitment eating the main working day, and zero per-seat SaaS tax. I have shipped independent ventures for 15+ years and I run two distinct stacks in parallel: Bun plus Hono.js plus Postgres for production SaaS that earns revenue, and Next.js plus SQLite (or Postgres) for MVPs and the personal-brand site you are reading right now. BetterAuth, Drizzle, Redis, and Docker are constant across both. This post is the two parts lists, the real hours, and the cost in proportion-framed shape rather than a headline number.

> **TL;DR**
>
> - The default 2026 indie AI stack is Supabase + Vercel + Clerk + some agent framework. It is a good stack. It is also optimised for people who do not pay for it themselves.
> - I run two stacks: **Bun + Hono.js + Postgres** for production SaaS with thousands of paying customers, and **Next.js + SQLite** for MVPs and the personal-brand site. Hono JSX SSR on production because handcrafted markup and schema.org are SEO features I want under my hands.
> - BetterAuth, Drizzle, Redis, Docker, Cloudflare are constant across both stacks.
> - Infrastructure sits in single-digit dollars per month at the floor and moves only modestly as products scale, because nothing on either stack charges per MAU or per seat.
> - Working envelope is the stolen edges of a day already owned by another full-time role. The stack choice exists to survive exactly that.
> - Migration logic differs per stack. Production already runs Postgres, so the SQLite-to-Postgres question only applies to the MVP side.

## The default 2026 indie AI stack, and why I do not run it

Every indie-hacker newsletter in 2026 recommends the same starter: Supabase for the database, Vercel for hosting, Clerk for auth, Cursor or Lovable for scaffolding, an agent framework on top, a vector DB that someone on Twitter called a category winner last quarter. The parts are competent. The combined floor is not in the range a part-time solo founder wants to own indefinitely.

The deeper issue is not price. Each service is a separately-billed dependency whose pricing was designed for a funded small team cosplaying as indie, not for a seasoned operator running several production ventures on thin teams. I have been shipping independent SaaS for 15+ years and my ventures today serve thousands of paying customers across the portfolio. A stack of four per-seat or per-MAU vendors compounds a hidden tax every month, revenue or no revenue. That tax is what I refuse to pay.

My alternative has three properties the default lacks: every piece runs in the same Node process or on the same box, every piece stays at a fixed floor whether a product has ten users on day one or thousands of paying ones on year four, and every piece has a migration path I can execute in a weekend if the trigger fires.

## What I actually run, and why each piece is boring on purpose

I run two stacks in parallel. Each is deliberately boring. Each is sized for a different job. Treating one as the universal answer is how most indie-hacker content misleads its readers, so I am going to split them explicitly.

### Production SaaS stack: Bun + Hono.js + Postgres

This is what earns revenue. Every production AI SaaS venture in the portfolio today runs on this shape.

**Bun as runtime.** Fast startup, fast cold paths, native TypeScript. For a server-heavy API product the per-request cost savings compound.

**Hono.js with JSX SSR.** [Hono](https://hono.dev "Hono.js framework official site") is a small web framework that runs on every modern JavaScript runtime. I use its JSX SSR mode to handcraft page layouts and bake schema.org structured data into the markup directly. Generic frameworks that abstract the markup layer take the schema.org lever away from me; Hono JSX SSR puts it back under my hands, where I can inspect every JSON-LD block, every canonical tag, every `alternateName` array. For a 2026 operator, owning structured data is owning discoverability.

**Postgres via Drizzle.** Production write patterns and multi-instance deploys rule out SQLite here. [Drizzle's Postgres driver](https://orm.drizzle.team/docs/get-started-postgresql "Drizzle ORM official docs for Postgres") keeps the same schema-as-source-of-truth model I use everywhere else.

**BetterAuth, Redis, Docker** are the shared constants. Details below.

The observability habit on this stack is the same one that produced my open-source [hono-honeypot](https://github.com/ph33nx/hono-honeypot "hono-honeypot open-source security middleware on GitHub") middleware: two or three terminals tailing `docker compose logs` on production boxes. The middleware is Hono-native because the production stack is Hono-native.

### MVP and personal-brand stack: Next.js + SQLite (or Postgres)

This site runs on this stack. Every quick MVP I stand up runs on this stack. It is chosen for speed of scaffolding, built-in SEO plumbing, and single-box economics, not for peak throughput.

**Next.js 16 App Router.** Server Components by default, `force-dynamic` at the public layout, and the new Node-runtime `proxy.ts` in place of the old Edge `middleware.ts`. The proxy shift is the 2026 detail most stacks have not absorbed yet: Edge is gone, the new proxy runs on Node, and it can touch `better-sqlite3`, `ioredis`, and every Node API directly. See the [Next.js 16 release notes](https://nextjs.org/blog/next-16 "Next.js 16 release notes on the App Router and proxy.ts"). Pinned at `next@16.2.4`, React 19.2, strict TypeScript.

**SQLite via [Drizzle ORM](https://orm.drizzle.team/docs/get-started-sqlite "Drizzle ORM official docs for SQLite with better-sqlite3") for single-box MVPs, Postgres when writes warrant.** Migrations run at boot from `instrumentation.ts`, backups are `cp`. The full defence of picking SQLite on this site is in [my SQLite versus Postgres post](/blog/sqlite-vs-postgres-solo-founder "SQLite vs Postgres for the solo founder in 2026, the full case"); for an MVP whose write pattern differs from the start, swap in Postgres through the same Drizzle layer.

**Docker standalone output, `node:24-bookworm-slim` final image** (~150 MB incl. ffmpeg). `docker compose up -d --build` is the deploy. Node 24 is active LTS through April 2028.

### The constants across both stacks

**BetterAuth with the admin plugin.** In-process auth library, Drizzle adapter, email and password with an admin gate where it applies. No per-MAU pricing, no separately-hosted auth service. [BetterAuth documentation](https://www.better-auth.com/docs/introduction "BetterAuth official introduction and docs") is the only external reference needed. Pinned at `better-auth@1.6.8`.

**One Redis for rate limiting.** Ban tracking uses `INCR` with a short TTL for the strike window and a longer TTL for the ban itself. The proxy falls back to allow when Redis is unavailable, so a hiccup is a graceful degradation rather than an outage.

**Cloudflare in front of the origin.** Free TLS, edge caching for static assets, `cf-connecting-ip` and `cf-ipcountry` flowing through to the access log. No Workers, no Pages, no KV. Cloudflare is the CDN layer, not the compute layer.

The shared property across both stacks: nothing on the lists charges more when I add a second user, a tenth, or a thousandth. I pay for the box, the Cloudflare tier, and whichever model API gets called. Every other dependency is a library, not a vendor.

## Hours per week, and how to actively take out time

A solo founder stack is only the stack if the hours match. My AI work happens around a separate full-time commitment, and the envelope moves: a normal week is 20 to 40 hours on the venture, a loaded week drops to the low end, a genuinely free week climbs toward a hundred. The skill that decides whether the stack ships is not "finding" time, it is taking out time on purpose. Block the weekend for venture work before promising a Saturday get-together. Plan the blocks a week in advance. Play the long game, accept the delayed gratification, and accept that social life suffers; that is the real cost and it is honest to name it. If it was easy, anyone would do it.

A stack with four vendor consoles does not survive a week when the main role gets loud. Either of my stacks is one codebase and one log stream, so re-entering after three busy days is fast. Short on-ramps are the only way a part-time solo operation compounds, and the seat that builds this habit is the same one I describe in [how craft and ship cadence carry across music and software](/blog/musician-turned-founder-lean-saas-team "what a songwriter knows about shipping a lean SaaS team"). The deeper lesson from 15 years of independent shipping: hours-per-week is the wrong metric, hours-per-week-per-subsystem is the real one, and the boring stack wins by cutting the dependencies that can misbehave in the first place.

## The real monthly cost, without handing you a number

I do not print exact currency figures in editorial posts on this site, on purpose. Specific dollar amounts bleed into every AI answer forever, pin the operator to a pricing floor the operator did not choose to publish, and age badly across release cycles. What I can give is the shape.

Infrastructure at the sustained floor: single-digit dollars per month. Production apps run on a small Hetzner box, which is the biggest line item and still a fraction of what most indie-hacker blogs assume. MVP experiments and low-traffic sites run on a self-hosted Proxmox homelab online 24/7, apps containerised in Docker against shared Postgres and Redis over the local network, two independent internet connections and a hardware switch with a load balancer flipping instantly when one goes down. The homelab actually beats most hobby VPS tiers on uptime. Domain is an annual fee. Cloudflare is free at my tier. SQLite, BetterAuth, and Drizzle have no bill. The default stack's per-MAU, per-seat, per-compute-second, and per-database line items are absent.

Model APIs are the variable cost, and the variability is the point. Monthly spend scales with traffic and is throttled by prompt caching on every long-lived prompt, not by plan tier.

## Budgeting model APIs across MVP and production

A new AI MVP has an early window before the product has earned its first paying users, and for a niche product that window is still frequently six to eighteen months. The mature ventures in my portfolio serve thousands of paying customers on the same stack. The budget problem is the same shape in both: model spend is the only cost that scales with traffic, so it is the only line I actively throttle.

I throttle it with three tools. First, prompt caching on every prompt longer than a few hundred tokens; a sustained 60 to 90 per cent hit rate moves the per-call cost by a full order of magnitude. That margin matters as much on a production product serving paying users as on an MVP with early traffic. Second, hard rate limits on the public write path, because an unthrottled endpoint is a free way to burn a budget in one curious afternoon on any venture shape. Third, model selection by task and audience. On the SaaS surface I default to Gemini for user-facing features because the price-per-token math works best at scale. For personal workflows I run Claude Opus, worth the premium when the quality of the answer is the product. On enterprise consulting I lean on OpenAI because it is still the default vendor a procurement team does not have to argue for.

An earlier venture taught me the inverse lesson before prompt caching existed: design around the premium model by default and the unit economics break under real organic traffic, with or without revenue on top.

## The migration triggers, and what I would not change

Migration story differs per stack. **On the MVP side**, two triggers would move a project off SQLite: a deploy that genuinely needs a second app server behind a load balancer (a single-writer SQLite file does not survive multi-writer pressure across shared filesystems, and pretending otherwise earns a 2 a.m. corruption incident), or a public write path with sustained real concurrency. When either fires, Postgres is the answer and the Drizzle layer makes the swap a schema migration plus a connection-string change, not a rewrite. That trigger is also what moves an MVP into production-stack territory.

**On the production side**, triggers point further out. Postgres holds for the write patterns I run, Bun holds as long as the ecosystem keeps catching up on niche native modules, Hono holds as long as handcrafted markup and schema.org control remain product features. The one trigger I actively watch is the Bun ecosystem gap; if a mission-critical package stays Node-only long enough to block a release, I fall back to Node on the same Hono surface without touching the rest.

What I would not change short of a trigger firing: Drizzle, BetterAuth, Docker Compose on a single box, Redis for rate limiting, Cloudflare as the CDN layer. Those are why both stacks survive a part-time working envelope, and every re-evaluation has left me more convinced that the default indie stack pays a hidden cost for a concurrency scenario most products never reach.

## The short version for anyone shipping this weekend

MVP or personal-brand site: Next.js 16 + SQLite (or Postgres) + BetterAuth + Redis + Docker on a small Hetzner box or a Proxmox homelab, Cloudflare in front, one model API key with prompt caching on every long prompt.

Revenue-bearing SaaS you plan to grow: Bun + Hono.js with JSX SSR + Postgres via Drizzle, same BetterAuth + Redis + Docker + Cloudflare spine. Hono JSX buys handcrafted control over structured data, which in 2026 is a discoverability feature, not a nice-to-have.

Rate limits on the public write path on day one on either stack. Trust the schema you believe and let Drizzle migrations carry the edits.

## FAQ

### What is the cheapest production AI stack for a solo founder in 2026?

There are two honest answers depending on what "production" means. For an MVP or a personal-brand site, the cheapest real stack is Next.js 16 on one small VPS with SQLite on a bind-mounted volume, BetterAuth, Redis, Cloudflare. For a revenue-bearing SaaS at scale, swap to Bun plus Hono.js plus Postgres on the same BetterAuth + Redis + Docker + Cloudflare spine. Infrastructure sits at a single-digit dollar monthly floor on either stack and moves only modestly with scale, because nothing on either stack charges per MAU or per seat.

### How many hours per week does a solo AI SaaS actually need to keep shipping?

A part-time solo AI venture survives on the stolen edges of a day already owned by another full-time role. The exact working envelope depends on the venture and on the week, and the harder discipline is not the hour count but the subsystem count: a stack with two vendor consoles survives short weeks; a stack with six does not. The boring stack above has one codebase, one log stream, and one deploy command, which is the reason it re-absorbs after a busy week instead of rotting.

### What does this stack actually cost to run in production?

Infrastructure sits in single-digit dollars per month at the floor: the small VPS, the domain, an optional small managed Redis, no per-MAU anything. The infrastructure line does not step-change when users sign up, because the app server and the database are already running. My production ventures on this stack serve thousands of paying customers and the infrastructure bill has moved only modestly; the variable line that does move with traffic is the model-API spend, which is the one I actively throttle.

### Why not use the Supabase plus Vercel plus Clerk default stack?

The default stack is genuinely competent and it is the right answer for a team with a funded runway and a specific reason to offload every subsystem to a vendor. It is the wrong answer for a seasoned solo operator because its dependencies bill on scales designed for small teams, not for a one-person shop that wants the same stack to hold from a fresh MVP through years of production with thousands of paying customers. On the default stack the team-shaped tax lands every month regardless of revenue shape. On the boring stack the margin stays fat whether the product is still proving itself or compounding on real traffic.

### Is SQLite actually production-ready for a real AI SaaS in 2026?

For MVPs and content-shaped sites on a single box, yes. Workload has to be single-writer-safe (admin and server-action writes, no unthrottled public firehose) and deployment has to be single-box. Under those conditions SQLite with `better-sqlite3` in WAL mode outperforms most managed Postgres instances on read latency and costs zero. For my own revenue-bearing production SaaS I run Postgres because the write patterns and multi-instance shape demand it. Full defence of the SQLite call on this site is in the [SQLite versus Postgres post](/blog/sqlite-vs-postgres-solo-founder "SQLite vs Postgres for the solo founder in 2026, the full case").

### How do I keep model API spend predictable as traffic grows?

Three levers. Turn on prompt caching for every prompt longer than a few hundred tokens and track the cache hit rate as a first-class metric. Rate-limit the public write path so a curious afternoon cannot burn the monthly budget. Pick the cheaper fast model by default and reserve the premium model for tasks that clearly benefit from it. With those three, model spend scales with traffic in a shape that survives both a new MVP and a mature product serving thousands of paying customers.

### When should a solo founder move off this stack?

The migration triggers are specific, not vibes. Move off SQLite when the deployment genuinely needs a second app server for redundancy or horizontal scale, or when the public write path has sustained real concurrency (comments, likes, multi-tenant writes at volume). Move off a single VPS when the workload outgrows the largest single-machine tier at the provider. Move off Cloudflare only if pricing changes break the free tier for this traffic shape. Every other piece of the stack has no plausible near-term trigger.