Which technology should we build on? Choosing a language, framework and database

Picking a stack usually turns into an argument about which language is faster, when the questions that actually decide the outcome are duller ones: how long will this version keep getting security patches, how hard is it to hire someone who knows it, and what does it cost to reverse the decision if it turns out wrong. All three convert into dates and budget lines. Raw language performance, in a normal line-of-business application, is a rounding error next to how the data model is designed. The question worth answering is not which technology is best, but who will keep this system alive for the next five years and at what cost.

Not every decision carries the same weight

A stack is not one decision. It is a few decisions stacked on top of each other, and the cost of undoing them varies enormously. At the bottom sits the data model and the database, the layer that is most expensive to move years later, because moving data is harder than moving code. In the middle is the application framework: replacing it is a big job, but a bounded and plannable one. At the top sit libraries, most of which can be swapped out inside a week.

We regularly see teams spend two weeks debating a library and then settle the database in the last ten minutes of a meeting. Allocate discussion time in proportion to how expensive the decision is to reverse.

The support calendar is an architectural constraint

How long your chosen version keeps receiving security updates is not a detail for the engineers, it is a constraint that lands on the project calendar. Here is how it looks in September 2026. Node.js 20 lost security support in April 2026, Node.js 24 leaves active support in October 2026, and Node.js 22 receives security fixes only, through April 2027. On the .NET side a release lands every November and LTS versions get three years; .NET 8 and .NET 9 both end on 10 November 2026, while .NET 10 runs to November 2028. PHP extended its policy in 2024 to two years of bug fixes plus two years of security fixes, so 8.3 left active support in December 2025 and keeps getting security patches until December 2027. PostgreSQL closes each major version five years after release, which puts version 14 at November 2026.

Framework windows are tighter still. Django LTS releases get three years of security fixes, meaning April 2028 for 5.2. Laravel ships a major version every year with 18 months of bug fixes and 2 years of security fixes. Angular runs a harder cadence: a major roughly every six months and 18 months of support per release, 6 active plus 12 in long-term support. Spring Boot's open source window is a little over a year, with anything longer sold as a commercial subscription. If your product plan covers three years, those two ends of the spectrum do not produce the same maintenance load, and the difference belongs in the budget from day one.

Upgrading is a fixed cost, not a project

"We will not upgrade for now" is not an option, it is a deferral that accrues interest. What it costs in practice is the subject of our post on end-of-life software. The discipline comes down to three habits: put one upgrade window per year on the calendar, move dependencies in small frequent steps rather than in one heroic jump, and invest in the only thing that genuinely makes upgrades cheap. That thing is test automation. Without tests, a major version upgrade becomes a job whose scope nobody can state up front.

There is a contract side as well. Who owns upgrades, whether they fall inside the maintenance scope and how they are billed should all be written down. Settling it after the fact is unpleasant for both sides, and the models are compared in our post on fixed price versus time and materials.

How many people know this technology

In Stack Overflow's 2025 developer survey the most used languages were JavaScript (66%), HTML/CSS (61.9%), SQL (58.6%) and Python (57.9%). On the database side PostgreSQL led at 55.6%, with MySQL at 40.5%. That is not a quality ranking. It is a list of technologies whose practitioners you can replace, which matters for hiring and for handover.

There are legitimate reasons to pick something niche, and some workloads genuinely justify it. Real-time messaging is a fair example. Just answer the follow-up question in advance: if the person who wrote this leaves, who takes over maintenance, and how long will it take to find a firm that can? Owning the source code solves half of that problem. The other half is handover discipline, which we covered in our post on source code ownership and escrow.

Where are you spending your innovation tokens

Dan McKinley's 2015 essay "Choose Boring Technology" made a point that still holds: a company gets roughly three innovation tokens. Every exciting choice spends one, because along with the new technology you buy a set of failure modes nobody has seen yet.

