5 mistakes when commissioning an app that cost companies the most

The most money on an app project is lost not on the code, but on bad decisions made before it's written: too broad a scope, choosing by price, and the lack of a decision-maker on the company's side. Below are the five mistakes that cost the most - and how to avoid each one.

1. A scope that hasn't been sliced up

Trying to build everything at once lengthens the time to first feedback and raises the cost before you know whether the idea works at all. A typical scenario: a company wants "a complete system right away" with a sales module, a warehouse, invoicing, reports and a mobile app for sales reps. The estimate grows, the first working screens appear only after many weeks, and along the way it turns out that half the assumptions were wrong. The result is always similar: money and time spent before anyone in the company actually clicked into a finished solution.

The larger the unbroken scope, the harder it is to change anything without reworking the whole thing. The cure: start with an MVP that solves one problem, for one group of users, and add the rest based on what actually works. → MVP in 6 weeks

2. Choosing by the lowest price

The cheapest offer usually assumes a narrower scope or greater risk (no continuity, no process). The problem is that at the inquiry stage this is hard to see - two offers with a twofold difference in price often describe a completely different scope of work, a different level of testing and different accountability after launch. The client compares amounts as if they covered the same thing, while in practice they choose an offer in which "finishing up" and fixes will be paid for later.

The second common consequence of the cheapest choice is a lack of continuity: a one-person contractor disappears or stops responding, and the system is left with no one who knows it. The cure: compare scopes and credibility, not just amounts - and ask outright what happens after deployment. → How much does a custom app cost · Software house or freelancer?

3. No project owner on the client side

Without a decision-maker in the company, the project gets stuck - the contractor waits for decisions that no one makes. In practice it looks like this: the question "should the invoice be generated automatically or manually" goes to three people, each says something different, and the decision is made after two weeks. Every such delay costs money, because the team either waits, or guesses and then reworks.

The project owner doesn't need to understand technology. They need to understand the company's process and have the mandate to settle disputed issues. The cure: appoint one person who decides and is accountable, and make sure they have real time for it, not "on the side of other duties."

4. Skipping maintenance

The "ship it and we're done" mindset ends with a system that stops working after six months because no one kept an eye on it. An app is not a piece of furniture - it's living software that requires updating libraries, renewing certificates, monitoring and reacting to changes in integrations (e.g. a change in the API of a payment provider or an invoicing system). Skipping this at the commissioning stage means the first serious outage catches the company without a plan and without a budget.

The consequences can be painful: the store stops accepting payments on a Friday night, and there's no one to contact. The cure: plan maintenance from the start - establish who reacts, in what time and for what money, even before you sign the contract for the development itself. → Maintaining an app after deployment

5. Building everything at once instead of iteratively

Guesswork instead of data. You build features "because someone might want them," and after launch it turns out that users need something else. A classic example: an extensive reports module in which, after deployment, no one opens half the report sets, while the simplest file export that employees asked for ended up at the bottom of the list. The work went into things that didn't change anything in everyday use.

Iteration is not a sign of lacking a plan - it's a way to correct the plan before things get expensive. The cure: develop based on real usage, not assumptions, and treat every deployed piece as a source of information about what to build next.

Bonus: consider whether you need custom development at all. Sometimes an off-the-shelf system is enough, and building your own solution is the most expensive mistake of them all. → Custom app or off-the-shelf system?

Additional trap: no access to the code and accounts

A common mistake, rarely caught in time, is handing over full control of your own system. If the code repository, the hosting account, the domain and database access are set up in the name of the contractor or their company, you formally don't own what you paid for. As long as the cooperation goes well, the problem isn't felt. Trouble appears when you change suppliers or when the contractor stops responding - you're left with an app that can't be taken over, moved or developed by anyone else.

The cure: state in the contract that the code, production accounts and data belong to you, and that after the cooperation ends they will be handed over together with the documentation needed for further development. While you're at it, it's worth establishing where and how user data is stored. → Data security in an app

Additional trap: not thinking about integrations

An app rarely lives in a vacuum. Most often it has to talk to what the company already has: an invoicing system, a payment gateway, email, a warehouse or a CRM. Omitting integrations from the inquiry and treating them as something to "add later" can blow up the budget and the schedule, because integration with an external system is often more work than the feature it serves. The result: a finished module that doesn't close the process, because data still has to be rewritten by hand.

The cure: list all the systems the new app must connect with before the estimate - along with whether they have a ready API. This is one of the first things that genuinely affects cost and time. → Integrations: email, invoices, payments

Additional trap: no acceptance criteria

"Done" is a word every side understands differently. Without acceptance criteria agreed in advance, the project ends in a dispute: the contractor believes they delivered the scope, and the client - that it doesn't work the way it was supposed to. As a result, the end of the project drags on for weeks, and the relationship sours exactly when trust is needed most, that is at the production launch.

The cure: set measurable acceptance criteria for each stage - specific scenarios the app must handle and how to verify them. The earlier the better, because it's hard to argue about something that was written down before work began.

Checklist before sending the inquiry

Before you send the inquiry to a contractor, check whether you can answer these points. If not - it doesn't mean you can't start the conversation, but it's worth naming these gaps outright, because they will come up later anyway.

• What specific problem the app is to solve and who will use it.
• Which processes are most important to start with, and what can wait for later stages.
• Which systems the new solution must integrate with.
• Whether it's an MVP or the target system right away - and what the approximate budget and deadline are.
• Who on the company's side is the project owner and makes decisions.
• What maintenance will look like and who is responsible for it after launch.
• Who will own the code, accounts and data after the cooperation ends.
• How you'll know that a stage has been accepted and is done.

A well-prepared inquiry shortens the conversations and produces comparable offers. If you want to go through this process step by step, start with the guide. → Custom app: a guide

FAQ

What is the most common mistake when commissioning an app? A scope that hasn't been sliced up - trying to build everything at once. This lengthens the time to first feedback and raises the cost before you even know whether the idea works.

Is it worth choosing the cheapest offer? Not automatically. The cheapest offer often assumes a narrower scope or greater risk. Compare scopes and the contractor's credibility, not just the amount.

What does it mean to have a project owner on the client side? It is a person in the company who decides and is accountable for the project on the client's side. Without them, decisions get stuck and the project loses momentum regardless of the contractor's quality.

Why is the lack of access to the code and accounts a problem? If the code, repository and hosting accounts are in the contractor's name, in practice you don't own your own system. When you change suppliers or the contractor disappears, you're left with an app that can't be taken over or developed further. Secure this in the contract from day one.

Do I have to know exactly what I want before I send an inquiry? You don't need a finished specification, but you do need to be able to describe the problem and who will use the solution and how. The contractor will help shape the scope, but without a clear problem the estimate will be guesswork and the project will drift along the way.

What should a request for proposal for an app contain? A short description of the problem, who will use the system, the most important processes to handle, integrations, an approximate budget and deadline, and whether it's an MVP or the target system. That's enough to get comparable and sensible offers.

---