By Nikola, founder at ZEROX. We build SaaS platforms, internal tools, and customer portals for B2B companies and agencies across the US, UK, and Europe. Last updated April 2026.
Every founder evaluating a build partner eventually asks some version of the same question: what will you actually build this on. It is fair, and the answer tells you a lot about how a team thinks. This post walks through the web app tech stack we use for production software, and why we chose each piece. It is for founders and CTOs who want the reasoning, not just the logos.
The short version: we favor boring, well-documented tools with large hiring pools, and we let the product decide the details rather than following trends.
Boring infrastructure is a feature, not a compromise
A web app that runs your business should be built on technology that is stable, hireable, and still going to exist in five years. Novelty is a cost. Every unusual framework or bleeding-edge database is a bet that whoever inherits the code can staff and support it later.
We optimize for the opposite. When we reach for something less common, it is because the product genuinely needs it. You own the code we write, so its upkeep is yours at handoff, and choosing proven tools is us taking that seriously.
The web app tech stack we ship: React, Next.js, and Node
For the front end we build with React, almost always through Next.js. React has the deepest talent pool in front-end development, which matters when you hire in-house or bring in another agency. Next.js gives us server rendering for the pages that need SEO or fast first loads, and plain client rendering for the app screens behind a login where SEO is irrelevant. One framework covers both jobs.
On the back end we default to Node with TypeScript, so one language spans the whole stack and engineers move between front and back end without switching gears. Node is not built for CPU-heavy numerical work, and when a product needs that we run a separate service in a better-suited language. But for a typical SaaS API, portal, or internal tool, it is fast, boring, and well supported.
Postgres or MongoDB: choose for the data, not the trend
We use both, and the choice comes down to the shape of your data, not fashion.
- Postgres is our default. Most business software is relational underneath: users belong to organizations, invoices belong to accounts, permissions cross-reference everything. Postgres gives you transactions, strong constraints, and room to ask complex questions of your data later without a rewrite.
- MongoDB earns its place when the data is genuinely document-shaped and schema-flexible: nested content, or records that vary field by field. It is a deliberate choice, never a default.
The failure mode we see most often is a document database chosen early "for speed," then months spent rebuilding the relational guarantees it never had.
REST or GraphQL
Most products we build use a straightforward REST API: easy to reason about, trivial to cache, and enough for the large majority of applications. We do not add GraphQL because it looks modern.
GraphQL genuinely helps when many clients pull widely varying shapes of data, or a mobile app is minimizing round trips over a slow connection, and when that fits we use it. Otherwise, REST keeps the system smaller and easier for your next engineer to pick up.
Stripe, and the billing details nobody demos
For payments or subscriptions we use Stripe. It handles the card data so you stay out of the worst of PCI scope, and it covers the billing details that look trivial in a demo but are most of the work: proration, failed-payment retries, tax, refunds, plan changes mid-cycle, and the webhooks that keep your database in sync. We treat Stripe as the source of truth for billing state rather than mirroring that logic ourselves.
Hosting, CI/CD, and monitoring: the unglamorous backbone
This is the part that separates software that survives from software that limps. Our baseline on every project includes:
- Managed hosting rather than hand-rolled servers, so patching and uptime are not a person's side job.
- CI/CD from day one, so every change runs the test suite and ships through a repeatable pipeline.
- Error tracking and uptime monitoring wired in before launch, so you hear about problems from a tool, not a customer.
- Backups you have actually tested by restoring, because an untested backup is a guess.
None of this is exciting, and all of it is what you are really paying for. We scope it into the build; it is not an upsell later.
When this stack is not right for you
Honesty matters more than winning the project. If you are building a real-time collaborative editor, a data-science-heavy platform, or something with hard low-latency requirements, parts of this default stack are the wrong starting point, and we will say so on the first call. And if your team is already fluent in a different ecosystem, adopting ours to match a blog post would be a mistake.
If you want the fuller picture of how we take a product from idea to launch, our guide to SaaS MVP development covers the process and timeline that sits on top of this stack.
FAQ
What is the best tech stack for a web app?
There is no single best one. For most B2B SaaS products, portals, and internal tools, React with Next.js, Node, and Postgres is a proven, hireable default. The best choice depends on your data, team, and performance needs.
Should I use Postgres or MongoDB?
Default to Postgres unless your data is genuinely document-shaped and schema-flexible. Most business applications are relational underneath, and Postgres lets you ask complex questions of that data later without a costly migration.
Do I own the code you build?
Yes. Everything we write is yours, with no lock-in. That is one reason we favor mainstream, well-supported tools: you or another team can maintain it after handoff.
How long does it take to build a production web app?
A focused MVP is typically around eight to twelve weeks, depending on scope. We give a fixed quote after a short scoping call so the number is honest before you commit.
Work with us
If you want a straight answer about the right stack for your product, we are happy to have that conversation. Tell us what you are building on our web app development page, or get in touch for a short scoping call and a fixed quote. No lock-in, honest estimates, and code you own.
