Choosing a tech stack: Next.js, Flutter, Supabase and what they cost to run

A stack is the set of tools your software is built on. It is the biggest cost decision in the project, and it is usually made for the developer's convenience rather than the client's monthly bill.

The build is one payment. The stack is every month for as long as the business runs. So the question I ask at the start is not what is the best tool, it is what is the cheapest thing that does this job properly and will still be supported in five years.

The costs nobody quotes for

You get quoted for the build. You do not get quoted for hosting, the database, image delivery, transactional email, monitoring, the CMS licence, plugin subscriptions, app store fees, and the developer you will need on retainer because nobody else can follow how it fits together.

Those are the real numbers. Get them on the table before you sign anything, and ask for them per month at your expected usage, not at zero.

Web: Next.js, WordPress or a builder

Next.js is a framework built on React that renders pages on the server, so content arrives as finished HTML that search engines and AI assistants can read. It hosts on Vercel, Cloudflare or Netlify, and a mostly static marketing site runs on a free or near-free tier indefinitely. A web app with a database and authentication costs more, and the database is nearly always the largest line.

WordPress makes sense when a non-technical person edits content weekly and the site is essentially documents. It stops making sense when it is carrying twenty plugins for a five page site, each one a subscription, a security risk and something that breaks on the next update.

Wix, Squarespace and Lovable get you live quickly, which is genuinely useful for testing an idea. The cost is control and a platform fee that rises when the platform decides. If the business depends on the site, move off before it is business critical, not after.

Mobile: Flutter, React Native or native

Flutter compiles one Dart codebase to native iOS and Android apps. For standard apps, lists, forms, maps, chat, media, it performs like native and saves roughly a third against building twice. React Native is the equivalent for teams already writing React and TypeScript who want to share logic with a web app.

Native Swift with SwiftUI, or Kotlin with Jetpack Compose, earns its cost when the app is built around the device: serious camera work, AR, HealthKit, precise background location, watch apps, or platform features released this month. It also wins when you only need one platform, because cross-platform buys you nothing there.

One thing worth saying before any of it: if you are still testing whether people want the product, a mobile web app needs no store review and no release cycle. Build native once the demand is proven.

Data: Postgres, SQLite, Supabase or Firebase

Postgres is my default. It is free, open source, hosted by everyone, and it handles relational data, JSON, full text search and geospatial queries without adding another system. Supabase packages it with authentication, file storage and realtime updates, and because it is Postgres underneath you can export the database and run it elsewhere.

Firebase is the alternative, and it is a document database rather than a relational one. It is quick to start and it bills per document read, which is why list heavy apps produce surprising invoices. Moving off it later is a rewrite of the data layer, not an export.

SQLite is a database in a single file that runs inside the app rather than on a server. It is the right answer for storing data on a phone, for desktop software, and for low traffic sites with no separate database to pay for. On mobile, libraries like Drift or WatermelonDB sit on top of SQLite and handle syncing local data back to the server when a connection returns, which is what you need for anything used on site, in a basement or on the Underground.

3D and graphics, when it comes up

Product configurators and 3D previews run in the browser with Three.js, usually fed by models built in Blender and exported as glTF. The technology is not the expensive part. Preparing the model is, because a CAD file or a high polygon sculpt has to be reduced and baked before it belongs on a web page. Keep the whole scene under a few megabytes or mobile visitors leave before it loads.

Where budgets quietly go

Images. Usually the largest thing on the page and the largest line on the bandwidth bill. Handled properly they cost almost nothing.

Plugins and add-ons. Each is a subscription, a security surface and a dependency that breaks on update. Many can be replaced with a small amount of code that does exactly one job.

Per seat pricing. Fine at three people, painful at thirty. Worth checking the curve before you commit.

A stack only one person understands. That is not a technical problem, it is a leverage problem. If you cannot replace your developer without a rebuild, you have been done over.

How I decide

Three questions. What does the business need this to do. What will it cost to run every month for the next five years. Could another developer pick it up without a rewrite. If the boring option wins on all three, it wins. It usually does.