--- title: What Happens After My App Is Built? description: Launching an app is just the start. Learn what comes after the build, from app store rules and ongoing costs to platform updates and long-term strategy. 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 The app is built. The designs are signed off, the code is tested, and you have a launch date. It feels like the finish line. Founders and product owners reach this point and exhale, because the hard part is done. Except it is not done. The hard part, in many ways, starts here. What follows a build is a long and often expensive set of decisions that nobody put on the original project plan, and the teams least prepared for them are the ones who treated the build itself as the destination. > The development invoice is settled, and then the costs and constraints that were never discussed start to appear. We have watched this play out across product categories, from property management to music distribution to genetics. The pattern is consistent. The development invoice is settled, the app goes live, and then the costs, constraints, and structural dependencies that were never discussed start to appear. Some are financial. Some are technical. Some are political, in the sense that they depend on decisions made by Apple, Google, or Stripe rather than by you. None of them are hidden. They are just not on the invoice. This article is about what actually happens after an app is built, and [what to plan for before you ever sign a development contract](https://weareaffective.com/learning-centre/what-belongs-in-a-product-strategy-before-you-talk-to-a-development-team). The founders who handle this well are the ones who built those realities into their model before writing a single line of code. ## App Stores Do Not Guarantee You a Place on the Shelf Submitting an app to Apple's App Store or Google Play is not a formality. Both platforms review every submission, and both can reject an app for reasons that are not always transparent or consistent. Apple's review process, in particular, can become a significant obstacle even for apps that meet every stated requirement. On a currency exchange app project we worked on, the client's product was rejected repeatedly despite addressing every compliance point Apple raised. Each time we resolved one objection, a new one appeared. When Apple eventually cited the risk of money laundering and criminal activity, we responded by capping transactions at €150, which should have addressed that concern entirely. The app was rejected again. The client ran out of budget and abandoned the product. It later became clear that this rejection process coincided with the build-up to the launch of Apple Pay. The rejections were not random. They were, in our assessment, strategically motivated. The problem is structural. Apple's review process has no effective appeals mechanism that a small developer can use against iterative rejections. A well-funded incumbent can effectively block a compliant competitor from the market simply by raising successive objections. That project demonstrated something important: compliance with the rules does not guarantee access to the platform. A new product can be technically sound and still never reach users if the review process is used against it. Plan your app store submission timeline with a minimum of four weeks of review buffer, and budget for at least two rounds of revision before expecting approval. ## Ongoing Costs You Will Not See on the Development Invoice The development cost is a single number on a single document. The ongoing cost of running an app is neither single nor fixed, and it tends to surprise founders who did not model it in advance. There are server costs, which scale with usage. There are third-party service fees. There are platform commissions. And then there is maintenance, which is a cost category of its own. Maintenance costs can reach up to 50% of the total development cost during the first year, according to [Stormotion](https://stormotion.io/blog/app-maintenance-cost/). That figure is consistent with what we see across the projects we run. In subsequent years, industry estimates settle at around 15-20% of the original build cost annually, as noted by [Imaginovation](https://imaginovation.net/blog/importance-mobile-app-maintenance-cost/). Neither figure appears on a development invoice, because neither belongs to the build. | Cost category | When it occurs | Typical driver | | --- | --- | --- | | Platform commission | Every transaction | App store takes 15-30% of revenue | | Server and hosting | Monthly | Scales with active users | | Third-party services | Monthly or per-use | Payments, analytics, push notifications | | Maintenance and bug fixes | Ongoing | Platform updates, user-reported issues | | Feature development | Periodic | Market feedback, competitive pressure | App stores typically charge between 15 and 30% on distribution revenue, according to [Topflight Apps](https://topflightapps.com/ideas/app-development-costs/). That is not a minor line item. For any app with meaningful revenue, it is one of the largest costs in the business, and it is set by the platform rather than by you. Founders who model their unit economics without accounting for this tend to find that profitable-looking projections become much tighter once real numbers replace assumptions. ## 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 ## Platform Updates and Why Your App Will Need to Keep Up Apple and Google update their operating systems on a regular cadence, and those updates do not wait for your roadmap. When iOS or Android ships a new version, apps built on older frameworks can break. Features stop working. UI elements render incorrectly. In some cases, apps are removed from the store entirely for failing to meet new technical requirements. Around 97% of apps in both major stores are updated every year, according to [Statista](https://www.statista.com/statistics/1404449/apple-app-store-app-updates-by-frequency/), which suggests that staying current is a near-universal requirement rather than an optional effort. > Platform updates do not wait for your roadmap, and an app that cannot keep up stops being listed. This is not just about bug fixes. Each platform update can change how apps request permissions, display notifications, handle payments, or interact with device hardware. An app that handled camera access cleanly under iOS 16 may need revision under iOS 17. That revision costs time and money, regardless of whether you added any features or changed the product at all. The update itself is the trigger. The practical consequence is that a live app without a maintenance budget is a product with a countdown. At some point, a platform update will require changes, and if there is no budget to make those changes, the app either breaks or disappears from the store. The only way to avoid this is to treat maintenance as a permanent running cost from day one. Align your app's major update cycles with the Apple and Google annual release schedules, so you can plan maintenance spend before platform changes land rather than after. ## Pricing Strategy Does Not End at Launch Pricing a consumer app is one of the decisions founders get most consistently wrong, and it is almost always wrong in the same direction. The price is set too high, too early, based on what the product cost to make rather than what the market will bear. We worked on a music backing track app where this played out directly. The client had invested heavily in producing the recordings and wanted to price the app at a level that would recoup those costs within weeks. We recommended a low price point to drive mass adoption, having identified that the market was niche and spanned both professional musicians and casual users. The client disagreed. As Simon put it directly to them at the time: "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 went with the higher price point. Sales were low, consistent with what we had predicted. The cost-of-production anchor prevented them from even considering a volume strategy, and the result was a product that [never reached its commercial potential](https://weareaffective.com/learning-centre/why-most-business-apps-fail-and-how-your-digital-business-can-avoid-the-same-fat). Consumer app economics work through [volume, retention, and compounding growth over time](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). A lower price that brings ten times the users produces more total revenue than a higher price that repels the casual majority. This is not an insight that applies only at launch. Pricing should be revisited regularly, tested against user behaviour, and adjusted as the product and its audience mature. The launch price is a starting point, not a commitment. If your app serves both casual and professional users, model two pricing scenarios: one at your preferred price point and one at half that, with realistic volume assumptions for each. The revenue difference is usually instructive. ## Payment Infrastructure and the Rules That Govern It If your app handles money, the technical and legal complexity rises significantly. Payment infrastructure is not a feature you configure once and forget. The [rules governing it are set by payment processors](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know), by financial regulators, and by the platforms themselves, and those rules constrain what you can build more than almost anything else. #### Choosing the right payment model On a property maintenance platform project we ran, we needed to hold funds until work was completed before releasing payment to tradespeople. This is essentially an escrow function. We investigated third-party escrow services but found they posed legal complications for the client's specific setup. Instead, we used Stripe Connect with delayed payouts and structured the product as a marketplace app. The platform connected landlords, tenants, and tradespeople: job specs could be uploaded, progress geotagged, and payments released on completion. Stripe handled the regulatory and financial compliance requirements, which meant we achieved the outcome we needed without building custom payment infrastructure from scratch. #### The cost of customisation The integration was not without its complications. Different Stripe Connect account types impose significantly different constraints. Express accounts require near-immediate payouts, which did not suit our use case at all. The more control you need over payment flows, the more complex the integration becomes. As we found on that project, the challenge is finding the balance between achieving the precise payment behaviour you need without over-customising to the point where you lose the protections and reliability that come from Stripe's default payment handling. Every degree of custom behaviour is a degree of additional maintenance and risk. ## When Third Parties Control Your Product's Fate Apps rarely exist in isolation. They depend on third-party APIs, data providers, payment processors, and platform relationships that were not built with your product in mind. When those dependencies change, your product changes with them, whether you planned for it or not. We encountered this directly on a toll management platform project. During development, we discovered there was no coherent or consistent API across toll providers. Each operator worked differently: some accepted cash, some card; fees varied by vehicle axle count or flat rate. Direct integration was not viable. Our solution was to set up corporate accounts with each toll provider, register customer vehicle plates to those accounts, and have customers preload credit onto the platform. This eliminated the need for real-time integration entirely and allowed the product to launch without depending on the cooperation of individual toll operators. We also had to educate the client about the realities of negotiating API access as a new, unproven product. Established toll operators have no incentive to open their systems to a startup. Our advice was to launch under the preloaded credit model and pursue API integrations later, once the platform had built credibility and a user base. The client accepted this staged approach. It was the right call, because a product that cannot launch while waiting for third-party cooperation is a product that may never launch at all. - Audit every third-party dependency before launch - Identify which ones could change their terms, pricing, or API without notice - Build contingency plans for your highest-risk dependencies - Avoid launching a product whose core function depends entirely on a third party you do not have a formal agreement with ## How to Know When Your App Needs to Change An app that launched well will not stay well indefinitely. User expectations shift, competitors improve, and the problems your product was built to solve evolve. The question is not whether the app will need to change, but how you will know when that moment has arrived and what to do about it. On a concierge app project for a property developer, the client came in wanting two things simultaneously: a full-service building management utility and a community-building social tool. We recognised these goals were pulling against each other. A utility product and a social product have different design logics, different success metrics, and different user behaviours. To resolve the tension, we ran focus groups with social housing tenants to understand what actually generates a sense of community. The insight was clear. Community is built on familiarity: people knowing each other's names, interests, families, and pets. Accumulating that shared knowledge is what generates belonging. That meant the product should surface opportunities for those disclosures rather than automate away the interactions that produce them. What started as essentially a building directory and maintenance logger became a [social feed at the heart of the product](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you), with residents posting content, asking neighbours for help, and following updates from the concierge team and local charities. Building management features became a secondary layer rather than the core experience. The signal that the product needed to change came from [direct research with the people it was built to serve](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), not from usage data alone. ## Planning for the Long Game Before You Sign The most effective time to plan for post-launch reality is before the development contract is signed. By the time the app is live, you are responding to problems rather than anticipating them. The founders who navigate this well are the ones who modelled the full picture early, including the costs, constraints, and dependencies that will not appear on any invoice. #### What to settle before development begins As a principle, building a consumer app requires treating it as a long-term investment. Founders who expect to recover development costs within weeks through app revenue are applying the wrong mental model. We saw this directly on the music backing track project: the client's need to recoup production costs immediately prevented them from considering a pricing strategy that would have served the product far better over time. Consumer app revenue is built through volume, retention, and compounding growth. That takes time, and a business model that cannot survive the early period will not reach the period where the returns compound. #### The questions worth asking early Before signing, the following are worth having explicit answers to: 1. What is the annual maintenance budget, and who owns it? 2. How will the product respond to a major platform update? 3. What happens if a key third-party dependency changes its terms? 4. At what point will the pricing strategy be reviewed, and against what data? 5. What is the plan if the app store rejects the submission? None of these questions require a crystal ball. They require the [same rigour that went into the feature list](https://weareaffective.com/learning-centre/4-ways-your-app-development-projects-can-improve-your-companys-customer-service) and the visual design. Products that plan for the long game before launch are the ones that are still running two years after it. ## Conclusion An app is a product you build and then run, maintain, defend, reprice, rebuild, and sometimes fundamentally rethink. The build is one phase of that. Everything that follows is the rest. What we have described across these chapters is not a set of edge cases. The App Store rejection we experienced on the currency exchange project, the pricing misjudgement on the music app, the third-party dependency problem on the toll management platform, the product pivot on the concierge app, these are the kinds of problems that appear on real consumer products with real users and real commercial pressure. They are normal, and the teams that handle them well are the ones that saw them coming. The practical upshot is straightforward. Build your maintenance budget before you build the app. Model your pricing on market demand, not production cost. Know your third-party dependencies before you depend on them. Treat the App Store as a gatekeeping relationship, not a formality. And keep talking to your users, because the product that launched is rarely the product that succeeds. If you are approaching a build and want to [plan for what comes after it](https://weareaffective.com/app-planning-strategy), [let's talk about your product before you commit to it](https://weareaffective.com/get-started). ## Frequently Asked Questions Will my app definitely be approved by the App Store or Google Play once it is built? Approval is not guaranteed, and both platforms can reject submissions for reasons that are not always transparent or consistent. Apple in particular may raise successive objections, which means a technically sound app can still be blocked from reaching users. Plan for a minimum of four weeks of review time and budget for at least two rounds of revision before expecting approval. What ongoing costs should I expect after my app launches? Beyond the development invoice, you will face server costs that scale with usage, third-party service fees, platform commissions, and maintenance expenses. Maintenance alone can reach up to 50% of the total development cost during the first year, which catches many founders off guard. These costs are not hidden, but they are rarely included in the original project plan. Can a larger competitor use the app review process to block my product? Based on real experience, it does appear possible for iterative rejections to function as a competitive barrier, even when every stated compliance point has been addressed. The article describes a currency exchange app that was rejected repeatedly during a period that coincided with the build-up to Apple Pay's launch. There is no effective appeals mechanism available to small developers in these situations. When should I start thinking about post-launch costs and constraints? The article is clear that these realities should be built into your model before a single line of code is written, and certainly before you sign a development contract. Founders who treat the build as the destination are typically the least prepared for what follows. Modelling these costs early gives you a far more accurate picture of what it will actually take to run the product. What kinds of decisions after launch are outside my control? Some of the most significant constraints depend not on you, but on decisions made by Apple, Google, or payment providers such as Stripe. Platform commissions, policy changes, and review outcomes are all determined externally. This structural dependency is something every founder should factor into their planning before committing to a build. Is the launch date really the finish line for a new app? According to the article, the launch date is better understood as a starting point rather than a conclusion. The hard work of managing costs, navigating platform relationships, and iterating on the product begins once the app goes live. Founders who exhale at launch and expect the product to run itself are typically the ones caught out by what comes next. What industries does this post-launch challenge apply to? The article notes that the pattern is consistent across very different product categories, including property management, music distribution, and genetics. The specific costs and constraints vary by sector, but the underlying dynamic is the same regardless of what the app does. No category is exempt from the structural realities that follow a build. What is the most practical thing I can do before signing a development contract? The article recommends building post-launch realities into your business model before development begins, rather than treating them as something to figure out later. This includes modelling ongoing costs, understanding platform dependencies, and planning for app store review timelines. Reading a product strategy guide before engaging a development team is specifically recommended as a starting point. ## Related Articles [![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.