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.
| Option | Best for | What you pay monthly | Main trade-off |
|---|---|---|---|
| Next.js | Web apps, and content sites that must rank | Hosting only, often a free tier | Needs a developer to change structure |
| WordPress | Content edited weekly by a non-technical owner | Hosting plus plugin subscriptions | Plugin load, security surface, update breakage |
| Wix / Squarespace | Getting live fast to test an idea | Platform fee that rises over time | Page speed and SEO ceiling you cannot lift |
| Lovable / Bolt | Prototyping an app idea in a weekend | Platform fee plus backend | Not production-ready without a rebuild underneath |
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.
| Option | Language | Best for | Where it costs you |
|---|---|---|---|
| Flutter | Dart | Both stores on one budget, UI-heavy apps | Newest platform features wait on plugin support |
| React Native | TypeScript | Teams already writing React, sharing logic with web | More native glue code than Flutter |
| Swift / Kotlin | Swift, Kotlin | Camera, AR, health data, watch apps, one platform only | Two codebases, two skill sets, roughly double |
| Mobile web app | TypeScript | Testing demand before committing to an app | No push notifications, no home screen, no offline by default |
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.
| Option | Data model | Bills you for | Portability |
|---|---|---|---|
| Supabase (Postgres) | Relational tables with joins | A database instance, storage, bandwidth | Full: export the database, run it anywhere |
| Firebase (Firestore) | Documents in collections | Every document read, write and delete | Data exports; queries and rules are a rewrite |
| SQLite | Relational, in a single local file | Nothing, it runs inside the app | Full: it is one file |
| WatermelonDB / Drift | SQLite plus a sync layer | Nothing locally, server costs apply | Full, built on SQLite |
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.
Got a quote in front of you? Send it over and I will tell you what that stack costs to run, not just to build.
Get a second opinionStraight answers
- What tech stack do you build on?
- Next.js and TypeScript for web, Postgres through Supabase or a managed host for data, and Flutter for cross-platform mobile, with native Swift or Kotlin when the app depends on device hardware. All of it is widely used, so another developer can take over without a rewrite.
- Is Next.js better than WordPress?
- For a web app with accounts, payments or live data, yes. For a small brochure site a non-technical owner edits weekly, WordPress or a hosted CMS is often cheaper overall. The question is whether the site is content someone edits or software people use.
- Should I build a Flutter app or a native one?
- Flutter when you need iOS and Android on a limited budget and the app is standard screens, lists, forms and media. Native Swift or Kotlin when the app is built around camera processing, AR, health data, precise background location or a watch app.
- Why is my current site expensive to host?
- Usually a heavy setup doing work it does not need, plus plugin and platform subscriptions nobody has reviewed in years. It is often fixable without a rebuild.
- Will I be locked in to you?
- No. The code, hosting and accounts are in your name, and I build with tools other developers already know. Postgres data can be exported and run anywhere. That portability is a deliberate choice.