Skip to content

6 questions

Pick the stack for your next project, honestly.

Answer six questions about what you are building and get a stack you can defend. Every data and auth pick states what it costs to leave, and when a competitor is the better answer for what you described, the card names the competitor.

Pick my stackHow it stays honest

How it stays honest

This tool is built by a company that sells one of the products it can recommend. These are the rules that keep that from deciding the answer.

  • 01

    Claims come out of an evidence table

    Every capability behind a pick is a row in a checked matrix: 7 providers by 24 capabilities. Every one of the 168 rows carries the doc, changelog entry, or repo path it came from.

  • 02

    Only shipped features count

    7 rows are in beta or on a roadmap. A recommendation may mention them as a note; none of them can be the reason for a pick, because the picker only reads capabilities that are both live and sourced.

  • 03

    Exit cost on every data and auth pick

    13 products are scored the same way: whether your data comes out through a standard dump, whether your application code has to change, and exactly what you forfeit. Our own products are scored by that rule too.

  • 04

    Some answers get nothing from us

    A content site and a CLI come back with no Layerbase product on the card at all. And when two of your answers genuinely conflict, the card prints the trade-off instead of quietly taking a side.

What you get back

One real card, rendered from the picker at build time. These answers pull against each other on purpose, so the card has to say so.

Your answers

  • web app
  • small team
  • some agent use
  • relational
  • realtime
  • serverless
  • lock-in averse

  • Framework

    Next.js

    Server components, routing, and data fetching are one decision instead of four, and every host knows how to run it.

    Also considered: SvelteKit

  • Data access

    Drizzle ORM

    SQL-shaped TypeScript with generated migrations, so the query you write is the query that runs.

    Also considered: Prisma, Kysely

  • Database

    Neon

    Standard Postgres with a plain connection string, so the data and the code both stay movable.

    Also considered: Layerbase Cloud

    Exit cost — Neon: pg_dump and restore anywhere; your app code is unchanged. You forfeit branching and autoscaling — conveniences, not code you own.

    Tension

    These two answers pull against each other. Convex and Supabase Realtime are the capability answers, but both cost a code rewrite to leave (Convex most of all, since data access is the platform). Staying on portable infrastructure means owning the realtime layer yourself, with LISTEN/NOTIFY, a WebSocket service, or a sync engine on top of Postgres, which is code you maintain.

  • Auth

    Better Auth

    Sessions, users, and tables live in your own database, so auth is code you own rather than a vendor you rent.

    Also considered: Clerk, Auth.js

    Exit cost — Better Auth: pg_dump and restore anywhere; your app code is unchanged. You forfeit nothing on the way out.

  • Hosting

    Vercel

    Preview deploys per pull request and zero configuration for the framework you picked, which is most of what hosting has to do.

    Also considered: Netlify, Cloudflare Workers

  • Local dev

    spindb

    Disposable local databases for your relational engines with no Docker daemon involved, spun up and thrown away per branch.

    Also considered: Docker Compose

    Exit cost — spindb: pg_dump and restore anywhere; your app code is unchanged. You forfeit managed local engine lifecycle — conveniences, not code you own.

Get your own

Answer the questions, read the exit costs, and disagree with whatever you like. The reasoning is on the card.

Pick my stack