What goes wrong with
app development?

Cause 1

Scope that grows without anyone noticing

Most app projects start with an idea that sounds clear. "We want an app where our customers can place orders." Fine. But somewhere between that conversation and the first line of code, new wishes appear: a back-office management panel, push notifications, an integration with the planning or accounting system, and maybe a web version too.

Each individual request seems reasonable. Together they double the size of the project, and with it the cost and timeline. This is one of the most common reasons projects run over.

It almost always starts with unclear agreements at the beginning: what is included, and what is not? A good agency defines this per phase, with its own budget and deliverable. That way you know what you get for each phase, and can decide per phase whether to continue.

Monitoring progress: a check every two weeks

Clear agreements only solve half the problem. The other half is progress monitoring. When scope and expectations are not well aligned, too few contact moments mean problems are discovered too late.

An approach that prevents this: every two weeks you show what has been built: not as a status report, but by demonstrating the working product. Does it look like the client expected? That way you can course-correct in time, rather than discovering after six months of building that half of it needs to change.

Cause 2

Who writes the code, and how good is it?

A quote says nothing about who actually does the work. Some agencies present a team of experienced developers and then deploy interns as full contributors, with insufficient supervision.

How do you recognise this? If a project consistently runs over without an obvious reason: not due to unclear scope or external integrations, but simply always "needing a bit more time". That is a warning sign. Experienced developers estimate better and ask for clarification upfront rather than having to rebuild afterwards.

A second signal: if you ask whether automated tests are written and the answer is vague. Such tests automatically check whether existing functions still work after something has been changed. Agencies that do not invest in this deliver faster, but the deferred maintenance that creates will cost you later in bugs, delays and expensive rework.

The same applies to code structure: without automated style checks, the code quickly grows into what developers call "spaghetti code": code that works, but that nobody dares touch for fear of unexpected consequences. If you later bring in another agency to take over, that can cost considerably more than a new project.

Cause 3

Licence costs you do not see coming

Building custom software costs more upfront than using off-the-shelf subscription software. That is true. But the comparison does not stop there.

With subscription software, costs increase over the years. They are often tied to usage: number of users, amount of data, the number of actions the software performs. What is a manageable amount in year one can become a significant expense by year four.

Custom software does not have that dependency. You pay once for the build, then only for hosting and maintenance. The software scales without the bill growing with it. We build exclusively custom software, without licence dependencies.

Who owns the software?

If an agency builds the app for you, that app is not automatically yours. It depends on what the contract says. Many agencies do not put anything in writing about this, or phrase it vaguely.

Imagine: your supplier goes bankrupt, is acquired by a party with different rates, or simply stops providing the service. The code is then not your property, but the supplier's. In an acquisition, that ownership transfers to the new party. In a bankruptcy, it falls into the estate. Either way, you have no guarantee that you can continue developing the app.

This risk is not hypothetical. We regularly receive calls from business owners whose supplier went bankrupt: the app is still in the App Store, but on the agency's account. The source files are nowhere to be found. They are left empty-handed, for software they paid tens of thousands of euros for.

We contractually establish in every agreement that the source code becomes the client's full property upon delivery.

Cause 4

Decisions that keep getting postponed

An underestimated cause of delay: the client who does not make decisions.

App development constantly requires choices. Which feature takes priority? How does this screen work exactly? What is the text on this button? If those choices are not made quickly, the build team waits. And that waiting costs money, even when no hours are being worked.

An agency that says nothing about this is not doing you a favour. A good agency makes expectations clear upfront: for each build period there is a list of decisions that need to be made before work begins. If they do not arrive in time, the work shifts.

How we approach it

Want to know how we handle this?

We work in phases with a fixed deliverable per phase, write automated tests, and contractually establish in every agreement that the source files become the client's full property upon delivery.

Want to know what that means for your project? We are happy to explain in an introductory call: no sales pitch, just an honest conversation about what your project needs.