# Do You Need an App, or a Better Process? > Published 2026-08-18 ยท Canonical: https://goodglyph.com/en/blog/do-you-need-an-app-or-a-better-process Some of the conversations that start with \"we need an app\" end more cheaply without one. Here is how to tell the difference before you spend, what fixing the process actually looks like, and the signs that this time you really do need software. The test is simpler than it sounds. Write the process down on paper, step by step, exactly as it happens now, with the names of the people who do each step. If you cannot write it down, the problem is not the missing app. It is that the process does not yet exist in a form anyone other than you could execute. If you can write it down and the steps are clear, but the work takes too long or things get lost between the steps, then yes, there is something for software to automate. That distinction matters because it is the difference between a few hundred euros and several thousand. An app built on top of an unclear process does not clarify anything. It encodes the mess and makes it harder to change, because from that point on every adjustment goes through a developer. ## 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. ## 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. ## 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. ## 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](https://goodglyph.com/en/blog/from-spreadsheets-to-an-internal-tool), 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. ## 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](https://goodglyph.com/en/blog/how-much-does-an-app-cost) becomes relevant, and [how long it takes](https://goodglyph.com/en/blog/how-long-app-development-takes) becomes the next one. ## 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. ## 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](https://goodglyph.com/en/blog/how-a-design-project-actually-runs). ## 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](https://goodglyph.com/en/services/automations-integrations) are the cheap road. If it shows that nothing on the market fits, then we talk about a [custom app](https://goodglyph.com/en/services/custom-apps), 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. ## 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. ## FAQ ### How do I know whether I need an app or just an automation? If you can name the person moving data from one system to another and the hours they lose, you need integrations. If a surface is missing altogether, a place where a client or your team sees and does something that currently exists nowhere, you need an app. ### What does fixing the process cost, compared with building? Writing the process down is free if you do it internally. Configuring what you already own runs to a few hundred euros. Integrations go from hundreds to a few thousand. An app built from scratch starts at a few thousand and climbs quickly, so the difference is usually an order of magnitude. ### We already have a system nobody uses. What do we do? First find out why. In most cases it is missing configuration and missing training rather than missing features. A new system bought on top of the same reason ends up the same way. ### My process changes often. Is that a reason not to build? For now, yes. A process that has not changed in six months is stable enough to be worth encoding. One that changes monthly needs to settle first, otherwise you pay for every move. ### Can you tell us which situation we are in? Yes, and it is the conversation we start with anyway. Come with the process written out in steps, even imperfectly, and we will tell you whether it is a build, an integration or a configuration, before any quote. ### If you recommend an off-the-shelf product, do you still earn anything? Not from that product, and that is fine. A project built on top of an unclear process ends badly for both sides, so the smaller recommendation serves us too, not only you. ## Related - Related service: [Service](https://goodglyph.com/en/services/automatizari-integrari) - [Client Portal or Simple CRM: Which One You Actually Need](https://goodglyph.com/en/blog/client-portal-or-simple-crm) - [What an MVP Is (and What It Is Not, Though It Gets Sold That Way)](https://goodglyph.com/en/blog/what-is-an-mvp) - [How Long Does It Take to Build an App? Real Stages and Timelines](https://goodglyph.com/en/blog/how-long-app-development-takes)