Commissioning a web app isn’t something most organisations do every day. You’re deciding on software you won’t build yourself, for colleagues who will use it every day once it’s live. The projects that go wrong rarely founder on technology. They founder on choices made too late, or not made at all.
We develop web applications from Amsterdam. The same handful of points comes up across those projects, time and again. Nothing secret, just things that easily get buried in the rush of a project.
Start with the challenge, not the wish list
“We want a web app” is a wish, not a brief. The useful question is which challenge the application needs to solve: which process keeps stalling, where people lose time, which information is never in order. Write that down and put it in order of priority. Features that don’t touch any of those core points can wait on the bench.
Involve the people who’ll actually use it early on. An hour spent watching a planner or a back-office colleague at work tells you more than an hour discussing features in a meeting: you see where the work chafes and which steps an application can take over.
Keep your budget honest
What a web app costs depends on its scope, the integrations with other systems, and the requirements around security and user numbers. What almost every project has in common: something comes up that nobody foresaw. Build in room for that in advance, in both budget and planning. And count your own hours too, because giving feedback, testing and bringing colleagues on board takes time from people who are already busy.
Choose a partner who asks follow-up questions
Past work tells you something: look at cases and pay attention to projects that resemble your situation. The first conversation tells you more. A good partner starts with your process and your goals, not their own technology, and translates every technical choice into what it delivers for you.
In that conversation, ask at least:
- how you’ll see, along the way, what’s finished and what isn’t;
- how changes during the project are discussed and priced;
- who owns the source code, and who can maintain the application afterwards.
Elsewhere in our knowledge base, we’ve set out which questions to ask before commissioning bespoke software.
Ease of use beats the longest feature list
An application that responds quickly and holds together logically gets used. One that’s packed with options but slow or confusing gets worked around, which means it delivers nothing. Start with the tasks that come back every day and make those flawless. The rest can wait for a later round, guided by what users turn out to need after launch.
Test before that launch with real users in realistic scenarios, not only with the project team. Anyone who helped design the system knows it too well to still spot the stumbling blocks.
The work starts after launch
A web app is never finished. Browsers change, security requirements shift, and your organisation doesn’t stand still either. So agree on maintenance and ongoing development up front: who monitors it, who resolves disruptions, how new requests get picked up, and what that costs per year. Regular, small-scale maintenance is almost always cheaper than a major repair later on.
Hold these points against your own plan before you sit down with agencies; the conversation sharpens immediately. If you’d like to see what a project like this looks like with us, from first sketch to maintenance, take a look at web applications and portals.