Compliance Doesn't Stop at Launch: How to Make It Part of the Product
Your product passed review. The privacy policy is live, legal signed off, and the first customers are paying. Then a new rule arrives: an accessibility law in the EU, a privacy law in another US state, an age check required by an app store. The team gets a deadline that was never on the roadmap.
This is how compliance usually shows up for product teams. It is rarely a single gate before launch. It is a stream of requirements that keeps coming while the product is already earning money. The rules themselves are seldom the hard part. The hard part is whether the product was built to change.
This article explains why compliance belongs inside the product, which stages of development it touches, and how compliance by design turns the next requirement into a configuration change instead of a rewrite.
Why compliance is a product question, not a legal checkbox
Most compliance requirements end up in code. What data a sign-up form collects, which defaults a settings screen uses, how a user gives and withdraws consent, who can buy what, whether a screen reader can get through checkout: these are product and engineering decisions. A legal review can tell you what the rule requires. It cannot ship the change.
The law itself says this. Article 25 of the GDPR requires data protection by design and by default: companies must build data protection into processing from the moment they decide how the processing will work, and keep it there for the whole life of the system. When choosing measures, they weigh the state of the art, the cost of implementation, the nature and purpose of the processing, and the risks to people. In other words, the regulation expects compliance to be a design input, not a document written after the release.
The cost of treating it as an afterthought is measurable:
- Fines. European regulators issued about €1.2 billion in GDPR fines in 2025 and €7.1 billion since 2018, according to DLA Piper's January 2026 survey. Regulators also received an average of 443 breach notifications a day, 22% more than a year earlier.
- Incidents. IBM's 2025 Cost of a Data Breach Report puts the average breach at $4.44 million globally and $10.22 million in the US. Healthcare has been the most expensive industry for 14 years in a row, at $7.42 million per breach.
- Lost deals. Enterprise and healthcare buyers send security and privacy questionnaires before they sign. A team that cannot say which data leaves the product, or which features run in which country, waits weeks for answers while the deal sits in review.
- Lost releases. A rule written into the code means a new build, a new store review and a regression risk for every user, even when the rule concerns one market.
Why compliance doesn't stop at launch
A pre-launch review is a snapshot. Legislators, regulators and platforms change requirements on their own schedules, and a product that runs in several markets meets all of their schedules at once. A few changes from the last two years show the pace:
| Area | What changed | What it touches in the product |
|---|---|---|
| Accessibility | The European Accessibility Act has applied since 28 June 2025. It covers websites and mobile apps of e-commerce, consumer banking, passenger transport, e-books and other consumer services in the EU. | UI components, contrast, screen reader support, forms, checkout, an accessibility statement |
| Privacy in the US | 24 US states now have comprehensive privacy laws, up from 20 at the start of 2026. Many require support for universal opt-out signals such as Global Privacy Control. | Consent, opt-out handling, data subject requests, rules for sensitive data |
| AI | EU AI Act obligations phase in from 2025 onward. In 2026, EU lawmakers agreed to postpone some of them, including obligations for high-risk systems, which move to December 2027. | Labelling AI-generated content, telling users they interact with AI, logging |
| Age and app stores | Texas SB 2420 took effect on 4 June 2026 after a court challenge. The app store verifies age, and the developer must act on the result. | Sign-up, purchases, parental consent, significant updates |
| Healthcare | Germany's e-prescription system keeps evolving under gematik specifications, including the CardLink procedure for redeeming prescriptions in pharmacy apps (see our pharmacy app case study and healthcare software development). | Prescription flows, health card scanning, security requirements |
Two patterns repeat across these examples. First, a rule rarely arrives in its final form: it is challenged in court, postponed, clarified by guidelines or changed by a platform. Second, the platform or the regulator usually handles one part of the work and leaves the rest to the product team. When Texas required age verification in app stores, Apple took on the check itself and gave developers tools to receive the result. Deciding what the app does with that result stayed with the developer.
“Sometimes a requirement comes from neither users nor the roadmap, but from the law. When a US state introduced age verification for purchases, we had to add checks, warnings and notices for users there. Our app lets product owners switch features on or off for a specific locale, which helps with both new markets and local laws.”
Roman Krutsiou, iOS Developer at Gilzor
Where compliance enters the product lifecycle
Compliance is cheapest where it is planned, not where it is discovered. Each stage of development has its own questions:
| Stage | Questions to answer | What you get |
|---|---|---|
| Discovery | Which markets, user groups and types of data are in scope? Which flows are regulated? | A list of markets and regulated flows, and counsel's view of the obligations |
| Design | What is the minimum data each flow needs? How does a user give and withdraw consent? Can everyone use the interface? | Data-minimal flows, clear consent screens, accessibility criteria based on WCAG |
| Architecture | Where do market rules live? Which modules hold regulated logic? Which vendors and libraries touch user data? | Per-market configuration, module boundaries, a data flow map |
| Development and QA | How do we test each market's behaviour, accessibility and privacy settings? | Test cases per market, accessibility checks, code review against the data map |
| Release | What do stores, users and buyers need to see? | Store privacy disclosures, a privacy policy, an accessibility statement |
| After launch | Who tracks rule changes? What happens in an incident? | An owner and a change log, a breach response process (under the GDPR, notification within 72 hours) |
The last row is the one most teams skip, and it is the one that decides how the next rule lands.
Signs your product isn't ready for the next rule
You can usually see the problem before a regulator does.
| What you notice | What's often behind it | What it costs the business | Priority |
|---|---|---|---|
| A rule in one market means a new release for every user | Market rules written into the code, no per-market switches | Release slots go to legal changes, features slip, every user gets a riskier update | High |
| Nobody can say which features are live in which country | No single place for regional settings | Slow answers to partners and enterprise buyers, deals stuck in review | High |
| Every compliance change touches files nobody wants to touch | Tangled legacy code without module boundaries | Estimates double, checkout or sign-up breaks | Medium |
| You learn about a rule weeks before the deadline | No one owns tracking legal and platform changes | Rushed work, frozen plans, risk of missing a date in a key market | Medium |
| No clear map of what user data leaves the product | Data flows grew one feature at a time | Longer privacy reviews and security questionnaires before a deal closes | Medium |
| Accessibility is checked only when someone complains | No accessibility criteria in design and QA | Rework of core screens, complaints, exposure under the EAA in the EU | Medium |
How to build a product that absorbs new requirements
Compliance by design doesn't mean predicting every law. It means building so that a new rule changes settings and a few contained parts of the code, not the whole product.
Map where regulated actions happen
List the moments where a rule could apply: sign-up and age, consent, purchases and subscriptions, health or financial data, user content sent to a server or an AI model, and the screens that must be accessible. Note which markets each one runs in. While you map, check what data each flow actually needs. Privacy by design starts here: if a product receives an age range instead of a birth date, there is less data to store and protect.
Why it matters: you can't estimate a change you can't locate. A map turns a vague legal question into a scoped ticket.
Make market rules configuration, not code
Put regulated features behind switches that can differ by country, state or locale. The product owner should be able to turn a feature on or off for one market without a new build or a new deployment. The same switches let you test a new market before you commit to it.
Why it matters: when a law starts, pauses and restarts, a switch follows it. Hard-coded logic needs a release each time.
Keep regulated flows in their own modules
Purchases, consent, age checks and data export should live in their own parts of the codebase. On one of our projects, features had been added fast for years and the code had become tangled. The business also asked us not to delete old logic, because it might be needed again. A refactor made it possible to add new functionality without breaking the old.
Why it matters: a contained module means a contained change. The estimate stays an estimate, and checkout keeps working.
Choose vendors and libraries for the long run
Every SDK, analytics tool and payment provider that touches user data becomes part of your compliance picture. Under the GDPR, the choice of processors should reflect how well they support data protection. Compare third-party libraries on how easy they are to maintain and how they handle data, so a platform change doesn't leave you waiting on someone else's roadmap.
Give one person ownership of rule changes
Someone should track legal and platform changes in your markets and turn them into tickets early. Platform developer news, regulators' guidelines and industry trackers are the places to watch. Apple, for example, announced the Texas requirements in its developer news together with the APIs developers needed.
Why it matters: a rule you see three months ahead is a planned feature. The same rule seen three weeks ahead is an emergency.
“A mature product keeps changing with the market and the law. When rules evolve and new systems and protocols appear, the technical side has to keep up.”
Tatiana Bulavko, Android Developer at Gilzor
What to do first
You don't need to rebuild the product. Start with whatever makes the next rule cheaper.
| Step | Effort | What it gives you |
|---|---|---|
| Map regulated flows, data and markets | Small | Every later estimate depends on it |
| Name an owner for tracking rule changes | Small | Rules arrive as planned work, not emergencies |
| Add accessibility criteria to design and QA | Small to medium | New screens stop adding accessibility debt |
| Put per-market switches around the riskiest flows, starting with purchases and sign-up | Medium | The next rule becomes a configuration task |
| Untangle the module every compliance ticket touches | Medium to large | Changes stop breaking checkout. The rest can wait |
If you sell in one market, with simple payments and no sensitive data, the first three steps may be enough for now.
Before you enter a new market or sign a regulated customer
A new market or a first enterprise customer is the moment rules multiply. The US isn't one market here: a single state can change what your product must do. An e-commerce site that starts selling in the EU takes on accessibility obligations. A health app in Germany works inside national prescription infrastructure.
Before you commit to a launch date, answer three questions:
- Which flows does the new market regulate?
- Can we switch features per market without a new release?
- Who tracks rule changes there after launch?
Self-check: is your product ready for the next rule?
Ready for the next rule?
Every box you can't tick is a question of priority. Start with the ones tied to the market you enter next.
How we work at Gilzor
We build web and mobile products that can take the next rule without a rewrite. Compliance is part of everyday engineering for us, not a separate phase.
- Developers own features end to end. On one long-running project, our developers take a feature from loosely described requirements through the backend contract, design edge cases, testing and the A/B test after release. Rules surface early, while they are still cheap to handle.
- Market rules become settings. We build switches so product owners can turn features on or off per market or locale. A new law becomes a configuration task, not an emergency release.
- Regulated code gets its own modules. A change to purchases or consent stays in one part of the product, so checkout keeps working.
- Libraries are chosen for the long run. We compare third-party libraries on how easy they are to maintain, so a platform change doesn't leave you waiting on someone else's roadmap.
What we don't do: give legal advice. We work alongside your counsel and turn their conclusions into product decisions and code.
We've launched 70+ products, delivered 98% of projects on time, and 85% of our clients come back. Our teams work from Poland and Cyprus.
Planning a new market, a regulated customer or a product that handles sensitive data? Tell us what your product does with user data. We'll tell you which requirements will shape the build and what to address first.
Built by Gilzor
Results we’ve shipped
Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.
Treat the next rule as a product requirement
If your product passed review and runs in production, you've already done the hard part. Compliance by design doesn't mean predicting every law. It means building so that the next one fits.
Go back to the self-check. The boxes you can't tick yet show where the next rule will cost you the most.
Contact us to discuss your product →
General information, not legal advice. Laws mentioned in this article can be challenged in court, postponed or amended, and their status can change. Involve legal counsel in decisions about your obligations.
FAQ
What is compliance by design?
Why doesn't compliance stop at launch?
Which regulations most often affect web and mobile products?
What is privacy by design in practice?
When should we involve legal counsel and when engineering?
No sales pitch
Get a straight answer for your project
Tell us what you’re building. We’ll reply with options, a rough cost and timeline. If we’re not the right fit, we’ll say so.
Engineers, designers and product people at Gilzor, writing about what we see in client projects.
Gilzor · Mobile Development partner
Need a team for your mobile app?
Services
Mobile DevelopmentNative and cross-platform iOS and Android apps, from MVP to scale.→By company type
Selected projects
The team behind them
