← All articles

What Does an App Cost? Why That's the Wrong Question

Published · by theCoders · 15 min read
What an app costs — why the price question comes too early and what really matters before development

Almost every conversation with a new entrepreneur starts the same way. “Hi, I have an idea. How much would an app cost me?”

It’s a legitimate question. The person has a budget, has an idea, and wants a number so they know whether they can start. The problem is that this question is like asking “how much does a house cost?” The correct answer is always another question: it depends how many rooms, on what land, with what foundation, for whom, and — most importantly — have you checked whether anyone actually wants to live there?

After years of delivered projects, we’ve reached an uncomfortable conclusion: the development price is rarely the reason a digital product fails. What kills products is everything that happens around the code. And there’s solid data that says so.

1. What the data says: capital is the cause of death, not the disease

In a report published in March 2026, CB Insights analyzed 431 venture-funded startups that shut down since 2023. The most frequently cited cause — “we ran out of money” — appears in 70% of cases. But their analysts are very explicit: that’s the cause of death, not the disease.

The real reasons, the ones that explain why the money ran out, look different:

CauseFrequency
Weak product-market fit43%
Bad timing / market conditions29%
Unsustainable unit economics19%

The companies in the analysis had together raised $17.5 billion before they died. Median per company: $11 million. So it wasn’t money that was missing. What was missing was the fit between product and market.

And one more detail that should give any founder pause: two-thirds of the product-market-fit failures were early-stage companies that never found a market — yet 20 of them had already reached a Series B round. You can raise millions and still build something nobody is asking for.

Marc Andreessen put it most clearly back in 2007, in an essay that has since become required reading: “The only thing that matters is getting to product/market fit.” Everything else — stack, design, team, budget — is a subordinate variable.

2. “How much does it cost” assumes the product is already defined

When someone asks for a price for “an app,” they implicitly assume they know what needs to be built. In 90% of cases, they don’t. And that’s not a criticism — it’s normal. The idea lives in the founder’s head as intuition, not as a specification.

The difference between an €8,000 quote and a €60,000 quote for “the same app” isn’t the vendor’s greed. It’s the fact that the two of them understood two completely different products from the same three-paragraph brief.

A case study from our own experience: a client came in with “a simple marketplace, like OLX, but for my niche.” After two discovery sessions, “simple” meant: identity verification, payment escrow, a dispute system, two-way ratings, chat, push notifications, and a moderation panel. In other words, not a 6-week project but a 6-month one. Nobody was lying. The word “simple” just doesn’t mean the same thing on either side of the table.

That’s why the first deliverable in a serious project isn’t code. It’s a document.

If you do want concrete budget ranges, we published a 2026 mobile app pricing guide with tiers by complexity.

3. Market research: the cheapest line in the budget and the first one cut

The typical cost structure of an app project looks roughly like this: discovery and research 10–15%, UI/UX design 20–25%, development 40–55%, QA and testing 15–20%.

Guess what gets cut first when the budget is tight? Exactly: the first 10–15%. The part that decides whether the other 85% makes any sense at all.

Discovery doesn’t mean a PowerPoint with “the global market for X is worth Y billion.” It means concrete, cheap things:

  • 15–20 interviews with people from the target audience, where you don’t pitch your idea but ask how they solve the problem today. Steve Blank calls this “get out of the building” — no answer lives in the office.
  • A map of the real competition, including the improvised solutions: Excel, WhatsApp, a notebook. Your strongest competitor isn’t another app, it’s the habit.
  • A willingness-to-pay test, before line one of code. A landing page, a waitlist, a pre-order.

The cost of this stage? A few thousand euros. The cost avoided? See the table in section 1.

It’s worth recalling here the “faster horses” myth attributed to Henry Ford — constantly used as an excuse not to talk to users. The quote isn’t documented anywhere in Ford’s writings. And even if it were real, it says something other than what’s claimed: people won’t describe the solution to you, but they’ll describe the problem perfectly. Your job is to listen to the problem, not to ask for the solution.

Market research is the cheapest part of the project — and often the first one cut from the budget

4. UX/UI doesn’t mean “make it look pretty”

The most expensive confusion in the industry: design treated as a cosmetic layer applied at the end.

McKinsey tracked 300 public companies over five years and built a design-maturity index. The companies in the top quartile saw revenue growth 32 percentage points higher and total returns to shareholders 56 percentage points higher than the average in their industry.

