Development
Web development frameworks in 2026: what we actually use for UK business sites
The frameworks we build UK business websites and apps with in 2026, when each one is the right call, and how the choice changes…
· 8 min read
Microservices architecture means building a system as several small services, each doing one job (payments, search, notifications, stock) and talking to each other over APIs or message queues. We design and build microservices and modular systems in Laravel and Node.js for UK businesses at £60 an hour plus VAT. We also spend a fair amount of time talking people out of them.
That is not a sales trick. Microservices became famous because companies with hundreds of engineers needed teams to ship independently. A business with three developers and one product rarely has that problem, and splitting a system up too early swaps one set of headaches for a larger, more expensive one: more servers, more deployments, more things to monitor, and bugs that now live in the gaps between services.
Our default: a well-built monolith, split where it hurts
Most systems we see are better served by a single, well-organised application with clear internal modules, and one or two parts pulled out where there is a measurable reason. People call this a “modular monolith”. It is less fashionable and far easier to live with. You get one codebase to deploy, one database to back up and one place to look when something goes wrong, while the boundaries inside it are clean enough that any module can be extracted later if it needs to be.
So the first thing we usually deliver is not code. It is a short written review of your current system and a recommendation: leave it, tidy it into modules, or split out specific services. You can take that report to any developer.
When splitting out a service is worth it
- Very different load. Image processing, PDF generation, search indexing or a big nightly import spike while the rest of the site is quiet. Moving that work to its own service and queue stops it slowing down checkout.
- Different release speeds. One part changes weekly (pricing rules, say) and every release currently risks breaking the whole platform.
- Shared by several products. One login, one payment service or one notification service used by a website, an app and a customer portal.
- Replacing a legacy system piece by piece. You can’t afford a big-bang switch, so new services take over one function at a time while the old system keeps running.
- Stricter data rules. Payment or health data that is better isolated, with its own access controls and audit trail.
When it isn’t
If your team is small, your traffic is steady and you run one website or app, keep it in one application. If your real complaint is speed, the fix is almost always caching, query tuning and a CDN rather than new architecture; our DevOps and hosting work often solves it in days. If the complaint is that the code is a mess, splitting a mess into ten networked pieces gives you ten messes and a network. Refactor first.
A comparison we show clients
| Item | Modular monolith | Microservices |
|---|---|---|
| Deployment | One app, one pipeline | One pipeline per service |
| Hosting at small scale | One server or container | Several containers, a queue, often a gateway |
| Debugging | One log, one stack trace | Needs tracing across services |
| Team size it suits | 1–10 developers | Several teams working independently |
| Scaling | Scale the whole app | Scale only the busy parts |
| Cost to change direction later | Low if modules are clean | High once contracts between services are fixed |
What we build
- Architecture reviews with a written recommendation and a rough cost for each option.
- Modular restructuring of Laravel and Node applications, with clear boundaries and tests around each module.
- Individual services in Node.js or Laravel, packaged in Docker, with versioned REST APIs and documentation.
- Message queues and background workers (Redis, RabbitMQ or managed cloud queues) so slow jobs don’t hold up users.
- API gateways and single sign-on shared across a website, app and portal.
- Logging, tracing and alerts so you can see a request travel through every service and find where it failed.
- Gradual “strangler” migrations off legacy systems, one function at a time, with both systems running in parallel until the switch.
What it costs
Our rate for this work is £60 an hour plus VAT, with discounts from 5 % at 10 hours up to 25 % at 100 hours. These are typical ranges, not quotes.
| Piece of work | Typical effort | Cost before VAT |
|---|---|---|
| Architecture review and written recommendation | 10–15 hours | £570–£810 |
| Move slow jobs to a queue and background workers | 20–50 hours | £1,020–£2,400 |
| Extract a first service (e.g. payments or notifications) | 40–100 hours | £2,040–£4,500 |
| Phased replacement of a legacy system | 200+ hours | from £9,000 |
A worked example: a 15-hour review is £900, less 10 % is £810, plus VAT of £162, so £972. If you then book a 100-hour block for the extraction, that is £6,000 less 25 %, so £4,500 plus £900 VAT. Hours never expire, so anything unused rolls into the next phase. Remember the running costs too: three or four small services usually cost more to host and monitor than one app, often by tens of pounds a month at small scale and more as you add environments.
How we work
We read the code, look at your hosting, logs and traffic patterns, and talk to whoever gets called when things break. Then we write down where the real bottlenecks are, with evidence. If we recommend extracting a service, we put it behind the existing system first, route a small share of traffic to it, compare results, and only then switch over. No weekend cut-overs with fingers crossed.
The team is based in London and we are happy to meet in London, but this work runs well remotely, and we work with companies in Manchester, Leeds, Bristol, Edinburgh and across the UK. If you have an in-house team, we can work alongside them and leave them with documentation, tests and diagrams they can maintain without us.
Questions we will ask you
- What actually goes wrong today, and how often? Slow pages, failed releases, outages, a feature you can’t ship?
- How many developers work on the system, and will that number grow?
- Which parts get the most traffic, and when?
- What would it cost the business if one part went down for an hour?
The answers usually make the decision obvious. If you want a second opinion on your architecture, get in touch, or book a block of hours for a review. Related work: API development and integration and cloud solutions.
