A web application rarely fails because of the code. When we’re asked to get a stalled project moving again, we keep seeing the same causes. They start in the conversations before development begins and in the silence after launch, which is exactly why they can be prevented.
We’ve seen these five, in various guises, since 2001. Recognise one in your own project and that’s no reason to panic, but it is a reason for a conversation this week rather than next quarter.
Nobody pinned down the real question
“We need a portal” is not a question, it’s a conclusion. What has to improve, for whom, and how will you know it’s worked? Leave those questions unanswered and everyone involved ends up building a different application in their head. You only notice at delivery, when everyone expected something different and the scope has already been stretched three times over.
The fix doesn’t cost a single line of code: before development starts, pin down which work process the application changes and which features are essential to that. Everything else is version two.
The technology was chosen on impression, not on the work
The newest framework feels like a safe choice, because it’s modern. But technology your team doesn’t master is a risk you pay for again every week. The right question isn’t what’s trending, but what the work actually needs: how many users, which links to existing systems, who maintains this in five years. Proven technology that fits the question almost always beats the newest tool with teething problems.
Users only see the application at launch
This is the pattern that costs the most money. The demo for management runs flawlessly, the steering group is satisfied, and the people who have to work with it every day open the application for the first time on launch day. Within a month, the old Excel spreadsheets are open again.
So involve end users from the first design onwards. Let them click through a prototype before any code is written, and watch over their shoulder as they do their everyday work. Every assumption you catch this way is a round of rebuilding you don’t have to pay for.
The schedule is built for a perfect day
Unrealistic deadlines lead to rushed work, rushed work leads to mistakes, and mistakes leave a team firefighting after the fact while trust drains away. Underestimating complexity is human; not leaving room for it is a choice.
So break the work into small steps that each deliver something working, so you can adjust based on what’s actually there rather than on a progress report. And be upfront about how long it takes to develop a web application: that depends heavily on how quickly decisions get made, not just on the build itself.
Attention drops off after launch
Launch feels like a finish line, but for the application the work is only just beginning. Browsers change, security holes get discovered, connected systems get new versions, and users develop new needs. An application nobody looks after becomes slow first, then vulnerable, and eventually the system everyone works around.
So arrange ownership for afterwards right at the start: who monitors it, who carries out the security updates, and which budget pays for that. Maintenance isn’t a cost you put off for as long as possible, it’s the reason the investment keeps paying off.
Has one of your applications ground to a halt like this, or do you want to stop your new project ending up on this list? At ongoing development and maintenance, we also take on applications built by others. The first conversation then isn’t about technology, but about where it’s hurting.