Almost every first call about a custom software project reaches the same moment: the client asks what technology we'd use. React? PHP? Python? Does it matter? Should you have an opinion?
The honest answer is that the technology choice matters — but not in the way most people expect. It almost never determines whether the software works. It does determine how easy it is to find someone else to maintain it five years from now, and how deeply you're locked into whoever built it. Those are business decisions, not technical ones — which makes them yours.
What a tech stack actually is
A tech stack is the combination of programming languages, frameworks and tools used to build and run a piece of software. A typical business application has three layers:
- The front-end — what users see and interact with in a browser or app
- The back-end — the server-side code handling business logic, authentication and data
- The database and infrastructure — where data lives and what keeps it running
Each layer has several competing technologies. The choice between them is partly technical, partly habit and partly fashion — which is exactly why you need to understand what drives the decision before you sign anything.
Why it matters to you as a business owner
Developers sometimes frame the stack choice as purely technical and outside your concern. That framing serves them, not you. Three business consequences flow directly from the choice:
The talent pool. Some technologies have far more developers available than others. PHP, JavaScript and Python are used by hundreds of thousands of developers across the Netherlands and Europe. A custom framework developed by a niche consultancy might have a talent pool of twelve. When your original developer leaves, moves on or raises their rates, the stack determines how easily you can replace them — a narrow pool means higher cost and longer waits for everything after launch. As the piece on what maintenance actually costs makes clear, launch is not the finish line.
Longevity and security updates. Widely adopted technologies receive security patches, framework updates and community support for decades. Niche technologies get abandoned when the company behind them pivots or fails. The framework version your software runs on will need updating every few years, and doing that is vastly simpler when the technology has an active community rather than a GitHub repository with no commits in three years.
Vendor dependence. A proprietary stack — one the developer built themselves or that only their company knows — is the most complete form of vendor lock-in that exists. The code may technically be yours, but if no other developer can understand it without months of onboarding, you're not actually free to move on. Standard, widely-known technology is the structural protection against this.
The stacks you'll actually encounter
For business software in 2026, a handful of combinations cover most projects:
- JavaScript / TypeScript (React + Node.js) — The most common stack for new builds. One language across front-end and back-end, a huge talent pool, strong community. The default choice for most web applications and APIs.
- PHP / Laravel — Mature, stable and widely known. Enormous global talent pool. Excellent for business applications and anything where speed-to-market matters. Often wrongly dismissed as old — it runs a substantial share of the web and is actively maintained.
- Python (Django / FastAPI) — Strong for data-heavy work, internal tools and applications that need to integrate with analytics or machine learning pipelines. Readable codebase and good long-term maintainability.
- Java / .NET (C#) — Common in larger enterprise environments and integrations with existing enterprise systems like SAP or older ERP platforms. Excellent tooling and long-term stability. Build and maintenance costs tend to be higher.
Any of these can produce excellent, maintainable software. Any of them can also produce a poorly built mess. The stack sets the ceiling on available talent and the floor on future maintenance costs — but the engineering decisions made week by week are what you're actually buying.
The one question that settles most stack debates
Ask this: How many developers in my region know this stack well enough to maintain it without months of ramp-up?
If the answer is "thousands," you're fine. If the answer is "our team, and a few others we know," stop and find out why. There may be a legitimate reason — a specific integration with an enterprise system, for instance. But in most cases, a developer proposing an unusual stack is proposing it because it's what they know, not because it's what your business needs.
Warning signs to watch for
- "We have our own framework" — There are thousands of mature, battle-tested frameworks. Building a proprietary one is rarely justified for a business application, and it exits you into a world only that developer can maintain.
- No answer on who would maintain it if they left — A developer building on standard technology should have a confident answer: "any competent React developer can take this over with an afternoon of reading." Vague answers here are the signal that matters.
- Stack chosen for the developer's convenience, not yours — "We prefer it" is not a reason. "It solves a specific problem your project has" is.
What to ask before you approve the stack
These four questions cover what you need to know:
- Why did you choose this stack over the alternatives?
- How large is the available talent pool for this technology in the Netherlands?
- Is the framework actively maintained, and what's its release history for the past two years?
- If you were no longer available, how long would it take another developer to get up to speed?
The answers you want are concrete and calm. Defensiveness or jargon as a substitute for specifics is the signal to probe further. A good developer using a good stack has nothing to protect — they'll walk you through it plainly. And this clarity is exactly what a proper discovery phase is designed to produce before any code is written.
The part that matters more than the stack
Performance, security and long-term maintainability are determined far more by how carefully the software is built than by which technology it runs on. A well-structured PHP application is more maintainable than a sloppy Node.js one, and vice versa. The stack sets the parameters — it does not guarantee quality. The engineering discipline applied week by week does.
This is why the stack question belongs in the intake conversation, settled before a line of code is written. By the time sprints start, the choice should already be clear to both sides — and clear on terms you understood, not just accepted.
Want a straight read on a proposed stack?
If you're evaluating a proposal and the technology choice isn't clear to you, send it over. I'll give you a plain-language read on whether it's the right fit for your project — including what the long-term implications are. How a custom software project runs here covers the ownership and handover terms that protect you when circumstances change.