How Do I Choose Which Boss Makes App Decisions?

About 70% of app projects get stuck in what I call decision paralysis, where different people in an organisation think they should be making calls about features, design, or technical direction. This creates a sort of bottleneck that can add months to your timeline, and I've watched this same pattern play out across healthcare apps, fintech platforms, and e-commerce projects over the past ten years of building apps at Glance.

The confusion usually starts in the first couple of weeks when someone from marketing wants the app to look one way, the technical team says that won't work with the backend systems, and the person holding the budget questions whether any of this matches what customers need. Everyone means well... but without a clear structure for who decides what, you end up with compromise solutions that make nobody happy and don't solve the actual problem your app was meant to address.

Decision-making authority needs to be crystal clear before you write a single line of code, not when you're halfway through development and two department heads are arguing about button placement

The answer isn't just picking one boss to rule everything (that creates its own problems) but instead setting up a proper system where different people have authority over different parts of the project based on what they actually know about and what they're responsible for. I've seen this work across projects from a £40k MVP through to multi-million pound enterprise apps, and the structure stays pretty much the same regardless of budget or team size.

Who Actually Owns the App Vision

The app vision needs one person who owns it, and this person needs to be high enough in your organisation that they can make decisions about budget, timelines, and whether the app even continues to exist if things go sideways. I'm talking about someone at director level or above in most companies, someone who has a direct line to the board or senior leadership team.

This isn't the person who decides which shade of blue your buttons should be. That's not what vision ownership means. They're responsible for answering questions like why does this app exist, what business problem does it solve, and what does success look like in twelve months time. When I worked on a healthcare booking app for a private clinic group, the vision owner was their operations director because she understood both the patient experience and the business model behind their appointment system.

The vision owner should be meeting with the project team every two weeks at minimum, not just showing up when there's a crisis or at the final demo before launch. They need to stay connected to what's happening because the vision will shift slightly as you learn more about what users need and what's technically possible within your budget.

I guess the biggest mistake I see is companies assigning vision ownership to someone who doesn't have the authority to make real decisions, so every choice has to go up another level for approval. That adds weeks to everything and the person nominally in charge becomes a messenger rather than a decision maker.

Technical Authority vs Business Authority

You need to split decision-making into two distinct tracks because the person who knows whether your app should integrate with Salesforce or HubSpot probably isn't the same person who knows which payment gateway will give you the lowest transaction fees for your customer demographic. This division stops you from having business people making technical calls they don't understand and technical people making business choices that don't match your commercial reality.

Your technical authority should be either your lead developer or technical director, someone who's actually worked on mobile apps before and understands the difference between what's possible, what's sensible, and what's going to cause you problems down the line. They make calls about technology stack, architecture decisions, API integrations, security implementations, and anything that touches code or infrastructure.

Write down which types of decisions belong to technical authority and which belong to business authority in a shared document that everyone can access. This saves hours of back and forth when someone asks who decides about push notification frequency or whether to use biometric authentication.

Business authority sits with whoever owns the commercial outcomes of the app... this might be a product manager, marketing director, or the vision owner themselves if it's a smaller organisation. They decide on features based on user needs, pricing models, go-to-market strategy, and anything that affects revenue or user acquisition costs. The business authority looks at whether a feature is worth building based on what it'll do for your bottom line, whilst the technical authority looks at whether it's worth building based on maintenance costs, technical debt, and system stability.

