The top 3 challenges of in house app development

Building an app in-house feels like the logical choice. You own the vision, you control the timeline, and nobody knows the product better than the people who conceived it. And yet, across the lifestyle brands we work with, the pattern that plays out is almost always the same: a product that was supposed to launch in four months is still in development a year later, the budget has doubled, and the team is exhausted and fractured. The app either never reaches the store or it launches in a state that serves no one particularly well.

In-house development fails not because the team lacks skill, but because scope, vision, and coordination are never properly governed.

The causes are rarely technical. They are structural and behavioural, rooted in how decisions get made, who holds the authority to make them, and what happens when conviction in a vision outpaces the evidence from real users. Three challenges account for the majority of what goes wrong, and understanding them clearly is the first step to building something that actually ships.

Each of these challenges compounds the others. Scope creep drains the budget that coordination problems then consume entirely, while founder conviction makes it nearly impossible to course-correct at any stage. We have seen all three playing out simultaneously, and the result is always the same: a product that never fulfils its early promise.

Challenge 1: Scope That Grows Every Time You Try to Shrink It

Scope creep is the most predictable failure mode in app development, and it is also the one teams are least equipped to resist. The problem is rarely that people are reckless. It is that each individual addition feels reasonable in isolation. Of course the app needs a notification system. Of course it needs reporting. Of course it needs this other thing that nobody mentioned during planning but now seems obviously essential.

On a sports club app we worked on, what the founders described as a focused product gradually became something that tried to do everything. The original timeline was three to four months to market. The app never launched. After twelve to fourteen months of development, the budget had nearly doubled, and the product still was not ready for the store. Every single one of those outcomes was forecast and communicated clearly by the development team, and none of the warnings changed the direction the project was heading.

The damage is not just financial. A product that keeps expanding never reaches the state of being done. Teams lose confidence. Stakeholders start questioning decisions made six months earlier. The development process stalls under the weight of its own ambition, and the original purpose of the product gets buried under layers of features that were never part of the core case for building it at all.

Set a written feature freeze date before development begins. Every new idea raised after that date goes into a backlog for version two, with no exceptions made during the initial build.

Why Refinement Sessions Become Expansion Sessions

There is a specific mechanism through which scope creep does most of its damage, and it happens inside the process that is supposed to prevent it. Refinement sessions are designed to narrow a feature down, to clarify its edges and agree on exactly what it will and will not do. In practice, on in-house projects, they routinely achieve the opposite.

On the sports club app, we watched this pattern repeat through the entire project. Every time we went into a refinement session to narrow a feature down, new requirements would surface. The response from stakeholders was consistent: of course it needs to do this, of course it needs to do that. These were things that had never been discussed before, but they were presented as obviously implied, as if the omission was somehow on us. And the stakeholders were adamant that these additions belonged in the product specification.

The dynamic is understandable. Getting into the detail of a feature naturally prompts people to think harder about how it will work in practice, and thinking harder surfaces things that were glossed over during early planning. But without a disciplined process that separates discovery from scope definition, every refinement session becomes an invitation to expand. The product that enters the room is always smaller than the one that leaves it.

According to a survey by Geneca, up to 77% of software project respondents report not knowing how to tell when their project is done. That uncertainty is the direct result of scope that is never fixed.

The Stakeholder Dynamic That Makes Scope Hard to Hold

Understanding why refinement sessions expand requires looking at who is in the room and what their relationship to the product actually is. On most in-house projects, the people with decision-making authority are also the people most personally invested in the product's success. That combination makes scope almost impossible to hold.

On the sports club app, both co-founders were deeply embedded in the world the app was built for. The app was their business, not a marketing tool sitting alongside it, which meant their professional identity and their product were the same thing. Both founders were strong-willed and consistently pushed to add more features, each convinced their additions were obvious and already implied by the original vision. The friction between those two positions, and between the founders and the development team, created a project environment where saying no to any single feature felt like an attack on the product itself.

This is a structural problem. When the people who have the authority to approve scope changes are also the ones proposing them, there is no independent governance. Nobody in the room has the standing to hold the line, because the line is being moved by the people who own it.

When the people approving scope changes are also the ones proposing them, there is no independent governance.

The fix is to separate those roles before the project starts. Someone needs to hold the product specification as a fixed document and have the authority to defer additions, regardless of who is making them. Without that separation, every stakeholder with access to the refinement process is also a vector for scope growth.

