Do You Need an App, or a Better Process?

01.Why the request almost always sounds the same

Nearly every conversation of this kind opens with the same sentence: "we need an app." That is understandable. It is the only thing in this territory with a clear name and a price you can ask for.

But that sentence covers four completely different problems, with four completely different solutions, at prices that differ from each other by a factor of ten. They are worth unpacking before you request a quote, because otherwise you get a quote for the wrong problem.

02.Four different problems that present identically

The process is not defined. Everyone on the team does the work slightly differently. Nobody can tell you what happens after step three, because it depends who is doing it. The clear sign: two colleagues give you two different answers to the same question about how things work. Here, software has nothing to automate. There is no "what" yet.

The tool exists and nobody uses it. You already have a system, bought two years ago, of which three functions out of thirty get used. Nobody was trained, nobody configured it for the way you actually work, and the team migrated back to spreadsheets and WhatsApp. The clear sign: you are paying a monthly subscription for something nobody opens. Here, a new app will meet exactly the same fate.

The tools exist but do not talk to each other. You have an invoicing system, a spreadsheet, a form on the site and an inbox, and somebody on the team moves data from one to another by hand several times a day. The clear sign: you can name the person doing the copy-paste and estimate the hours they lose each week. This does not need an app. It needs integrations, which is a separate and far cheaper category.

There genuinely is no suitable tool. You have tried what is on the market, you have talked to the vendors, and nothing fits because your work has a real particularity. The clear sign: you can name the exact function missing from each product you tested. Only here does the conversation about a custom app become the right conversation.

03.The three-question test

Before any quote, answer these three in writing.

1. Can you describe the process in numbered steps, without saying "it depends"? If "it depends" shows up more than twice, define the process first. A developer cannot make that decision for you, whatever you pay them.
2. What is the current cost, in hours or in mistakes, per month? If you cannot estimate it even roughly, you will not be able to judge whether the investment is worth it, and a year from now you will not know whether it worked.
3. What have you already tried, and why did it fail? If the answer is "nothing," it is too early for software. If it is a concrete list of products tested with clear reasons, you are ready for the conversation about building.

People who clear all three usually have a real project. People who get stuck on the first usually have a cheaper problem to solve.

04.What "fix the process first" actually means

That sounds like empty advice, so here is what it means in practice and roughly what each option costs.

• Writing the process down once, as a document. Who does what, in what order, and what happens when something goes wrong. It is free if you do it internally, in one afternoon with the team. It has the best effort-to-result ratio on this whole list and it is skipped almost every time.
• Configuring what you already own properly. Plenty of systems do what you need and nobody has told them how. A few hundred euros for someone who knows the system, plus a training session for the team.
• An off-the-shelf product, chosen carefully. For booking, invoicing, inventory or project management there are mature products costing tens of euros a month. A full year of subscription comes in under the price of the smallest app built from scratch.
• Automations and integrations between what you have. This is where the real gain most often sits. Data flows between the existing systems on its own, the copy-paste work disappears, and you have not built anything new to maintain. The order of magnitude is hundreds to a few thousand euros, against the tens of thousands for a new system.

We wrote separately about the signs you have outgrown your spreadsheet, where the discussion is narrower: you start from one particular tool and ask when it starts costing you. Here the question comes earlier and sits wider.

05.When software really is the answer

There are situations where building is the correct decision and delaying costs you. The signs:

• The manual work grows with the number of clients. If doubling your clients means doubling your admin hours, you have a problem that worsens on its own. Software is the only option that breaks that link.
• Mistakes cost real money, not just irritation. A wrong invoice, a lost booking, an order that never arrives. When a mistake has a price, automation has a calculable return.
• Your clients are asking for something you cannot give them. Access to their own documents, a status they can check themselves, a history of the work. A better process does not solve that, because what is missing is a surface that does not exist.
• Your particularity is real and it is your advantage. If the way you work is the very reason people choose you, a standard product will push you into working like everyone else. Here, custom protects something.

If two or more of these describe you, the question of how much an app costs becomes relevant, and how long it takes becomes the next one.

06.What the mistake costs, in both directions

You build too early. You spend somewhere between five and fifteen thousand euros on an app that encodes a process you were going to change anyway. Six months later the process has changed, the app has not, and every adjustment costs. You paid to make it harder to change your mind.

You wait too long. You hire an extra person for the admin work, then another. That cost is monthly and permanent, unlike the build cost, which happens once. Two years of salary for work an automation was doing comes to several times the price of the automation.

There is no single rule that covers both. There is only the question of whether the process is stable. A process that has not changed in six months is mature enough to be worth encoding. One that changes monthly needs something else first.

07.What this conversation looks like with us

When somebody writes to us with a request for an app, the first meeting covers the current process, who executes it and where it jams, rather than the feature list. Often the outcome is a recommendation smaller than the request: an existing product, a few integrations, a configuration. We say that out of self-interest as much as honesty, because a project built on top of an unclear process ends badly for both sides.

When the conclusion is that something does get built, we start with the process already written down, which shortens everything that follows. We described those stages in how a design project actually runs.

08.The GoodGlyph take

If you take one thing from this article: write the process down before you request the first quote. It is free, it takes an afternoon, and it tells you by itself which of the four situations you are in. If that exercise shows that data just needs to flow between systems, automations and integrations are the cheap road. If it shows that nothing on the market fits, then we talk about a custom app, with the process already clear. Write to us with the process written down and we will tell you which of the two you are in, before any quote.

09.Closing

The most expensive app is the one built to avoid a conversation about how the team works. That conversation costs an afternoon. The app that replaces it costs about a year of salary, and still does not answer the question.