These two people need to talk to each other regularly (I'd say weekly during active development) because the best decisions happen when you combine business sense with technical reality. A feature might make perfect commercial sense but cost three times what you thought to maintain, or a technical approach might save development time but create user experience problems that hurt retention.

Building Your Decision-Making Framework

A decision framework is just a written document that says who can say yes to what, and I've found the simplest version works better than trying to map out every possible scenario. You want something that fits on two pages maximum that people can refer to when they're not sure who should be making a call.

Start With Decision Categories

Break your project into categories like user experience, technical implementation, commercial terms, marketing and launch, legal and compliance, and budget and resources. Under each category, list the person who has final say and the person who needs to be consulted before decisions get made. For a fintech app I worked on, legal and compliance decisions had to go through their head of legal (obviously) but the technical authority needed to be consulted because compliance often meant technical changes to how we stored and processed data.

The framework should explain what happens when the decision affects multiple categories... if you're building a feature that's going to cost an extra twenty grand but marketing thinks it'll double your conversion rate, who breaks the tie between technical authority saying it's not worth the maintenance burden and business authority saying the revenue justifies it. Usually this escalates to your vision owner, but you want that written down so people aren't arguing about process when they should be discussing the actual decision.

Set Decision Timelines

Nobody should sit on a decision for weeks whilst the development team waits around burning through budget. Your framework needs to specify how long each authority has to make their call before it automatically escalates upward or defaults to a predetermined answer. I typically suggest two working days for minor decisions, five working days for medium-sized ones, and ten working days for anything that'll change scope or budget by more than 10%. If someone can't decide in that timeframe, they probably don't have enough information and need to loop in whoever does.

The Three-Tier Approval System That Works

Most decisions in app development can be handled at three levels, and the trick is making sure the right level handles each type of decision so you're not wasting senior people's time on minor stuff or leaving junior team members to make calls they're not equipped for.

Tier one covers day-to-day development decisions that don't change scope, budget, or timeline by any meaningful amount. This includes things like exact wording of error messages, minor UI adjustments within the agreed design system, bug fix priorities for non-critical issues, and technical implementation details that users never see. Your development team leads should handle these without needing approval from anyone else, otherwise you create a bottleneck where people are waiting for permission to do their jobs.

The goal is to push decisions down to the lowest competent level, not pull everything up to the highest authority

Tier two handles decisions that affect specific features or could shift your timeline by a few days or your budget by a few thousand pounds. This might include adding a small feature that wasn't in the original scope, changing how a feature works based on user testing feedback, or choosing between two technical approaches that have different trade-offs. Your technical and business authorities should handle tier two decisions between them, bringing in the vision owner only if they can't reach agreement.

Tier three is for anything that changes the fundamental nature of the app, shifts launch dates by weeks rather than days, adds or removes major features, or affects budget by more than about 10%. This absolutely needs your vision owner involved, and depending on the size of the change might need board approval or sign-off from whoever controls the overall budget. I worked on an e-commerce app where halfway through development the client wanted to add a full social commerce layer with user-generated content and community features... that was a tier three decision because it basically doubled the scope and pushed the launch back by four months.

When Stakeholders Disagree on Direction

Disagreements happen on every project, and the question isn't how to avoid them but how to resolve them quickly without damaging relationships or making rubbish decisions just to keep the peace. The worst approach is trying to find a middle ground that satisfies everyone, because you usually end up with a watered-down solution that doesn't really work for anyone.

The first step when stakeholders disagree is making sure they're actually disagreeing about the same thing. I've sat in meetings where two people argued for twenty minutes before realising one was talking about the MVP launch version and the other was talking about features for version two... they weren't in conflict at all, just discussing different timeframes. Get everyone to write down exactly what they think should happen and why before you try to resolve anything.

Use Data to Break Stalemates

When opinions clash, look for data that can inform the decision rather than just going with whoever shouts loudest or has the fanciest job title. Can you run a quick user survey or show prototypes to your target audience? Is there analytics from similar features on your website or competitors' apps? I've watched plenty of arguments dissolve when actual users weigh in and everyone realises their assumptions were wrong.

• Give each stakeholder five minutes to present their case without interruption, focusing on business or user outcomes rather than personal preferences
• List the risks and benefits of each approach on a shared screen where everyone can see them
• Check if there's a smaller test you can run to gather real-world data before committing fully to either direction
• Set a deadline for the decision and agree who has the final call if you can't reach consensus by then
• Document whatever gets decided and the reasoning behind it so you can refer back if the topic comes up again

Sometimes disagreements reveal that you've given overlapping authority to multiple people, which means you need to go back and clarify your decision framework. If your marketing director and product manager both think they should have final say on user onboarding flow, that's a structural problem not a personality clash.

Executive Sponsors and Their Real Role

An executive sponsor isn't the same as your vision owner, though sometimes they're the same person in smaller organisations. The sponsor is typically someone at C-level or on the board who's championing the project internally, securing budget, and removing organisational roadblocks that the project team can't shift themselves.

They shouldn't be involved in daily or even weekly decisions about the app... their job is to show up at key milestone reviews, make sure the project stays aligned with broader company strategy, and step in when there's a conflict that can't be resolved at lower levels. I think of them like an insurance policy that you hope you don't need to use very often, but when you do need them they have the authority to actually fix problems.

Schedule a 30-minute check-in with your executive sponsor every four to six weeks, not just when there's a crisis. This keeps them informed enough to support the project effectively without dragging them into details they don't need to worry about.

The sponsor's real value shows up when you need resources that weren't in the original plan, when another department is blocking access to data or systems you need, or when market conditions change and someone needs to decide whether to pause, pivot, or push forward with the app. On a retail app project, our executive sponsor got us access to the company's loyalty programme data after three weeks of the CRM team saying no... that's the kind of organisational weight that makes sponsors worth having.

What Sponsors Shouldn't Do

Bad sponsors either disappear completely until launch day or try to micromanage design decisions and feature details they're too far removed from users and technology to properly judge. Your sponsor shouldn't be the one deciding colour schemes, debating button layouts, or questioning technical architecture choices unless there's a really good reason they have relevant expertise.

Documentation That Prevents Scope Creep

Every app project I've worked on that stayed on budget and timeline had one thing in common... really clear documentation about what was in scope and what wasn't, with a defined process for how anything new gets evaluated and approved. The documentation doesn't need to be fancy (a shared Google Doc works fine) but it needs to exist and everyone needs to actually use it.

Your decision log should record every meaningful choice made during the project, who made it, when, and the reasoning behind it. This sounds tedious but takes maybe five minutes after each decision meeting and saves you hours later when someone questions why you built something a particular way or wants to revisit a choice that's already been made and implemented. The log also helps new team members get up to speed if someone leaves or you bring in contractors partway through development.

The Change Request Process

Scope creep happens when people can add features or changes without any formal process, so things just accumulate until you're building something twice as complex as you planned. Your documentation needs to define how changes get requested, who evaluates them, and what information is needed before anyone can approve them.

A change request should include what specifically needs to change, why this change matters to users or the business, what it'll cost in time and money to implement, what the impact is on launch timeline, and what you could remove or defer to make room for this new thing if the budget is fixed. That last point is the key one... most people want to add features without taking anything away, which is how you end up six months late and eighty grand over budget.

I typically recommend that anything adding more than a week to the timeline or five grand to the budget needs sign-off from both the vision owner and whoever controls the budget, with a clear note in the project plan about what moved to accommodate this change. Smaller additions can be approved by technical and business authorities together, but still need to be documented so everyone knows what's been added since the original scope was agreed. This is particularly important when considering whether to expand features or create separate products as your app grows in complexity.

Conclusion

Getting decision-making authority right early in your app project saves you from months of arguments, rework, and compromise solutions that don't solve anyone's problems properly. The structure matters more than the specific people you assign to each role... you need clear lines between who owns the vision, who has technical authority, who has business authority, and who sponsors the project at executive level, with documented processes for how decisions get made and disagreements get resolved.

Start by writing down your decision framework before you write any code or finalise any designs, and treat it as a working document that you can refine as you learn what works for your specific team and organisation. The goal is letting people make decisions at the right level without either creating bottlenecks or leaving big choices to people who don't have enough context or authority to make them properly.

If you're setting up an app project and need help working out the right governance structure for your organisation, or you're stuck in a project where unclear authority is causing delays and conflicts, get in touch and we can talk through what's worked across different types of projects and team sizes.

Frequently Asked Questions