The Forrester figure also circulates — every dollar invested in UX supposedly returns $100, i.e. a 9,900% ROI. We use it cautiously, because it’s old research aggressively extrapolated in marketing. The direction, however, is confirmed by real user behavior, and there the numbers are brutal.

Global retention benchmarks for mobile apps show roughly 26% on Day 1, 13% on Day 7, and 7% on Day 30. Other analyses put the Day 30 median as low as 4%, and about a quarter of users abandon the app after a single use.

Translate that into money: if you pay €2 per install and lose 93% of users within 30 days, the real cost per active user isn’t €2, it’s nearly €30. You don’t have a marketing problem. You have an onboarding problem — that is, a UX problem.

Steve Jobs summed it up in five words, and the sentence remains the best filter for any conversation about design: “Design is how it works.”

5. Every extra feature is a liability, not an asset

This is where budgets die most quietly.

Pendo analyzed usage data from 615 software-product accounts and found a constant pattern: roughly 80% of features are rarely or never used, while 12% of them generate 80% of daily usage volume. By extrapolation, publicly listed software companies had invested up to $29.5 billion in features nobody touches.

The older Standish Group figure — 45% of features never used, 19% rarely used, so 64% — is from 2002 and has been criticized methodologically. But, significantly, no later large-scale study has produced a substantially different result.

What does that mean for the quote you receive? That out of your list of 40 features, roughly 8 matter. And if the vendor prices all 40 without asking a single question about prioritization, they haven’t made you an offer — they’ve made you an invoice.

Reid Hoffman, LinkedIn co-founder, has a well-known rule: if you’re not slightly embarrassed by the first version of your product, you launched too late. It’s not an invitation to sloppiness. It’s an invitation to let the market decide what deserves to be built next.

Every feature you build is also a liability — around 80% of features are rarely or never used

6. Testing with real people: the only moment you learn the truth

The “100x rule” circulates heavily in the industry: a defect found in the design phase costs 1, in implementation ~6.5, in testing ~15, and in production up to 100.

The classic source — the IBM Systems Sciences Institute — has been publicly challenged: researcher Laurent Bossavit showed the original data is either nonexistent or predates the 1980s. We mention this precisely because a well-documented article isn’t one that cites impressively, but one that also says when a figure is fragile.

The order of magnitude, however, remains supported by independent sources. The Consortium for Information & Software Quality estimates the cost of poor-quality software in the US alone at $2.41 trillion a year, of which $260 billion comes from failed projects.

What works concretely, at the scale of an SME:

  1. A clickable prototype before development. Five real users, one hour each, concrete tasks. You’ll uncover 70–80% of the major flow problems.
  2. A closed beta with 20–30 people from the target audience, not friends and family. Friends tell you it’s pretty. The target audience tells you they don’t understand the button.
  3. Analytics from day one in production. You can’t fix what you don’t measure.

Our rule: if you haven’t talked to at least 10 users between design and launch, you haven’t built a product. You’ve built an expensive hypothesis.

7. Distribution: the part almost nobody puts in the budget

There are over 4.1 million apps across Google Play and the App Store combined, and discoverability has become technical problem number one. Adjust’s analyses estimated, at one point, that about 90% of App Store apps are “zombies” — organically invisible, findable only if you search their exact name.

Translation: if your distribution plan is “we’ll put it in the store,” your distribution plan doesn’t exist.

A realistic budget allocates at least as much to distribution as to development in the first year. Not necessarily in paid ads — it can be content, SEO, partnerships, community, niche press. But it has to be a line in the budget, with an owner and measurable goals.

The Y Combinator motto — “make something people want” — works in both directions: first build what people want, then make sure those people find out it exists.

8. Communication: the invisible variable that moves cost the most

From our experience with 15+ developers and dozens of projects, the best predictor of a project delivered on time isn’t the stack, the seniors, or the methodology. It’s how fast the client responds.

A project with feedback within 24 hours goes twice as fast as an identical one with feedback in 10 days — because the team doesn’t just wait, it loses context and has to rebuild it.

Three things that reduce cost more than any rate negotiation:

  • A single decision-maker. Three stakeholders with divergent opinions don’t produce a better product, they produce rewrites.
  • A demo every two weeks, with the product running, not with screenshots.
  • A publicly prioritized backlog, where “not now” is an acceptable and visible answer.

9. Launch is not the finish line

