--- title: What Happens After My App Is Built? description: App maintenance after launch costs more than most founders expect. Here is what platform updates, pricing and post-launch planning actually involve. image: https://weareaffective.com/hubfs/learning-centre-images/what-happens-after-my-app-is-built.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-happens-after-my-app-is-built#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What Happens After My App Is Built? Table of Contents Most of the money questions founders bring us land before a line of code exists. What does the build cost, how long will it take, when can we launch. The question that decides whether the product lives or dies is app maintenance after launch, and it usually gets asked about eighteen months too late, when the budget has gone and the app has started to creep towards unusable. > The day your app goes live is the day the real spending starts, and most plans stop there. Here's the position an app is in on day one. It sits in a store owned by Apple or Google, who can remove it. It runs on operating systems that change every year, and those changes break working code. It takes money through a payment platform with its own rules about who holds funds and for how long. It depends on other people's services, and those services change their terms without asking you. So this is [what the months and years after a launch actually look like](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need). Review queues, maintenance budgets, platform updates, release cycles, pricing decisions and the people who handle all of it. We've drawn on projects we've run, including ones that didn't go the way the client hoped. ## The First Thirty Days: Getting Through Review and Out of the Door A client came to us with a currency exchange app, and it never reached a single user. The build was finished. The compliance work was done. Apple rejected it anyway, and each time we resolved the objection they'd stated, a fresh objection appeared in its place. The client spent real money on legal counsel to satisfy the stated requirements. Apple then raised the possibility that the product could be used for money laundering and criminal activity. We capped transactions at €150, which should have settled that concern completely, and Apple rejected it again. As Simon put it, "it was clear that there was something else going on that Apple just didn't want to allow this on the store for whatever reason". The client ran out of budget and abandoned the product. Apple Pay and other payment services launched shortly afterwards. We believe the rejections were tied to that. #### Why the first thirty days need their own budget There's no effective route to challenge a decision like that. So the practical lesson we take into every project with any regulatory edge to it is that review is a phase with its own cost, its own timeline and its own risk of total failure. Budget for it separately, and don't commit marketing spend to a launch date that a reviewer controls. ## What App Maintenance After Launch Actually Costs Founders tend to picture maintenance as the occasional bug fix. The reality is a standing annual cost that starts high and settles into something permanent. [Stormotion](https://stormotion.io/blog/app-maintenance-cost/) puts first-year maintenance at up to 50% of the original development cost, dropping to roughly 15 to 25% in the years after that. Those numbers match the shape of what we see, where the first year carries all the things nobody anticipated and later years carry the steady work. #### What app maintenance after launch covers | What you keep paying for | What drives it | Does it ease off? | | --- | --- | --- | | Hosting and data | Number of users and volume of content | No, it grows with usage | | Third-party services | Their pricing tiers and term changes | No, and it's outside your control | | OS compatibility work | Annual iOS and Android releases | No, it's an annual fixture | | Bug fixes and crash work | Real users doing unexpected things | Yes, after the first year | | Store policy compliance | [Apple and Google rule changes](https://weareaffective.com/learning-centre/what-happens-if-apple-or-google-changes-their-push-notification-rules) | No, but it's usually small | | Product changes | What your data tells you | That's your choice | The first three lines never go to zero. A founder who's modelled a build cost and nothing else is modelling about half the first two years. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Why Platform Updates Force You to Rebuild Work You Already Paid For Apple ships a new version of iOS every autumn and Google does the same with Android. Each release changes permissions, deprecates components, alters how notifications behave or adjusts what the store will accept. Code that worked perfectly in September stops working in October, and you pay somebody to fix it. This isn't a rare event. [Statista](https://www.statista.com/statistics/272698/global-market-share-held-by-mobile-operating-systems-since-2009/) puts the share of applications needing additional compatibility work within three months of a mobile OS update at over 60%. > Every year, Apple and Google change things that break working code, and you pay for the repair. The work is invisible to users, which is what makes it hard to fund. Nobody sees a new feature. The app simply carries on working, and a founder who's just spent money on that can reasonably ask what they bought. One thing we do at the architecture stage is reduce how much of the product sits exposed to other people's decisions. On the toll management platform we built, we deliberately avoided real-time integrations with toll operators, which meant the product had fewer moving parts outside our control from the day it launched. Fewer dependencies, less annual repair work. ## Planning Your Update Cycle: What Ships, When, and Why An [app that stops receiving updates gets removed](https://weareaffective.com/learning-centre/why-80-percent-of-business-apps-fail-and-how-to-be-in-the-20-percent). [Pixalate, 2025](https://www.pixalate.com/blog/february-2025-delisted-mobile-apps-report) found that 78% of delisted apps were classed as abandoned because they hadn't been updated in over two years. So the question isn't whether you ship after launch, it's what you ship and in what order. The staged approach we took on the toll management platform is a good model for this. We made the case that a brand-new, unproven product would struggle to negotiate API access with established toll operators, so the first release used preloaded credit and corporate accounts instead. API integrations went onto the roadmap for later, once the platform had credibility to negotiate with. The client accepted that, and it meant version one shipped without waiting on anyone else's goodwill. A workable cycle looks like this. 1. Stability work first, so crashes and compatibility fixes always jump the queue. 2. Small improvements to the flows your data shows people struggling with. 3. [The features you deferred from version one](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), in the order the product now needs them. 4. Integrations and partnerships, once you've got the usage numbers to open those conversations. Keep a running list of everything you cut from version one, with the reason you cut it. Six months in, the reasons have usually changed and that list becomes your roadmap. ## Deciding What to Change Next: Data, Research, and the Concierge App Pivot [Analytics tell you where people stop](https://weareaffective.com/learning-centre/how-to-diagnose-which-stage-of-the-emotional-arc-your-reorder-flow-is-losing-cus). Research tells you why. You need both, and the second one is where the bigger product decisions come from. On a concierge app project for a property developer, the client wanted two things at once, a full-service building management utility and a tool that built community between residents. We recognised those goals were pulling against each other, so we ran focus groups with social housing tenants to understand what actually creates a sense of community. What we found was that it comes from familiarity. People knowing each other's names, jobs, children, hobbies and pets. That changed the product. It went from something close to a building directory to a social feed at the heart of the experience, where residents could post, ask neighbours for help and follow updates from the concierge team and local charities. The mundane building tasks went into the app, and the design pushed people towards face-to-face conversations rather than replacing them. We saw the same pattern on a genetics product. The client wanted full medical detail as the default. Our user testing supported the opposite structure, plain language and real-world analogies first, with the scientific depth there to explore for anyone who wanted it. That produced higher comprehension and lower anxiety in testing, so that's what shipped. ## When Your Product Depends on Someone Else's System On the toll management platform, we found during development that there was no coherent or consistent API across toll providers. Each one operated differently. Some took cash, some took card, and fees varied by vehicle axle count or sat at a flat rate. Direct integration wasn't viable at any sensible cost. So we designed around it. We set up corporate accounts with each toll provider, registered customer vehicle plates against those accounts, and had customers preload credit onto the platform, with funds deducted after the fact. That removed the need for real-time integration completely and let the product launch without waiting for any individual operator to cooperate. Part of that project was educating the client on how APIs work in the first place, and on what it really takes to establish a formal data-sharing relationship with an incumbent who has no reason to help you. #### Dependencies are a maintenance cost Every external service you rely on is a line in your future maintenance budget. They change pricing. They deprecate endpoints. They decide your category is no longer one they serve. The currency exchange project is the extreme version of this, where the dependency was Apple itself. List every external service your app touches and write down what happens to the product if each one disappears tomorrow. Anything without an answer is a risk you haven't priced. ## Payment Infrastructure Is Never Finished On a property maintenance platform we worked on, money had to sit somewhere between the landlord paying and the tradesperson getting paid. The platform connected landlords, tenants and tradespeople, with job specs uploaded, progress geotagged and payment released on completion. Third-party escrow services were the obvious route, and we investigated them, but they created legal complications for the client. We went with Stripe's delayed payout system instead, treating the product as a marketplace app through Stripe Connect. That gave us the escrow-like behaviour we wanted while Stripe carried the legal and financial regulation requirements. Getting there took work. Stripe Connect account types impose different constraints, and Express accounts require near-immediate payouts, which didn't suit the use case at all. > The more control you take over payments, the more complex the flows become and the more you maintain yourself. Finding that balance was the whole job. We needed exactly the payment behaviour the product demanded without customising so far that we lost the benefits of Stripe's default handling. Every piece of custom payment logic you add is something you own forever, and payment providers update their APIs and their compliance requirements regularly. Payment work is a permanent line in app maintenance after launch, rather than a one-off build task. ## Pricing Is a Post-Launch Decision, Not a Launch One We worked on a music backing track app where the market was niche and split between professional musicians and casual users. Our recommendation was a low price point to drive mass adoption and build revenue through volume. Simon's advice to the client was direct. "Nobody will actually pay what you think it should be worth and instead we should be looking at this as purely as a volume product." The client disagreed. They'd come from the music world and knew precisely what the recordings had cost to produce, and they wanted to recoup that within weeks. In Simon's words, "that's just not how things work". They pushed for a high price that reflected production value, and sales were low, as we'd expected. The anchor to production cost stopped them even considering a lower entry price or a volume strategy. Had they tested a cheaper introductory price, our assessment is that both downloads and total revenue would have been higher. Price is one of the easiest things to change after launch and one of the most informative. You can run a different price for a fortnight and read the result. Treat your launch price as the first test rather than a decision you're stuck with. ## Who Keeps the App Running, and What Their Week Looks Like The people who built your app are rarely the people who should keep it running week to week, and founders are often surprised by how varied that ongoing work is. It's rarely a developer sitting writing new features. A typical week covers things like this. - Reading crash reports and working out which ones affect enough users to fix now. - Checking third-party services for deprecation notices and pricing changes. - Reviewing analytics for drop-offs that appeared after the last release. - Responding to store reviews, which are both support and marketing. - Testing the next release against the latest OS beta. - Updating content, prices or copy that the business has changed. Crashes matter more than most founders assume. [Alphabin](https://www.alphabin.co/blog/mobile-app-testing-uninstall-rates) reports that [62% of users uninstall apps after hitting crashes](https://weareaffective.com/learning-centre/what-are-the-different-types-of-mobile-app), freezes or errors. A bug you leave for a month is churn you don't get back. For a small product, this is a few days a month from someone who knows the codebase. For anything with payments, user-generated content or a live operational dependency, it's closer to an ongoing part-time role. Either way, it's a named person with budgeted time rather than a favour. ## Building the Post-Launch Plan Before You Sign the Contract The currency exchange client ran out of money fighting a review process they hadn't budgeted for. That's the clearest argument we can make for settling the post-launch plan before the build starts rather than after it. Here's what we'd want agreed before signing anything. 1. A maintenance budget for year one and year two, written as a number rather than an intention. 2. Who owns the code, the accounts, the store listings and the service logins. 3. What the response time is for a crash affecting all users, and what that costs. 4. Which external services the product depends on, and what the fallback is for each. 5. A date for the first post-launch review of the data, usually six to eight weeks in. 6. How much runway sits behind the launch, so pricing and feature decisions can be tested rather than guessed. None of this slows a build down. It changes what gets built, because [a team planning for two years of ownership](https://weareaffective.com/app-planning-strategy) makes different architecture decisions than a team planning for a launch date. The toll platform shipped the way it did precisely because we were thinking about what the product had to survive after release. Ask any agency what their last three clients spent on maintenance in year one. A straight answer tells you they've stayed involved after launch. ## Conclusion An app is a business with running costs, not a project with an end date. The store can reject you, the operating system changes under you every year, the services you depend on set their own terms, and your users tell you things about your product that no amount of pre-launch planning predicted. The projects we've seen go well are the ones where that was understood going in. The concierge app changed shape completely because focus groups told us something the brief had wrong, and there was budget and appetite to act on it. The toll platform launched without API access because we planned a route that didn't need it yet. The music app underperformed because the price was fixed to a cost base rather than treated as something to test. So plan the first two years, not the first release. Budget for maintenance as a standing cost. Keep enough runway to change your mind about pricing and features once you've got real data. Decide who's responsible for the app on a Tuesday morning in eighteen months' time. If you're building something now, or you've got a live app that's started to drift, [let's talk about your post-launch plan](https://weareaffective.com/get-started). ## Frequently Asked Questions How much should I budget for app maintenance after launch? Expect first-year maintenance to run at up to 50% of your original development cost, settling to roughly 15 to 25% a year after that. The first year absorbs everything nobody anticipated, while later years cover the steady, predictable work. Why does app store review need its own budget? Review is a distinct phase with its own cost, timeline and genuine risk of total failure, as a reviewer can reject your app repeatedly for reasons that shift each time. Treat it as a separate line in the budget rather than assuming it is a formality at the end of the build. Can an app be rejected even if it is fully compliant? Yes. We had a currency exchange client who completed the compliance work, paid for legal counsel and capped transactions at €150, and Apple still rejected the app each time with a fresh objection. There is no effective route to challenge a decision like that, and the client eventually ran out of budget and abandoned the product. Should I book marketing spend against a planned launch date? Not before you are through review. The launch date is effectively controlled by a reviewer at Apple or Google, so committing marketing money to a fixed date puts that spend at risk if approval is delayed or refused. Which ongoing costs never really go away? Hosting and data grow with your user numbers and content volume, third-party service costs move with their pricing tiers and changing terms, and operating system compatibility work returns every year with each new iOS and Android release. Bug fixing is the one area that does tend to ease off over time. Why do operating system updates matter so much? Apple and Google release new versions of their operating systems every year, and those changes routinely break code that was working perfectly well. Compatibility work is therefore an annual fixture rather than an occasional surprise. What risks come from depending on third-party services? Your app relies on services owned by other companies, and they can change their pricing or terms without consulting you. That cost sits outside your control, so it is worth knowing which dependencies you have and what a change to each would mean for your running costs. What is the biggest mistake founders make about post-launch costs? They treat launch as the finish line and picture maintenance as the occasional bug fix, so the money questions all get asked before any code is written. The spending genuinely begins on the day the app goes live, and the question usually gets raised around eighteen months too late, once the budget has gone. ## Related Articles [![What Are the Main Reasons Mobile Apps Fail?](https://weareaffective.com/hubfs/learning-centre-images/what-are-the-main-reasons-mobile-apps-fail.webp)](https://weareaffective.com/learning-centre/what-are-the-main-reasons-mobile-apps-fail) ### [What Are the Main Reasons Mobile Apps Fail?](https://weareaffective.com/learning-centre/what-are-the-main-reasons-mobile-apps-fail) On a sports club app project we [worked on, the client reached the end of the budget](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) with nothing on... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Do I Need to Develop an App?](https://weareaffective.com/hubfs/learning-centre-images/what-do-i-need-to-develop-an-app.webp)](https://weareaffective.com/learning-centre/what-do-i-need-to-develop-an-app) ### [What Do I Need to Develop an App?](https://weareaffective.com/learning-centre/what-do-i-need-to-develop-an-app) A client came to us with a well funded plan for a sports club app. It would handle finances, games,... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How Much to Budget for App Marketing](https://weareaffective.com/hubfs/learning-centre-images/how-much-to-budget-for-app-marketing.webp)](https://weareaffective.com/learning-centre/how-much-to-budget-for-app-marketing) ### [How Much to Budget for App Marketing](https://weareaffective.com/learning-centre/how-much-to-budget-for-app-marketing) The question usually reaches us late. The build has been quoted, a launch date already sits in... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.