Why Don't Executives Understand How Long Apps Take?

Why does a finance director think your app should take six weeks when you know it needs six months? This question comes up in probably half the discovery meetings we run at Glance, and the frustration goes both ways... executives feel like developers are being deliberately slow or overcautious, whilst developers feel like their expertise is being questioned or dismissed. The gap between these two perspectives has cost businesses millions in failed projects, strained relationships, and apps that launch half-finished because someone decided the timeline mattered more than the reality of what needed building. I've been building apps for a decade now, and this disconnect hasn't got better as the industry has matured, it's actually got worse because executives see more apps in the marketplace and assume the process must have become easier or faster.

The timeline for building an app is sort of like asking how long it takes to build a house without saying whether you want a garden shed or a five-bedroom property with underfloor heating

The problem isn't that executives are being unreasonable or that developers are being precious about their craft. It's that these two groups are looking at completely different things when they think about what an app project involves. An executive sees the finished product, maybe they've used a competitor's app or downloaded something similar, and they think about how long it might take to replicate what they can see on screen. A developer sees the infrastructure behind those screens, the API integrations that need building, the security requirements that need implementing, the edge cases that need handling, and the testing that needs doing before anyone should trust this thing with real user data.

The Gap Between Building and Expecting

I've sat in boardrooms where a managing director sketched out an app concept on a whiteboard and asked if we could have it ready in six weeks. The idea was sound (a booking system for their salon chain with payment processing, staff scheduling, and customer profiles), but the timeline was off by about four months. The gap here wasn't about intelligence or business acumen, it was about visibility into what actually happens when you build software for mobile devices.

The problem starts with familiarity. Executives use apps every day, they tap buttons and swipe screens, and everything feels instantaneous. When you interact with Instagram or Uber, you're not seeing the months of work that went into making that double-tap animation feel natural, or the backend infrastructure that processes millions of requests per second. You're just experiencing the end result, which makes the whole thing look simple.

This creates a disconnect between perception and reality. Building an app means writing code for two different operating systems (iOS and Android), designing interfaces that work on dozens of screen sizes, integrating with third-party services that have their own quirks and limitations, testing on real devices (not just simulators), and deploying through app store review processes that can reject your submission for reasons you didn't anticipate. None of this is visible to someone who's only ever been a user. Understanding the discovery phase can help bridge this gap by revealing the complexity that exists beneath the surface.

What Looks Simple But Isn't

• A login screen requires password encryption, database setup, email verification, password reset flows, and comprehensive security testing
• Push notifications need server infrastructure, user permission handling, message scheduling, and platform-specific configuration
• Payment processing involves PCI compliance, fraud detection, refund systems, and integration with payment gateways
• Photo uploads require image compression, storage solutions, bandwidth management, and content moderation

The other issue is comparison. When an executive sees how quickly their website was updated with a new banner image, they assume app changes work the same way. But apps aren't websites, changes need to be compiled, tested across devices, submitted to Apple and Google, reviewed (which takes days), and then users need to actually download the update. A simple text change that would take five minutes on a website can take a week to reach all your app users.

What Executives See vs What Developers Know

A CEO looks at Instagram and sees a simple photo sharing app with filters, and the maths seems straightforward in their mind... if Instagram can do it, surely a similar app takes maybe three months to build. What they don't see is the army of engineers working on server infrastructure, content delivery networks, spam detection systems, and the dozens of micro-services running behind that deceptively simple interface. The disconnect happens because executives see features whilst developers see systems, and those are two completely different ways of understanding the same product.

When a board member asks for "just a login system", they're thinking of two text boxes and a button. They're picturing five minutes of work. The development team is thinking about password encryption standards, account recovery flows, two-factor authentication, session management, API security tokens, database indexing, rate limiting to prevent attacks, and compliance with data protection regulations. That single "simple" feature touches at least eight different parts of your application architecture. For businesses developing enterprise solutions, the security requirements become even more complex, adding layers of authentication and data protection measures.

What Different Roles Actually See

Take your executive team through a working development environment and show them the actual code files, server dashboards, and testing procedures for a single feature... the sheer volume of technical work becomes immediately visible when they see the fifteen different files that need changing just to add a button to the interface.

Where Time Actually Goes in App Development