The industry standard for maintenance is 15–25% of the initial cost, per year — servers, OS updates, security patches, bugs, adaptations to API changes. And in the first year after launch, costs can reach as much as 50% of the initial investment, because that’s where the iterations based on real feedback concentrate.

A €40,000 app is not a €40,000 cost. It’s a €40,000 cost plus €6,000–10,000 a year, indefinitely. Whoever doesn’t tell you this in the first conversation either doesn’t know, or doesn’t want you to know.

10. Technical Consulting Isn’t About Having the Answers. It’s About Asking the Right Questions.

After everything we’ve covered, one conclusion becomes difficult to ignore.

Most software projects don’t fail because developers can’t write code. They don’t fail because the wrong framework was chosen. And they rarely fail because the technology itself was the wrong choice.

Most projects begin to fail much earlier. They fail the moment important decisions are made based on assumptions that were never tested.

That’s where technical consulting creates the most value. Not by deciding whether an idea is good or bad, but by turning an idea into a plan that can be executed with significantly less uncertainty.

Experienced consultants don’t begin with technology. They don’t start by discussing React, Flutter, Laravel, Kubernetes, or cloud infrastructure. They start with questions. Because the quality of a software project is often determined long before the first line of code is written.

The questions that save the most money

Every successful discovery process revolves around a surprisingly small number of questions. Questions such as:

  • What problem are we actually solving?
  • Who experiences this problem, and how often?
  • How do people solve it today?
  • Why would they switch to a new solution?
  • Which feature delivers the product’s core value?
  • What can we remove without reducing that value?
  • How will we measure success after launch?
  • Which assumptions can we validate before investing in development?

None of these questions produce visible progress. They don’t generate mockups. They don’t create mobile apps. They don’t impress investors during a demo.

What they do is far more valuable. They prevent expensive mistakes before those mistakes become software.

The cheapest change is the one you never have to make

There is a simple principle that applies to nearly every software project: the later a decision changes, the more expensive that change becomes.

Change an idea during a workshop, and the cost is almost zero. Change the same idea after two months of development, and now you’re redesigning interfaces, rewriting code, retesting functionality, and delaying delivery. Change it after launch, and now you’re paying not only for engineering work, but also for customer confusion, support requests, lost trust, and missed opportunities.

This is why the most successful software projects aren’t necessarily the ones that produce the most code. They’re the ones that avoid building the wrong things in the first place.

Great development teams don’t automatically say “yes”

One of the most valuable things a client can hear is surprisingly simple: “We don’t think this feature should be built — at least not yet.” Or sometimes: “We don’t think this is the real problem.”

That may sound counterintuitive. After all, isn’t a development company supposed to build whatever the client requests? Not exactly. A team that accepts every requirement without challenging it isn’t providing consulting. It’s providing implementation.

Real consulting begins the moment difficult questions enter the conversation. Why is this feature necessary? Who benefits from it? How will success be measured? What evidence supports this decision?

If those answers aren’t clear, development doesn’t eliminate uncertainty. It simply converts uncertainty into code.

The role of a modern software partner

Ten years ago, the biggest competitive advantage of a software agency was the ability to build complex applications. Today, AI has dramatically reduced the time required to write code.

That changes where value is created. Today, competitive advantage isn’t simply about building faster. It’s about making better decisions before development begins.

Technology can accelerate implementation. It cannot decide what is worth implementing. That responsibility still belongs to people — and it has never been more valuable.

Technical consulting isn't about having the answers — it's about asking the right questions before development begins

Conclusion

This article began with a question almost every founder eventually asks: “How much does it cost to build an app?”

By now, the answer should look very different. Development cost is only one part of the investment. Sometimes it isn’t even the most important part.

The most expensive mistakes usually happen before development begins:

  • when products are built around assumptions instead of evidence;
  • when features are added before problems are understood;
  • when user research is skipped;
  • when design is treated as decoration instead of problem solving;
  • or when products are launched without a realistic strategy for reaching customers.

Technical consulting doesn’t eliminate uncertainty. No methodology can. But it can dramatically reduce the number of expensive decisions made without evidence. And in software development, that is one of the highest-return investments any company can make.

So perhaps the real question isn’t “How much does it cost to build an app?” It’s this: “What do we need to know today to make tomorrow’s investment worthwhile?”

Because successful software isn’t defined by how quickly code is written. It’s defined by how well the right decisions are made before that code exists.

Key takeaway: software development is an investment, not a purchase. The best investments don’t begin with programming — they begin with understanding the problem, validating assumptions, and asking the right questions.

Sources