Choosing the right technology to grow your business is less about finding the most advanced option than about avoiding one you will regret. The right choice is widely used, has years of vendor support ahead of it, is known by enough developers that you can hire or change supplier, leaves you owning the code and the data, and has a cost you can predict as the business gets bigger. Systems seldom fail a growing business because the technology could not do the job. They fail because, five years on, nobody can be found to change them.
This article is about the technology a business system is built on: the programming language, the database, the hosting and any platform underneath. It applies when you are commissioning something new and when you are deciding what an ageing system should move to.
Start with the problem, not the technology
Before any technology is discussed, write down what the system has to do: who will use it, which tasks it supports, roughly how much data it will hold and which other systems it must exchange data with. A supplier who recommends a technology before asking these questions is recommending what they already know.
Then check whether you need to build at all. If a packaged product does the job, its technology is the vendor’s concern, and your questions are about fit, price and getting your data out. Our articles on bespoke and off-the-shelf software and on bespoke software or a low-code platform cover that decision. The six tests below matter most when software is being written or rewritten for you.
Six tests for any technology
| Test | A good sign | A warning sign |
|---|---|---|
| Is it mainstream? | Used widely for this kind of system for years | New, fashionable, or kept alive by one small company |
| How long is it supported? | The vendor or project publishes end-of-support dates | No published policy, or the current version is near its end |
| Who can maintain it? | Several UK suppliers and plenty of developers work with it | Your supplier’s own framework, or a skill only one person has |
| What does it cost as you grow? | Costs you can estimate for double the users and data | Per-user or per-transaction fees nobody has projected |
| Does it fit what you have? | Works with your existing systems, sign-in and skills | A second set of skills and hosting to look after |
| Can you leave? | You own the source code and can export the data | The code or the data stays with the supplier or platform |
Mainstream. For business software, boring is a virtue. A widely used technology has more developers, better documentation, more ready-made components and more suppliers able to take the work over. Novelty benefits the developer’s CV more than your business.
Support dates. Every serious technology has a published lifecycle, and upgrades are a recurring cost, not a surprise. Microsoft’s .NET 10 is supported until 14 November 2028, and a new long-term support version appears every two years. SQL Server 2025 is supported until 6 January 2036. PHP 8.5 receives security fixes until 31 December 2029. Ask for the dates of everything proposed and the cost of keeping up. Our end-of-support pages list the Microsoft ones.
People. Ask how many developers the supplier has who know the technology, and who else could support it if the relationship ended. A system written in a supplier’s private framework can only be maintained by that supplier.
Cost over time. Add up licences, hosting, upgrades and support over five years, at the size you expect to be and not the size you are. Per-user pricing that is trivial for ten people can be a large bill for two hundred.
Fit. A technology that matches what you already run means one set of skills, one hosting arrangement and simpler connections between systems. If staff sign in with Microsoft 365, a system that uses the same sign-in saves a password and a support call.
The way out. Growth sometimes means outgrowing a supplier. Make sure the contract gives you the source code and the right to use it elsewhere, that accounts for hosting and domains are in your name, and that the data can be exported in a standard format. Our answer on who owns the source code of bespoke software sets out what to check, and it is a point to take legal advice on.
Where the mainstream choices stand
For a web-based business system the established choices include Microsoft’s .NET with SQL Server, PHP with MySQL, Java, Python, JavaScript on the server, and Ruby on Rails. All of them are capable of running a business of 10 to 500 staff. The differences that reach the person paying are in hiring, licences, hosting and how often upgrades come round, and our comparison of ASP.NET and PHP works through one such pair in detail.
CodeFirst works mostly with Microsoft technology, so that is where our own experience lies. We would not tell a business with a healthy PHP or Rails system and a good supplier to change it.
Three wider points apply whichever you choose.
- Cloud hosting is now the default for new systems. Managed services reduce the upkeep you are responsible for. They also bring a monthly bill that grows with use and, if you build heavily on one provider’s own services, a dependence on that provider.
- AI features do not need a special technology. They are normally added by calling an AI service from the application, which any mainstream technology can do. A wish to add AI later is not a reason to choose something unusual now.
- A phone app is a separate decision. A web application that works well on a phone screen covers many needs. Build an app when there is a specific reason, such as working without a signal.
If you are choosing what an old system moves to
Stay in the same family where you can. A system written in VB6, Classic ASP or .NET Framework can move to modern .NET in stages and often keep its existing database, with the business rules carried across piece by piece. Moving to an unrelated technology means rewriting everything at once, and the rules nobody wrote down are the first thing lost.
Check too whether the whole system needs to move. Often one part is out of support and the rest is sound. Our maintain, modernise or replace tool is a ten-question way to think that through.
Questions to ask whoever recommends a technology
- Why this, and what was the alternative you rejected?
- When does support end for each component, and what will the upgrades cost?
- How many of your developers work with it, and who else could take it over?
- What will licences and hosting cost per year at twice our current size?
- What exactly will we own at the end, and what stays with you?
Ask for the answers in writing. A sound recommendation survives all five, and a supplier who cannot answer the third is describing a risk to you.