The actual coding part of building an app takes up maybe thirty percent of the total project time, which surprises most people when they first hear it. I had a client once who assumed their eight week timeline meant eight weeks of a developer typing away at a keyboard, when really that developer was only actively writing new code for about twelve days total across that entire period.

Most of the time disappears into activities that happen around the code itself. Testing eats up weeks. Not just the obvious stuff like making sure buttons work, but checking how the app behaves when your phone loses signal halfway through a transaction, or what happens when someone receives a call whilst filling out a form, or how it performs on a three year old Android device with half the memory of newer phones. We had a banking app fail its security audit because we hadn't tested what happened when users rapidly tapped the login button seventeen times in a row, which created duplicate session tokens that confused the backend system. Proper testing and debugging processes are essential for catching these edge cases before they reach production.

The Real Time Breakdown

Here's where those eight weeks actually go on a typical mid-sized project:

• Requirements gathering and planning (one week)
• Design iterations and approvals (one and a half weeks)
• Core development work (two and a half weeks)
• Testing and bug fixes (two weeks)
• Client reviews and requested changes (one week)

The back and forth communication alone can add days to any timeline, especially when decisions need approval from multiple people who aren't always available at the same time.

The Hidden Costs Nobody Talks About

Look, when you build an app there are expenses that never appear in the original budget breakdown, and they sneak up on every single project without fail. The App Store charges £79 per year for a developer account, Google Play takes £20 as a one-off fee, but those are just the obvious bits that everyone remembers to budget for when they start planning their brilliant new application.

What catches people off guard is the server infrastructure that scales with user growth (something that can jump from £40 a month to £800 within weeks if your app takes off), third-party API costs that seem reasonable at 10,000 calls but become eye-watering at 500,000 calls, push notification services that charge per message sent, analytics platforms that lock their best features behind paywalls, and SSL certificates that need renewing annually. We had a client who built a fitness tracking app and forgot to account for the mapping API costs... when their user base hit 5,000 active members the monthly bill went from £120 to £2,400 overnight because each workout session was pinging the location service dozens of times. For specific integrations like financial services, the costs can be even more substantial than most teams anticipate.

The real shock comes three months after launch when the bills start arriving for services you thought were included in the development cost

Then there's the Apple Developer Enterprise Program at £250 annually if you need internal distribution, beta testing platforms that charge per tester, crash reporting tools, A/B testing services, customer support infrastructure, and the time your team spends responding to user reviews and managing app store listings. These recurring costs add up to thousands per year before you've even started marketing the thing, and nobody warns you about them in those initial planning meetings.

Why Every App Project Feels Like It Takes Forever

The waiting becomes unbearable once a project moves past the design phase, because stakeholders can see the finished screens and buttons... they assume the hard part is done. I've watched this happen dozens of times now. Someone opens Figma or Sketch, scrolls through perfectly polished mockups, and genuinely believes we're 80% finished when we haven't written a single line of working code yet.

The design shows a simple login screen with email, password and a button. Straightforward enough. What the design doesn't show is the password reset flow that needs building, the email verification system that requires backend infrastructure, the secure token management that protects user data, the biometric authentication that iOS and Android handle completely differently, the error states for weak internet connections, the accessibility features for screen readers, and the analytics tracking that measures how many people actually complete the signup process. That one screen balloons into three weeks of development work across multiple team members.

Building features always takes longer than looking at them, which creates this strange disconnect where everyone feels like the project is dragging. The invisible work... that's what consumes the calendar, and no amount of showing people our task management boards seems to close that perception gap.

Teaching Stakeholders to Think Like Developers

The best way I've found to bridge this gap is to involve stakeholders in a sort of mini-development workshop (nothing fancy, just an hour on a Tuesday afternoon usually does it) where they actually see how code gets written and tested. When a CFO watches you spend twenty minutes debugging why a button doesn't align properly on one specific Android device, something clicks in their understanding of where time goes... they start to see the work rather than just the end result.

I tend to walk people through what I call the dependency chain, which is really just showing them how one thing has to happen before another can start. If you need user authentication before you can build the payment system, and you need the payment system before you can test the subscription flow, then trying to rush any single piece affects everything downstream. It sounds obvious when you say it like that, but most stakeholders haven't thought about apps in terms of building blocks that stack on top of each other. Understanding mobile application architecture helps explain why these dependencies exist and why certain features must be built in a specific sequence.