Appoint one person as the scope guardian before development starts. Their role is to hold the original product specification and formally log any new requirements as version two items, with the sign-off process bypassing anyone who proposed the change.

Challenge 2: Founder Vision Overriding User Evidence

The second challenge is more subtle than scope creep and considerably harder to address, because it involves the founder's relationship with their own conviction. Building a product requires genuine belief in what you are making. But that same belief, when it becomes resistant to contradicting evidence, produces what we describe as a vanity product: something shaped entirely by the founder's preferences rather than by what real users actually need.

We have seen this pattern across two separate projects, a fitness and wellness app and a grassroots football product, where founders with strong personal conviction in their vision consistently set aside data emerging from research, focus groups, and surveys. The product continued to evolve in the direction the founder wanted it to go, regardless of what the evidence suggested about user behaviour. In both cases, we flagged the trajectory early. In both cases, the project exhausted its budget in design and build without ever reaching a fully live product.

The early warning signs are consistent across both projects. An excessive drive to perfect the product before launch. Rolling back sign-offs to request further changes after decisions have already been made. A pattern of prolonged decision-making that prevents the team from moving forward. Each of these behaviours looks, in the moment, like diligence. Collectively, they are a signal that the product is being built for the founder rather than the user.

The Warning Signs of a Vanity Product

One of the clearest illustrations of this dynamic came from a pre-launch founder in the football industry who approached our team with a colour-coded spreadsheet mapping out competitor products. The plan was to merge several specialised apps into a single all-in-one product. The founder was visibly excited and clearly proud of the work they had done to get to this point.

When we began asking questions about prospective users, the conversation shifted. Why would someone choose an all-in-one product over the specialised tools they already use? Would consolidating features risk making each one less useful than the dedicated app it was replacing? The founder had not worked through those questions, and the moment we raised them, the energy in the room changed. They became deflated. But asking those questions is the job. Building on a premise that has not been stress-tested against real user behaviour is how vanity products get built.

The warning signs of a vanity product tend to cluster in a recognisable way.

• Research findings are acknowledged but do not change decisions
• The product is described in terms of what the founder wants it to feel like rather than what users need it to do
• Launch keeps being pushed back in favour of adding one more feature
• User testing feedback is reinterpreted to confirm the original direction rather than challenge it

None of these individually is fatal. Together, they describe a project that is building toward the founder's satisfaction rather than toward a product that users will actually return to.

What Happens When the Budget Runs Out Before Launch

The practical consequence of a vanity product is predictable, even if it is rarely acknowledged until it is too late. Design and build are expensive. If the decision-making process is slow, if scope keeps shifting, and if the product keeps being refined toward an ideal that nobody has validated with users, the budget gets consumed before the product ships.

On both the fitness and wellness app and the grassroots football product, this is precisely what happened. The entire budget was spent in design and build. Neither project reached a fully live version. The founders had invested real time and money into products that never launched, not because the development team was incapable, but because the process of building had been driven by internal conviction rather than iterative validation.

On the sports club app, we warned the client early and directly that the budget would spiral and that they risked running out of funding before launching anything. The warnings were noted. The client continued adding features. The project ended with the entire budget exhausted, nothing published to the app store, and the agency and client parting ways. The outcome was not a surprise to anyone on the development side. It was exactly what had been forecast.

According to figures from Agile Soft Labs, 2026, founders typically underestimate MVP development time by a factor of two to three, based on their experience across more than 200 MVPs. The gap between expectation and reality is wide enough on its own. When scope keeps growing and decisions keep getting revisited, that gap becomes unbridgeable.

Build a version-one product that does three things well rather than ten things adequately. Set the launch date before features are finalised, and let the date determine what goes in, not the other way around.

Challenge 3: Coordination Failures Across Distributed Teams

The third challenge operates at the process level rather than the decision-making level, and it affects projects that have no scope problem and no vanity product issue at all. Coordination failure is what happens when the people responsible for design, development, and delivery are not working from the same shared understanding of what they are building and how it needs to behave.

On a baby monitor project we worked on, the team was spread across a consortium of groups in multiple countries, covering the UK and elsewhere in Europe. Keeping everyone aligned on capabilities and requirements across those distributed teams was genuinely difficult. The challenge was compounded further by the fact that we had no access to the physical hardware or test devices. To test our work properly, we built our own internal version of the baby monitor and ran all testing against that prototype before handing everything over to the hardware team. It was a workable solution, but it added friction and distance between the work we produced and the environment it would eventually run in.

