How Much Does It Cost to Keep Your App Complia?
Compliance is one of those costs that feels abstract until it lands on your desk as a bill you did not budget for. A product goes through months of design and build, the launch happens, and then a platform policy update, a regulator's letter, or a legal review surfaces something that was never properly addressed. The work does not stop. It doubles back.
Compliance handled before launch is a design decision. Compliance handled after launch is a crisis response.
The question of what compliance costs is rarely asked clearly before a product is built, because it feels like a question that belongs to lawyers and accountants rather than product teams. But the real answer sits somewhere between those two worlds, and the teams who understand it early make very different decisions to those who discover it late.
What follows is a practical look at where compliance costs come from, what drives them up, and how to plan for them before they become unplanned surprises. We draw on our own work across a range of products and sectors, because the gap between theory and practice is where most budgets get hurt.
Why Compliance Costs More After Launch Than Before It
The most expensive time to discover a compliance gap is after users are already in the product. Retrofitting is slower than building correctly the first time, and it often requires touching parts of the codebase that were not designed to accommodate the change. On the peer-to-peer currency exchange product we worked on, Apple flagged the app as a potential vehicle for money laundering after the core transfer mechanism had already been built. The product allowed unlimited transfers between parties, which tripped AML concerns. We had to go back and add more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties. None of that was budgeted at the start.
This pattern is not unusual. Compliance requirements discovered during build cost more than those addressed in discovery, and requirements discovered post-launch cost significantly more than those discovered during build. The reason is compounding: changing a data model after users have stored data in it is a different problem to designing the right data model at the start. Changing a transfer mechanism after a product has been live is a different problem to designing limits in from day one.
According to GoodFirms, highly regulated industries like healthcare and fintech can see development budgets increase by 30 to 50 percent due to compliance, security, and data protection requirements. That figure applies to products where compliance is treated as a feature of the build, not an afterthought. For products where it is treated as an afterthought, the cost balloons into a separate project, dwarfing any percentage of the original budget.
Start your app project the right way
We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it.
When GDPR and Legal Data Retention Pull in Opposite Directions
One of the more difficult compliance problems we have worked through sits at the intersection of two obligations that appear to contradict each other. GDPR gives users the right to have their data removed. But in certain product categories, legal and safeguarding obligations require data to be kept, even after a user deletes their account.
Two legal obligations pulling in opposite directions require a policy decision, not just a technical one.
On an anonymous messaging app we worked on, this tension was real and required a deliberate decision. If a user sent bullying or abusive messages and then deleted their account, a naive reading of GDPR would wipe that data. But if the police needed to open an investigation, the data would be gone. We implemented a data retention policy of around six months, so that even after account deletion, the underlying messages remained available to the platform's admin team and, if required, to law enforcement.
This was not a technical patch. It was a policy decision with legal grounding, and it had to be documented, communicated in the privacy policy, and built in a way that separated user-facing deletion from back-end retention.
Getting this wrong in either direction carries cost. Delete too much and you are potentially obstructing a legal process. Retain too much and you are in breach of GDPR. The working solution requires legal advice, a retention policy that is proportionate and defensible, and a data architecture that can honour both obligations independently. None of that is free, and none of it is something a development team can resolve without input from someone who understands the regulatory landscape.
Document your data retention policy before you write a line of code. Knowing exactly what data you store, why you store it, and how long you keep it is a legal requirement, and it shapes your database architecture. Trying to retrofit this after launch is significantly more expensive than building to it from the start.
Data Protection: The Recurring Cost of GDPR Compliance
GDPR is an ongoing obligation that generates recurring costs across product management, legal review, and engineering. Every time you add a new data source, a new third-party integration, or a new feature that touches personal data, your compliance posture changes. A privacy impact assessment that was accurate at launch becomes inaccurate when you add a new analytics tool six months later.
The recurring costs of GDPR compliance fall into roughly four areas. Legal review when the product or its data flows change. Engineering time to honour data subject requests, deletion, portability, and access requests all require working mechanisms, not just policy statements. Audit and documentation work to keep records of processing activities current. And incident response capacity for the event of a breach, because GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a breach.
That last point carries real financial weight. According to IBM's 2025 Cost of a Data Breach Report, the average cost of a data breach globally was $4.44 million, rising to $10.22 million for US companies. Even at the lower end of that range, a breach is a business event. Products that treat GDPR as a checkbox exercise rather than an ongoing programme carry that risk into every sprint.
Build your Subject Access Request process before you launch. Users have the right to request all data you hold on them, and you need a working mechanism to respond within 30 days. A manual process is fine at low scale, but it needs to exist from day one.
Platform Policy Compliance: App Store Rules as an Ongoing Overhead
Apple and Google both publish detailed review guidelines, and both update them. An app that passes review at launch can fail a subsequent update review if the platform's position on a particular feature category has shifted. This is one of the most common causes of unplanned engineering work in live products, and it carries a cost that most pre-launch budgets ignore entirely.
The peer-to-peer currency exchange product we worked on illustrates what platform-level compliance review can surface. Apple's review team identified the unlimited transfer mechanism as a potential money laundering risk. The product had been built in good faith, but Apple's guidelines on financial products include provisions that go beyond what a development team might anticipate from reading the general review criteria. The rework required, additional KYC flows, transfer limits, and enhanced security layers, took time and budget that had not been allocated.
Platform compliance is particularly unpredictable in categories Apple and Google treat as sensitive, including financial services, health and wellness, social networking with user-generated content, and anything involving in-app purchases. Products in these categories should budget for platform review as a recurring line item, not a one-off clearance. A rejected update can delay a release by weeks if the fix requires a substantive change rather than a cosmetic one.
| Product category | Common platform concern | Typical rework trigger |
|---|---|---|
| Financial transfers | AML and fraud risk | Transfer limits, KYC flows |
| Social and messaging | User safety and moderation | Reporting tools, content controls |
| Health and wellness | Medical claims, data sensitivity | Disclaimer copy, data handling |
| In-app purchases | Subscription transparency | Cancellation flows, pricing clarity |
AML, KYC, and Sector-Specific Regulation: The Cost of Getting It Wrong Late
Anti-money laundering requirements and Know Your Customer checks are not just a fintech problem. Any product that facilitates the movement of money between parties, even informally, sits inside a regulatory perimeter that most product teams do not consider until a platform flags it or a lawyer reads the spec. The currency exchange product we built was not positioned as a financial services app in the traditional sense. It was designed to help travellers exchange leftover foreign currency at fair rates. But the mechanism, money moving between two private parties without a fixed limit, was enough to trigger Apple's AML concerns.
The cost of retrofitting AML and KYC compliance into a product that was not designed for it is substantially higher than building to those requirements from the start. KYC flows require identity verification, which typically means integrating with a third-party verification provider. Those integrations take time and carry licensing costs. The verification logic itself has to be woven into the onboarding flow in a way that feels proportionate and clear to users, not just technically functional. And the limits placed on transfers have to be defensible, set too low and the product stops being useful, set too high and you are back in front of a regulator.
Sector-specific regulation compounds this further. A product operating in property, insurance, gambling, or healthcare carries obligations that sit on top of the general data protection and platform requirements every app faces. Identifying those obligations before the architecture is set is almost always cheaper than discovering them during build or after launch.
If your product moves money between users, get a legal opinion on your AML obligations before you design the transfer mechanism. The architectural decisions you make at that stage, limits, identity checks, audit trails, are much cheaper to make correctly than to rebuild later.
In-App Safety Features as a Compliance Requirement, Not a Nice-to-Have
Safety features in consumer apps, particularly those with user-generated content or direct messaging, are increasingly treated as a regulatory expectation rather than a product decision. The UK's Online Safety Act creates obligations for platforms to protect users from illegal content and, in many cases, from legal but harmful content. Products that allow anonymous interaction carry a higher burden because the anonymity that makes the product attractive is also what can make it dangerous.
On the anonymous messaging app we worked on, we built in-product reporting features that allowed users to escalate concerns about inappropriate or bullying messages directly to the client's admin team. This was not a feature that came out of the initial brief. It emerged as we got deeper into the product and began examining what anonymous messaging actually enables. A user who has sent abusive messages has a strong incentive to delete their account. A platform with no reporting mechanism, no admin review process, and no data retention policy has no way to respond when that happens.
The safety architecture on that product required three things working together: the in-app reporting tools, the admin-side review interface for the client's team, and the data retention policy described earlier. Each of those had a development cost. None of them generated revenue. But without all three, the product could not responsibly operate in its chosen category, and it would have faced serious platform and regulatory risk. The cost of safety features is real and belongs in the project budget from the start.
How to Budget for Compliance Before You Build
Compliance budgeting works best when it is treated as a discovery question rather than a build question. Before scope is set and estimates are made, the team needs to understand which regulatory frameworks apply to the product, which platform guidelines are most relevant to the product category, and whether any sector-specific obligations exist. The answers to those questions change what gets built, and therefore what everything costs.
A practical pre-build compliance review covers the following.
- Data mapping: what personal data does the product collect, where does it go, and how long is it kept.
- Platform review: which app store guidelines apply most directly to the product category.
- Regulatory mapping: which sector-specific rules apply, such as AML, health regulations, or financial services rules.
- Safety obligations: does the product category carry Online Safety Act obligations or equivalent.
- Third-party dependencies: do any planned integrations carry their own compliance requirements.
Each of these review areas should produce a documented output that feeds into the product spec and the architecture decisions. The cost of that review is small relative to the cost of retrofitting the answers into a live product. On the dating app we worked on, skipping discovery for the messaging component, just one part of one product, resulted in a rewrite that cost approximately £15,000 in additional budget and two months of extra work. Compliance discovery is cheaper than that, and it catches more problems.
Where Compliance Sits in a Product Roadmap
Compliance does not have a natural home in most product roadmaps because it does not generate features users ask for. It generates constraints, policies, and infrastructure that users never see but rely on. That invisibility is exactly why it tends to get deprioritised until something forces it back onto the agenda.
The right way to handle compliance in a roadmap is to treat it as a category of work that runs in parallel with feature development, not as a set of tasks that get addressed reactively. This means scheduling legal review at defined intervals, not just before launch. It means including data protection impact assessments when new features touch personal data, as a step in the feature process rather than an optional extra. And it means building a relationship with whoever is responsible for platform compliance, whether that is an in-house legal team, an external solicitor, or a specialist consultant, so that regulatory changes are caught proactively.
Compliance work that surfaces in the roadmap as a named category of effort also becomes easier to budget. Teams that treat it as background noise find it appearing as emergency work with emergency costs. Teams that schedule it as a recurring overhead find it cheaper, more predictable, and considerably less disruptive to live products.
On the bootstrapped social football platform we worked on, mid-project budget pressure forced a decision to pause Android development and focus all remaining resource on iOS. The result was a product that launched on one platform and addressed roughly half the intended audience. The budget pressure that caused that decision had multiple sources, but any unplanned rework compounds that kind of pressure fast. Compliance costs that are not in the plan become the final straw that forces trade-offs nobody wanted to make.
Conclusion
Compliance is a cost you pay either way. The question is whether you pay it at the point in the project where it is cheapest and most manageable, or at the point where it is most disruptive and most expensive. Products that treat compliance as a discovery activity, asking the regulatory questions before the architecture is set, make better decisions and spend less overall.
The patterns we have seen across the products we have worked on point in the same direction. The currency exchange product that needed KYC and AML retrofitted after Apple's review. The anonymous messaging app that needed a data retention policy to satisfy both GDPR and law enforcement obligations. The dating app where skipping discovery for one component cost £15,000 and two months. In each case, the underlying compliance question was not obscure or unforeseeable. It was answerable before build began, at a fraction of the cost it took to answer it later.
If you are planning a product and compliance feels like a box to tick at the end, it is worth pausing and reversing that sequence. The compliance questions shape the architecture, the data model, the onboarding flow, and the platform submission. Getting them answered first is efficiency.
Let's talk about your product's compliance requirements before they become budget problems.
Frequently Asked Questions
Retrofitting compliance into an existing product is slower and more disruptive than building it in from the start, because changes often require touching parts of the codebase that were never designed to accommodate them. A data model built around the wrong assumptions, for example, becomes a much larger problem once real users have stored data in it. The further into the product lifecycle a compliance gap is discovered, the more expensive it becomes to fix.
In highly regulated industries such as healthcare and fintech, compliance, security, and data protection requirements can increase development budgets by 30 to 50 per cent. That figure applies when compliance is treated as part of the build rather than an afterthought. When it is treated as an afterthought, the cost often becomes a separate project that far exceeds any percentage of the original budget.
Issues around data handling, transfer limits, and identity verification are frequently overlooked during early product planning, particularly in fintech products. Anti-money laundering requirements, KYC checks, and restrictions on peer-to-peer transfers are the sort of details that can appear straightforward until a platform or regulator flags them post-launch. These gaps tend to surface at the worst possible moment, once users are already in the product.
GDPR gives users the right to request deletion of their personal data, but certain product categories carry legal or safeguarding obligations that require data to be retained even after an account is deleted. This creates a genuine tension that cannot be resolved through technical means alone. It requires a deliberate policy decision about which obligation takes precedence in which circumstances, and that decision needs to be made before the product is built.
Compliance is best addressed during discovery, before any design or build work begins, because decisions made at that stage are far cheaper to act on than changes made later. Treating compliance as a design decision rather than a post-launch crisis response leads to significantly better outcomes for both budget and product quality. Teams who understand their compliance obligations early make fundamentally different architectural and product decisions to those who encounter them late.
Compliance planning tends to fall between product teams, lawyers, and accountants, which means it can easily be neglected by all three. In practice, the most effective approach is to bring compliance into product and design conversations from the outset, rather than treating it as a separate workstream owned entirely by legal or finance. The teams that understand compliance as a product consideration, rather than an administrative one, are the ones that avoid the most costly surprises.
The immediate consequence is rework, which takes time, costs money, and can delay or disrupt a product that users are already relying on. Beyond the financial impact, late compliance fixes can introduce instability into parts of the codebase that were not designed to be changed, creating new risks in the process. In regulated sectors, the consequences can also include platform rejection, regulatory investigation, or reputational damage.
Those sectors carry particularly heavy regulatory requirements, but compliance obligations exist across many product categories, including social platforms, messaging apps, e-commerce tools, and anything that handles personal data. GDPR alone applies to any product that collects or processes the data of users in the UK or EU, regardless of the sector. The specific obligations vary, but the principle that compliance is cheaper to address early applies universally.