Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Picking a Technology Stack You Can Maintain
Custom Software

Picking a Technology Stack You Can Maintain

The best technology for building is not always the best for living with. How to weigh performance and elegance against the ability to find people.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Choose boring, widely used technology unless you have a specific reason not to. The constraint that bites in year three is finding someone who can maintain it, not whether the framework was the fastest option at the time.

The short answer

Pick technology with a large pool of developers, an active community and a predictable upgrade path. Exotic choices are justified by specific requirements, not by preference, and the person making the choice is rarely the one maintaining it in five years.

The question to ask is: if everyone who built this left, how hard would it be to find a replacement?

What actually matters over time

FactorWhy it matters in year three
Size of the developer poolDetermines whether you can hire at all
Community and documentationDetermines how fast problems get solved
Upgrade pathDetermines whether you can stay current
Stability of the ecosystemDetermines how often things break beneath you
Your team's existing knowledgeDetermines the cost of the first year

Raw performance rarely appears on that list, because for most business software it is not the constraint. Where it genuinely is, that is a specific reason and it justifies a specific choice.

Boring is a feature

Widely used technology has more answered questions, more libraries, more people who have hit your problem, and more candidates when you need to hire. Those compound.

  • Problems you hit have usually been hit before
  • Libraries exist for the unglamorous parts
  • Security issues are found and patched by many eyes
  • Hiring is possible at a sensible rate
  • Another supplier can pick it up if the relationship ends

When exotic is justified

A genuine requirement that mainstream tools cannot meet: extreme throughput, hard real-time constraints, a domain where one ecosystem dominates, or an existing team who are expert in something unusual.

Those are real. What is not a reason is that the framework is new, interesting, or what a developer wants on their profile.

Questions worth asking a supplier

  1. Why this rather than the more common option?
  2. How many developers in our market could maintain it?
  3. What is the upgrade path, and what happened at the last major version?
  4. If we moved to another supplier, how hard would it be for them?
  5. What would you choose if you were not going to maintain it?

The last question is the useful one. A supplier answering it honestly is thinking about your position rather than their convenience.

Consistency beats optimality

A system built in one mainstream stack is easier to maintain than one assembled from the best tool for each part. Every additional technology is another thing to upgrade, secure and hire for.

Where a second technology genuinely earns its place, that is fine. The default should be to use what you already have.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

Should we let the supplier choose the stack?

With input. They know what they build well. You know what you will have to live with, and you should ask why.

Is it bad to use a new framework?

Not inherently, but the risk sits with you. New ecosystems change fast, and the hiring pool takes years to build.

What if our team knows an unusual technology?

That is a genuine reason to use it, as long as you accept the hiring constraint if those people leave.

How do we avoid lock-in to a stack?

Keep business logic separate from framework specifics where you reasonably can. Complete portability is expensive and rarely worth chasing.

Keep reading

More on Custom Software

Custom Software

When Off-the-Shelf Software Stops Fitting

Every platform is bent to fit eventually. The signals that you have passed the point where configuration is cheaper than a custom build.

Custom Software

Turning a Critical Spreadsheet Into Software

Most businesses have one. Why it survived, what it encodes that nobody wrote down, and how to replace it without losing the knowledge inside it.

Start here

Weighing up a custom build?

Tell us what you are trying to fix and what you already run. We will give you an honest view on whether custom software is the right answer, what it would involve and a realistic range. If configuring what you have would do the job, we will say so.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →