Devstars
Blog
Date: 28/04/2026
Stuart WatkinsThe short answer: Yes, bespoke web software development still matters in 2026, even with AI coding tools widely available. AI significantly accelerates experienced developers, but it does not replace the domain knowledge, architectural judgement, and failure-mode thinking that production systems require. The most reliable systems combine human engineers with AI tooling, not either alone.
Vibe coding (using AI to generate working code from natural-language prompts) might be a good fit for prototypes, internal tools and quick demos. It is not ready for systems on which real customers, real money or real reputations depend.
Because writing code was never the hard part of building software.
The hard parts are working out what the system actually needs to do, designing it so it doesn’t fall over at scale, and understanding how the humans on either end will actually use it. AI tools are getting better at the first part, are still poor at the second, and are essentially useless at the third without an experienced engineer in the loop.
There is a popular argument doing the rounds at the moment that AI will write all the code, so you don’t need developers any more. Type the prompt, get the app, ship it on Friday. It is a tempting story. It is also wrong, in the same way that “spreadsheets will replace accountants” was wrong in 1985. The tool got better. The job got harder. The people who understood the problem properly ended up more valuable, not less.
The four case studies below show why. None of them could have come out of a vibe coding tool. All of them solved a real, specific, painful business problem.
Because the hard parts are operational, not technical.
Some years back we built a queue-timing platform for Heathrow Airport. The brief sounds simple when you write it down: tell passengers and operations teams how long the queue is, in real time, accurately enough that people would actually trust it.
Anyone who has actually stood in a queue at a major hub knows what makes that hard. You are dealing with multiple terminals, each with multiple security lanes, each with different staffing levels at different times of day, each affected by passenger flow from a hundred different inbound flights. The data is messy. The tolerances are tight. And the moment a wait time on a screen turns out to be wrong, passengers stop trusting any wait time you ever publish again.
We built the platform. It worked. It ran for over a decade across Heathrow and was rolled out to several other airports around the world.
The reason that project succeeded was not the code. The code was solid, but plenty of teams could write the code. The reason it succeeded was that the people building it understood what passengers actually do, what operations staff actually need, and what airport politics actually look like when terminal managers argue about resource allocation. That domain understanding shaped every decision in the architecture.
You cannot prompt your way to that. You can only build it by being in the room, asking the awkward questions, and translating what you hear into a system that holds up under real-world load.
Key takeaway: Real-time systems live or die on architectural decisions made before any code is written. AI can write the code. It cannot make those decisions.
A complete rethink of what the product is, not just better technology.
When we first sat down with G4S Risk Consulting, the product was a monthly PDF. Subscribers paid to receive country-by-country security updates, compiled by analysts and travelling business people, and emailed out as a single document four weeks after the events it described.
You can see the problem from a mile away. By the time the PDF landed, the intelligence was four weeks old. For a corporate security team trying to decide whether to send a delegation to Lagos next week, four-week-old intelligence is not intelligence. It is history.
We rebuilt the whole thing as a geotagged web platform. Analysts around the world contributed bulletins in real time. Subscribers logged in to a secure system, picked the countries they cared about, and got threat maps, downloadable bespoke PDFs, and live alerts. The monthly PDF didn’t disappear. It just became a downloadable summary inside a system that was now doing the actual heavy lifting in real time.
What I want to flag here is that the technology was not the interesting part. The interesting part was redesigning a 30-year-old subscription product so that the core promise — you will know what is happening, where, before it affects your people — actually got delivered.
AI can help you scaffold a CRUD app. It cannot tell you that the real product is trust, and that trust is built or broken on latency. We are still the principal architects of that platform today.
Key takeaway: The hardest part of bespoke software is rarely the code. It is correctly identifying what the product actually needs to deliver.
No, and the reasons matter.
We have been working with Dash, the salary-sacrifice e-bike company. The brief here is genuinely tricky. They are pulling together three things that don’t naturally talk to each other:
We built the employer onboarding system from scratch. Then we built a marketplace that pulls products in from any brand running on Shopify, normalises the data, and lets a Dash subscriber pay for any of those bikes out of their pre-tax salary. Concept to live in under 30 days for the original platform, with the marketplace layered in on top.
Try prompting an AI tool to build that. You will get something that looks like it works, until you try to reconcile a Shopify variant SKU with a payroll deduction calendar and a manufacturer’s stock feed. At which point you will realise that the architectural decisions that determine whether this scales to 1,000 brands or falls over at 50 are not visible in the prompt. This kind of custom API integration — connecting payroll systems, stock feeds and third-party storefronts — is where experience pays for itself many times over.
This is the kind of work where a good systems engineer plus AI absolutely beats either one alone. We use AI heavily to accelerate boilerplate, generate test cases, scaffold integrations and explore edge cases. But the architecture, the failure-mode thinking, the bit where you decide which parts of the system absolutely cannot fail — that is still humans who have done this for 20 years.
Key takeaway: AI can produce code that looks correct. Only experienced engineers can produce systems that stay correct at scale.
Because the hard problems are human, not technical.
Film Locker came to us with a problem the film and TV industry has been quietly losing sleep over for years. When you finish a major production, you have terabytes of footage, project files, masters, dailies, costume references, and all the rest. Cloud storage at that scale is expensive, electricity-hungry, and not always trusted by the studios who own the rights.
We have built them a system for managing offline data storage. It gives production companies a proper digital index of physical archives, full audit trails, controlled access, and a workflow for retrieval that doesn’t require someone to physically walk into a storage facility every time a director needs a clip from three years ago.
The technical interest here is in the metadata layer. The harder problem is in the human layer.
Film and TV teams work in pressure-cooker conditions. Any system you build for them has to survive a 4am phone call from a producer in Los Angeles who needs the unedited rushes from a shoot in 2019. The interface, the search, the permissions, the failure recovery — all of it has to be built around how the people actually work.
That kind of design thinking is the bit that AI is genuinely bad at. AI can generate code that looks like it solves the problem. It cannot generate the deep scepticism that asks “but what happens at 4am when the producer’s tired and the network is slow?”
Key takeaway: Software that survives real-world use is designed around how humans actually behave under pressure. AI does not understand pressure.
The differences are significant. They matter more as the stakes get higher.
| Approach | Best for | Risks | Production-ready? |
|---|---|---|---|
| Vibe coding (AI generates code from prompts, minimal review) | Prototypes, internal tools, throwaway demos, quick proofs of concept | Code looks correct but fails at scale; security holes; unmaintainable architecture | No |
| AI-assisted development (Experienced engineer using AI tools) | Most modern production builds, where speed and quality both matter | Quality depends entirely on engineer’s judgement and review discipline | Yes, when engineer is experienced |
| Bespoke development (Custom-built solution, AI used selectively) | Complex business problems, integrations, mission-critical systems, scale-sensitive workloads | Higher cost; longer scoping phase; requires real domain knowledge | Yes, the highest reliability tier |
The honest position is that almost no modern build is purely one of these. Most production work is AI-assisted bespoke development. AI accelerates the boring parts. Engineers handle the parts that matter.
Key takeaway: Vibe coding is appropriate for prototypes only. Production systems need experienced engineers, with or without AI assistance.
Use vibe coding when all of the following are true:
Use bespoke development when any of the following are true:
Most prototypes start as vibe-coded experiments. Most production systems end up as bespoke builds. The transition between the two is where projects most often go wrong, because teams underestimate how much rebuilding is required to turn a prototype into a production system.
Key takeaway: The cost of treating a prototype as production code is almost always higher than the cost of rebuilding it properly.
We use AI throughout the development process, but never as a substitute for engineering judgement.
Specifically, our developers use AI to:
What we do not use AI for:
The honest answer is that a great systems engineer using AI will always produce a better result than either AI alone or a less experienced engineer using AI. Both have access to the same models. Only one has the domain knowledge, the architectural instinct and the scar tissue from previous mistakes that lets them direct the AI properly.
Key takeaway: AI handles the volume. Humans handle the judgement.
It does not mean writing every line by hand. It means building exactly what the problem requires, using whatever combination of human expertise, AI tooling, off-the-shelf components and custom code makes the system work.
The judgement of what to combine, in what order, for what purpose, is the skill. The code is just the output.
Looking back across Heathrow, G4S, Dash Rides and Film Locker, the common thread is not the technology. WordPress, custom Yii applications, Shopify integrations, secure web platforms — the stack is whatever the problem demands.
The common thread is that we like working on projects where we can examine a problem and solve it really effectively. Clients come to us because they have something specific that off-the-shelf tools cannot do, or because the off-the-shelf approach has stopped scaling, or because the problem they are trying to solve has not been solved before by anyone.
That is what bespoke web software development looks like now. The tools have changed. The need for people who understand the problem properly has not. You can see how this plays out in our Investors in Property case study and the Sort Your Future matching platform — two very different problems, same approach.
If you have a problem that does not fit existing tools, or one where the existing tools have stopped fitting, that is the conversation worth having. Drop me a line at stuart@devstars.com or book a proper chat.
Bespoke web software is built from the ground up to solve a specific business problem, rather than configured from off-the-shelf templates or platforms. It is appropriate when existing tools cannot do what you need, or have stopped scaling.
Not in the foreseeable future. AI tools accelerate experienced developers significantly, but the architecture, domain understanding and failure-mode thinking that determine whether a system works in the real world still depend on humans. AI tools used by engineers without that experience tend to produce systems that look correct but fail under load.
Vibe coding refers to using AI tools to generate working code from natural-language prompts, often without the developer reading or fully understanding the output. It is useful for prototypes, internal tools and quick demos. It is not suitable for production systems where reliability, security or scale matter.
It depends entirely on scope. We have taken Dash Rides from concept to live in under 30 days. Larger enterprise platforms like the G4S intelligence system took several months for the initial build, with continuous development since. The honest answer is we will scope it properly before we quote.
Custom WordPress sites are built on the WordPress platform with bespoke themes and functionality. Bespoke web software refers to applications built from the ground up, often without using a CMS at all, where the business logic is too complex or specialised for a CMS to support. The line between the two depends on what the system needs to do.
Project minimums at Devstars start at £15,000 for development work, with most enterprise platforms ranging from £30,000 to £80,000 for the initial build. Ongoing development and maintenance is typically retained at a monthly rate. We scope every project properly before quoting, because the cost depends entirely on what the system needs to do.
Yes, and we recommend it. Vibe coding is genuinely useful for testing whether an idea is worth building. The prototype rarely becomes the production system, but it almost always sharpens the brief. Bring us the prototype and we will tell you honestly what needs rebuilding and what can be carried across.
We expect them to. Bespoke development is iterative by design. The architectural choices we make at the start are specifically intended to absorb change without rebuilding from scratch. We will tell you up front which changes are cheap, which are expensive, and why.
We have built bespoke platforms for Heathrow Airport (queue-timing), G4S Risk Consulting (global intelligence), Dash Rides (multi-vendor e-bike marketplace), Film Locker (offline data storage), the Ministry of Defence (secure research tools), Investors in Property (SalesForce-integrated property portal) and many others. Our core team has been building this kind of work together for nearly two decades.
Tell me what you’re trying to fix. Half an hour, no pitch, no slide deck.
If we’re the right fit we’ll talk about what’s next. If we’re not, I’ll point you to someone who is.