Spend the tokens where your product actually differs from everyone else's. If you are building order management, the interesting part is probably the pricing or planning engine, and the sensible answer for sessions, queues and storage is the boring one. The value of a well-worn technology is not its feature list, it is that its failures are documented. Which query goes slow and why, what happens when the connection pool fills up: someone has already written it down. That is precisely why we could enumerate the usual causes in our post on database bottlenecks.

Local integrations narrow the list

Any business application has a ring of services it must talk to, and in Turkey that ring is fairly consistent: an e-invoice and e-archive integrator, a payment provider and the 3D Secure flow, bank virtual POS, shipping carriers, an SMS gateway, plus electronic and mobile signature. These providers do not publish official client libraries for every language. If yours is not on the list, you write the client yourself and you maintain it forever. That makes for a concrete question at proposal time: will you use the provider's official library here, or write your own? The genuinely hard parts of payments are in our post on payment integration.

Security criteria: patch speed and defaults

A technology's security profile shows up in two places. First the process: is there a published security advisory channel, how fast do reported issues get patched, and do fixes reach older versions? Second the defaults: does the ORM produce parameterized queries, does the template engine escape output on its own, is CSRF protection built in, do session cookies ship with the secure flags set? A framework with safe defaults reduces the number of decisions your team has to get right every day, which is the cheapest security control available.

Dependency count is a criterion too. An ecosystem that pulls hundreds of packages for a basic install expands your attack surface by the same measure; the full subject sits under software supply chain security. Keeping patches flowing after go-live is covered in our post on patch and vulnerability management.

Managed services are fine, an exit plan is not optional

Buying the database, the queue or authentication as a managed service is the right call for most teams and hands off a meaningful share of the operational load. The question is not whether to use one, it is what leaving looks like: can you export the data in a standard format, is there a second provider speaking the same interface, does the application lean on a provider-specific API? Standard interfaces (SQL, S3-compatible storage, OCI container images) keep the exit cheap. For how much container machinery you actually need, see do you really need Kubernetes, and for how the invoice grows quietly, cloud cost optimization.

Seven questions to ask when a proposal lands

1. When does security support end for the version you are proposing, and when does the next LTS arrive?
2. Who owns major version upgrades, and which clause of the contract says so?
3. If hiring for this technology gets harder, who else could take over maintenance?
4. How many dependencies does a clean install pull, and how many of those shipped a release in the last year?
5. For e-invoicing, payments and shipping, will you use official libraries or write clients from scratch?
6. If a managed service is involved, in what format and over what period can the data be exported?
7. Can we have the reasoning behind this choice as a one-page written note?

The seventh is not a courtesy question. A choice whose rationale cannot be written down is usually just what the proposing team already had lying around. That is not automatically a bad reason, but it should be said out loud.

Write the decision down on one page

The architecture decision record spread from Michael Nygard's November 2011 post and now sits among the practices Thoughtworks recommends adopting on its Technology Radar. The format is short: context (what constraints existed), decision (what was chosen), consequences (what it gives you and what it takes away), and the alternatives considered with the reason each was dropped. It lives in the repository as numbered files like docs/adr/0001-database-choice.md and is versioned alongside the code.

The payoff arrives two years later. When a new developer asks why something is the way it is, the answer is in the file. When the constraints change, you can see which assumption the decision rested on and change it deliberately rather than by accident. It is the cheapest document you can leave for whoever takes over. Writing the requirements themselves is a separate job, covered in our post on writing software requirements.

One step you can take this week

Put the language, framework, database and runtime versions of your current system on a single page, with the security end-of-support date next to each one (endoflife.date is enough for this). Mark everything that expires in the next twelve months and assign each item an upgrade window. If you are starting something new, open the first ADR before anyone writes code.

If you are holding two proposals built on different technologies and cannot tell which one your team can realistically sustain, we can assess both against the same criteria and give you an independent comparison. Wedevit has no partnership with any language or vendor; we judge the options against your team's capacity to maintain them.