Key Concepts to Share With Your Team

• Testing takes roughly the same amount of time as building the feature itself
• Changes late in the process cost about five times more than changes made early
• Every platform (iOS and Android) needs separate attention for quality assurance
• Dependencies between features mean parallel work has limits

The thing that really helps is using their own business as an example. I guess you could say it's about translation... if they run a restaurant, I explain that building an app is more like opening a new location than printing new menus, with all the complexity that involves in terms of planning and coordination.

Record a short video showing your actual development environment and the steps needed to make a simple change, then share it with stakeholders before your next planning meeting.

How to Set Expectations That Actually Stick

The most effective approach I've found involves showing stakeholders a timeline breakdown in their Wednesday morning review meeting, then asking them to choose which features matter most for the first release. This simple exercise changes everything because it forces real decisions rather than vague wishes about wanting everything at once.

Three Documents That Keep Everyone Aligned

I send three documents after the initial planning session, each one serving a different purpose. The first is a simple feature list ranked by complexity with hours attached to each item, which gives executives something concrete to discuss when they need to adjust scope. The second document shows the critical path, those dependencies where one piece of work must finish before another can start, and this tends to prevent the dreaded "can't we just add this small thing" requests halfway through. The third is a milestone schedule with buffer time built in but clearly labelled as buffer rather than padding, which stops people from assuming we have hidden slack to absorb their last-minute ideas. When working with larger organisations, formalising these expectations in a development agreement helps protect both parties from scope creep.

Making Time Visual

Numbers on a spreadsheet rarely stick in people's minds, but a wall chart showing each week of development with sticky notes for different features tends to make the timeline feel real. When someone suggests adding a new feature, I walk them to that chart and ask them to physically place it somewhere in the sequence, then we discuss what needs to move or get removed to make space. That physical act of moving pieces around creates understanding faster than any conversation about abstract timeframes ever could.

Building Trust Through Honest Timelines

The best relationships I've built with clients started with a conversation nobody wanted to have, where I told them their launch date wasn't going to work and explained exactly why. The only problem was sitting through that initial silence while they processed what I'd just said. Trust doesn't come from promising what people want to hear... it comes from being straight about what's actually possible and then delivering on that promise every single time.

I keep a spreadsheet (kind of nerdy, I know) that tracks every project timeline I've ever given against what really happened, and the pattern is pretty clear. When I pad estimates by twenty to thirty percent and walk clients through every assumption I'm making, we hit our deadlines about eighty-five percent of the time. When I give optimistic numbers to make people happy, that drops to maybe forty percent. The maths just doesn't lie on this stuff.

Telling someone their app will take six months when you know it needs eight doesn't make you helpful, it makes you unreliable when month seven rolls around and you're still not done

What changed things for me was starting to share my working documents, the actual spreadsheets where I break down features into hours and account for testing cycles and buffer time. Some executives found it boring at first. But then something interesting happened. They started asking better questions about trade-offs and suggesting which features we could move to phase two, because they could see the direct connection between scope and time in a way that made sense to them. For businesses starting to build an audience before their app launches, this transparency helps them plan their marketing timeline more realistically too.

Conclusion

The disconnect between executives and developers when it comes to app timelines is never going to disappear completely, and I've come to accept that after building apps for organisations of all sizes over the years. The people holding the budget live in a world of quarterly reports and board meetings where speed matters above nearly everything else, while developers exist in a reality where a single misplaced bracket can break an entire feature and where proper testing can't be rushed no matter how many times someone asks for it.

What I've learned is that bridging this gap requires constant communication, not just at the start of a project but throughout every single stage of development. When you show stakeholders exactly where their money goes (server costs for a user base that might grow to 50,000 people, security audits that protect sensitive payment data, accessibility testing that ensures everyone can use the app), they start to understand that time isn't being wasted. Apps aren't slow because developers lack motivation. They're complex because modern users expect perfection.

The best relationships I've built with clients have been the ones where we treated timeline conversations as ongoing discussions rather than fixed agreements set in stone at the beginning. Reality changes. Requirements shift. Technical challenges appear that nobody could have predicted during the planning phase, and being honest about those challenges builds more trust than pretending everything is going exactly to plan when it isn't.