Founders often ask which technologies their app should be built with. It is a fair question, and online it gets passionate answers. In practice, for most business apps, the choice between mainstream options matters less than people think, and a few other factors matter a lot more.
This post covers how I think about stack choices, the stack I use for most client work and why, and the mistakes that are genuinely expensive.
What actually matters
1. Can you find people who know it?
The most important property of a stack is that developers who know it are available, now and in five years. You will need to hire, replace or add developers at some point. A mainstream stack makes that possible. An exotic one, chosen because a single developer loved it, can leave you stuck.
2. Is it mature and maintained?
Prefer technologies with years of production use, regular releases, security updates and a large ecosystem of libraries. New frameworks can be exciting, but your business should not be their test case.
3. Does it fit the product?
A content website, a booking app, a real-time dashboard and a data-heavy back office have different needs. Choose for the actual product, not for a hypothetical future at enormous scale.
4. How will it be hosted and run?
A stack that runs comfortably in containers on a standard Linux server keeps hosting simple and portable. See running Docker Compose in production on a single server.
5. How much lock-in does it create?
Some platforms make the first weeks very fast and the later years painful: proprietary backends, low-code tools with limits you discover too late, or services that are hard to leave. Lock-in is acceptable when it is deliberate and the trade-off is clear.
6. What does the developer know well?
A developer working in a stack they know deeply will deliver faster and with fewer bugs than one learning on your project. It is reasonable to factor this in, as long as the stack also passes the points above.
The stack I use, and why
For most client projects I use a small, consistent set of technologies, visible across my work:
- React Native for iOS and Android apps. One codebase, native apps in both stores, with native modules when needed. Used for Pro Clean+, the technician app of NeonTask and Local Meals. See React Native vs native apps.
- Next.js for web apps, admin panels and marketing sites that need more than a CMS. Used for the NeonTask web app and the Pro Clean+ backend and admin.
- .NET Core for APIs with complex business logic and finance, as in NeonTask and Local Meals. It is fast, strongly typed and well supported over the long term.
- PostgreSQL as the default relational database. Reliable, well understood and flexible. See Postgres backups that actually restore.
- Docker and CI/CD for every deployable service, so environments are reproducible and releases are routine. See a CI/CD pipeline for a small team.
- WordPress with Elementor for content-led websites where the team must edit pages without code, as with AgriDev and Alpha Green. See WordPress or a custom Next.js site.
Each of these is mainstream, mature and widely known. A different competent developer could pick up any of these projects.
Common choices, briefly
One language everywhere? Using TypeScript for the web, mobile and backend reduces context switching and lets code be shared. A separate backend language like .NET or Java brings strengths for complex domains. Both approaches work; consistency within a project matters more.
SQL or NoSQL? For business apps with customers, bookings, orders and invoices, relational data is the natural fit. Start with Postgres unless there is a clear reason not to.
Backend-as-a-service? Hosted backends can speed up prototypes. For a product with real business logic, permissions and integrations, a proper API you control is usually worth it. If you start with a hosted backend, plan how you would move off it.
Microservices? Almost never for a first version. A well-structured single backend is easier to build, deploy, debug and afford. Split later if a real need appears.
Serverless? Useful for some workloads, such as scheduled jobs or spiky traffic. For a typical business app, a small server or two is simpler and more predictable. See scaling on a single server.
Third-party services are part of the stack
The stack is not only languages and frameworks. Every app also depends on outside services: email delivery, SMS or WhatsApp messages, maps, push notifications, error tracking, file storage and sometimes AI models. Treat them with the same care:
- Prefer services with clear pricing, good documentation and a way to export your data.
- Wrap each one behind a small layer in your own code, so replacing a provider later means changing one module, not the whole app.
- Keep a list of every service, which account owns it and who pays for it.
- Check what each one does with your users' data.
These choices often cause more trouble years later than the framework does, because they are made quickly and forgotten.
Mistakes that cost the most
- Choosing for a scale you do not have. Complex distributed setups slow you down for years before you might need them.
- Mixing too many technologies. Every extra language, database or framework adds maintenance and hiring costs.
- Picking a niche framework because of a single developer's preference.
- Building on a low-code platform without checking its limits on data, logic, users and export.
- Ignoring the admin side when choosing tools; it is often the largest part of the app. See what your admin panel needs.
- Not owning the infrastructure accounts. Whatever the stack, accounts should be in the company's name.
Questions to ask your developer
- Why this stack for this product, specifically?
- How easy would it be to find another developer who knows it?
- Where will it be hosted, and could it move elsewhere?
- What are the main third-party services, and what happens if one changes its pricing?
- How are updates, backups and monitoring handled?
For more, see questions to ask before hiring a developer.
When to revisit the choice
Stack choices should be stable, but not permanent. Revisit when:
- A core technology approaches end of support.
- Hiring becomes consistently difficult.
- A part of the system has outgrown its tools, for example reporting that needs a separate analytics database.
Even then, change one part at a time. Rewrites of everything at once are rarely the answer; see taking over an inherited codebase for how I assess this.
Summary
Choose mainstream, mature technologies that fit the product, can be hosted simply and that developers can be found for. Keep the number of technologies small. Own your accounts. Then spend your energy on the product itself, because that is what users notice. Nobody downloads an app because of its framework; they keep using it because it works, it is fast and it solves their problem every time they open it.
If you are starting a product and want a second opinion on the technical plan, read about me and get in touch to book a call.