Distributed development creates coordination costs that are easy to underestimate at the outset. When design and development happen in different teams, often in different time zones, the assumptions each side makes about what the other is producing start to diverge. That divergence only becomes visible at the point of handoff, which is exactly when there is the least time and budget to address it.

When Design, Development, and Handoff Are Not Aligned

The handoff between design and development is where coordination failures become most expensive. A design that looks clear to the designer contains dozens of implicit decisions that a developer has to interpret without guidance. When the gap between those interpretations is not closed early, it generates rework, and rework at the development stage is much more costly than rework at the design stage.

We experienced a version of this on a wellness genetics product we were brought in to work on. The product had been built functionally but without the emotional layer the brand needed, so our brief was to improve how users engaged with what was a very data-heavy experience. When we handed our designs to the development team, a third-party designer in between produced something that looked appropriately premium. But the development team struggled to understand how to implement it on top of their existing codebase, and the gap between the visual design and what the code could support required considerable back-and-forth to resolve.

Adding an interaction layer on top of existing code is possible, but it requires very careful management of the relationship between design intent and technical constraints. The more intermediaries sit between the original design thinking and the team implementing it, the more distance opens up between what was intended and what gets built.

According to figures from Zeplin, 66% of designers spend four to eight hours each week explaining layouts and interactions due to handoff inefficiencies, while 65% of developers spend the same amount of time interpreting designs for the same reason. That is a significant volume of time spent on alignment that should have happened earlier in the process.

How Access and Ownership Structures Create Friction at Launch

Coordination failures do not only affect the work itself. They also shape the mechanics of how a product gets deployed, and the problems that creates are often invisible until the moment they matter most.

On a social football product we worked on, the client held the App Store Connect Account Holder role, since the account was registered in their name. We were given admin access to the majority of the account and set up three internal testing groups. One for our team, one for the client, and one external QA beta test group for the client's testers. That structure gave us control over which builds went to which groups at each stage of the deployment process.

As the project moved toward launch, the client began bypassing that structure. They started manually sending uploaded builds to whichever group they wanted, without going through the agreed process. Because the account was theirs and they had full access, we had limited ability to prevent it. It caused problems. The testing structure we had built to manage quality and sequence broke down, and we lost visibility into what was being tested by whom and when.

Ownership of platform accounts carries real decision-making power during deployment. Who controls the account, what access levels are agreed on, and what the process is for moving builds through testing to release all need to be defined clearly before the project starts, not negotiated at the moment of launch.

Why These Are Strategic Problems, Not Resourcing Ones

There is a tempting conclusion to draw from each of these three challenges: if only the team had been bigger, or better, or more experienced, the outcomes would have been different. The evidence does not support that. The sports club app was not under-resourced. The wellness genetics product had a capable development team. The baby monitor project involved multiple skilled groups across several countries. The problems were not about who was in the room. They were about how the project was governed.

Scope creep is a governance problem. It requires fixed specifications, clear authority over what belongs in the product, and a process that separates discovery from definition. Founder vision overriding user evidence is a decision-making problem. It requires someone with standing to hold the evidence against the conviction, and a clear agreement that research findings carry weight in the room. Coordination failure is a structural problem. It requires aligned processes for handoff, agreed access structures, and testing environments that reflect the real product as closely as possible.

The distinction matters because resourcing problems have resourcing solutions. You hire more people, or better ones. Strategic problems require structural changes to how the project is run. Adding a fifth developer to a project with no scope discipline does not reduce scope. It produces more of the same product, faster, at greater cost.

Each challenge has a strategic answer, and each answer requires the kind of structural thinking that needs to happen before the first line of code is written, not after the first crisis has arrived.

Conclusion

In-house app development fails in patterns. The same three challenges appear across product categories and team sizes, from a wellness genetics brand to a grassroots football platform to a sports club app that spent twelve to fourteen months in development and never reached the store. The variables change, but the structure of the problem is consistent.

Scope that lacks a guardian will grow. A founder's vision, when it is never tested against contradicting evidence, will shape a product that serves the founder rather than the user. And teams that are not aligned on handoff, access, and deployment will find that coordination costs eat the time and budget that would otherwise have got the product to launch.

These are not problems that a bigger team or a faster build cycle resolves. They are strategic problems that require structural answers, and those answers need to be in place before the project starts. The product specifications, the decision-making authority, the handoff process, the testing environment, the deployment access structure. All of it.

If any of this maps onto a project you are running or planning, it is worth talking through before the pattern repeats. Let's talk about your app development challenges.

Frequently Asked Questions