The Cancellation Button Is an Engineering Deliverable Now: What the Digital Fairness Act Will Ask Your Product Code to Prove

Why Is a Consumer Law Proposal Landing in Your Backlog?

Most engineering leaders have a mental filing cabinet for EU regulation, and consumer protection goes in the drawer marked legal. That filing has worked for thirty years, because consumer law historically regulated what you said: the terms, the disclosures, the price presentation, the returns policy. All of that is copy, and copy is somebody else's problem.

The Digital Fairness Act breaks the filing. It is the European Commission's planned horizontal instrument on digital consumer protection, and the practices it targets are not statements. They are mechanisms. A countdown timer that resets when the page reloads is a component. A cancellation path that takes eleven steps when signup took two is a route. A recommender tuned for session length is a ranking function with a loss term. A price that varies by device, location or inferred urgency is a service call. Every one of those is something an engineer wrote, and none of them can be fixed by rewriting a paragraph in the terms of service.

The evidence base behind the proposal is unusually blunt about this. The Commission published its digital fairness fitness check in October 2024, and Arthur Cox's summary of the findings records two numbers that explain why an entirely new instrument is being drafted rather than a guidance note issued: a 2022 behavioural study found that 97% of the most popular websites and apps used by EU consumers deployed at least one deceptive pattern, and the fitness check quantified consumer detriment in the digital environment at approximately €7.9 billion per year. When a practice is present on essentially every site, the regulator stops treating it as deviance and starts treating it as a market default that has to be re-specified.

Timing matters for planning, so be precise about it rather than alarmed. The Parliament's legislative train file for the Digital Fairness Act tracks the initiative through a public consultation that ran from 17 July to 24 October 2025 and into the Commission's impact assessment. Goodwin's analysis of the initiative sets out the expected shape: a draft legislative proposal in the second half of 2026, the ordinary legislative process running through 2027, and a horizontal harmonising framework that complements the Digital Services Act and the unfair commercial practices regime rather than replacing them. That is not a deadline you sprint at. It is a deadline you design toward, which is a different and much cheaper exercise.

One detail from the consultation is worth keeping in mind, because it tells you how much political energy sits behind this file. The consultation drew thousands of responses within its first fortnight, a large share of them from video game players pressing for rules against publishers disabling games people had paid for. Consumer-protection consultations do not normally attract that. This one did, and files with a constituency move faster and survive amendment better than files without one.

What Actually Counts as a Deceptive Pattern Here?

The most common objection engineering teams raise at this point is reasonable: dark pattern is a vague term, half the internet uses it to mean any design someone dislikes, and you cannot build against a vibe. Fair. But the EU has already been concrete about this in enforcement, and the concreteness is the useful part.

In the coordinated screening run by national consumer authorities and the Commission, 148 of the 399 online shops screened were found to contain at least one of three specific categories. Forty-two sites ran countdown timers with fake deadlines attached to specific products. Seventy sites hid information or made it less visible, typically around delivery costs, cheaper alternatives or contract duration. Fifty-four steered consumers toward particular choices, from subscriptions to pricier delivery options, through visual design or the wording of the buttons. That is not a vibe. That is three testable assertions about a page.

The Commission's published record of these coordinated sweeps shows the pattern of attention over time, moving from dark patterns to influencer marketing, to second-hand goods, to price marketing practices. Each sweep is a signal about what a future instrument will codify, and each has been followed by national enforcement rather than by a shrug.

The legal gap the Digital Fairness Act is meant to close is specific and worth understanding, because it determines who is in scope. Article 25 of the Digital Services Act already prohibits online platform interfaces that deceive or manipulate users, but it binds platforms, and it offers very little operational detail about what compliance looks like. The unfair commercial practices regime applies far more broadly but works case by case, after the fact, through national authorities with uneven capacity. A horizontal instrument with concrete interface requirements would apply to the ordinary e-commerce business, the B2C SaaS product and the mobile app that never came close to platform thresholds. If your product takes money from consumers in the EU, assume you are in scope and plan accordingly.

The Cancellation Path Is Where the Real Cost Sits

If you read one part of the evidence base, make it the part on contract cancellation, because it is where the gap between what products do and what the law is about to require is widest, and because the engineering work is genuinely non-trivial.

Freshfields' breakdown of the fitness check on cancellations and digital subscriptions sets out what consumers reported. 69% found cancellation technically difficult. 55% believed traders deliberately used mechanisms to avoid cancellations. 40% said the design of the website or app made cancelling very difficult. 54% never received a confirmation that their contract had actually been terminated. 62% experienced an automatic renewal with no reminder beforehand, and 44% ended up paying for additional months because they had not realised the contract was still running.

Look at that last cluster as an engineer rather than as a consumer. Confirmation of termination is a transactional email and a state transition that fires it. Renewal reminders are a scheduled job against the subscription record. Unintended additional months are what happens when cancellation is modelled as a support ticket rather than as a state the system can enter on its own. The reason so few products handle these well is not malice in most cases. It is that subscription lifecycle logic accreted around a billing provider over six years, nobody owns it end to end, and the cancellation path is the one route that no growth metric ever rewarded anyone for improving.

The direction of travel is already visible in national law, which is the clearest signal about what a harmonised rule would look like. Germany requires a cancellation mechanism reachable in roughly two clicks, France in three, and the same Freshfields analysis notes that a mandatory click-to-cancel function, explicit consent for free-to-paid conversions, and clearer technical cancellation requirements are all live candidates for the instrument. A rule that says cancellation must be as easy as subscription is not a slogan once a regulator counts the clicks on both paths.

The United States arrived at the same destination by a messier route, and the cost of getting it wrong there is now a matter of public record. The Federal Trade Commission's click-to-cancel rule was vacated by the Eighth Circuit in 2025, but enforcement did not stop. Amazon settled claims over Prime enrolment and cancellation for $2.5 billion, comprising a $1 billion civil penalty and $1.5 billion in refunds to roughly 35 million customers, days into what was expected to be a month-long trial. And the rulemaking came back: Jones Day's note on the revived rule sets out the renewed process and what it means for subscription businesses. If you sell to consumers on both sides of the Atlantic, you are not choosing between two regimes. You are building one flow that satisfies the stricter reading of both.

Addictive Design Turns Product Defaults Into Regulated Settings

The second cluster in the proposal is the one that will generate the most internal argument, because it reaches features that product teams consider core rather than marginal.

Osborne Clarke's analysis of the addictive design strand lists the features the Commission has named: infinite scrolling where a page loads content with no distinct end, ephemeral stories that disappear rapidly, autoplay that starts video or audio without user intervention, engagement penalties such as breaking a streak, and recommender systems steered to increase engagement. Guidance on protecting minors under the Digital Services Act adds communication streaks, read receipts and push notifications to the same list.

Three regulatory approaches are under discussion, and they are not equivalent in engineering cost. Giving users controls to disable features or choose recommendation criteria is a settings surface plus a propagation problem. Switching features off by default with opt-in availability is the same work plus a materially different growth conversation. Prohibiting certain features outright for minors is the expensive one, because it presumes you know which of your users are minors, and that is an age assurance problem sitting underneath a product problem. We worked through the architecture of that verification layer separately in the piece on EUDI Wallet integration, and the short version is that it is a service you build once behind an internal boundary, not an SDK you drop into three screens.

The consultation responses suggest the minors angle has the most support behind it. A summary of the published consultation responses records that 31% of respondents agreed certain addictive design features should be prohibited for minors outright, with particular concern about personalised advertising and pricing aimed at children and other at-risk groups. That is a minority position in absolute terms and a strong one for a consultation, and minors provisions are historically the hardest part of any digital file to water down in trilogue.

The practical implication for a roadmap is smaller than it sounds if you act early and much larger if you do not. A product where autoplay, notification cadence and recommender weighting are hard-coded across four clients has to be re-architected to comply. A product where those same things sit behind feature flags with a per-user resolution layer has to change some defaults and ship a settings screen. The difference between those two positions is roughly one quarter of unglamorous refactoring, and the cheapest time to do it is before anyone tells you that you must.

Personalisation Becomes Something You Have to Be Able to Explain

The third cluster is personalisation, and it is the one most likely to be underestimated, because the obligation is not obviously about the interface at all.

McCann FitzGerald's overview of the problematic practices in scope describes the concern as personalisation that exploits consumer vulnerabilities, including targeting based on financial stress, emotional state or age, and personalised pricing that responds to inferred characteristics rather than to cost. The same overview flags a practice many companies would not have thought of as a consumer-protection issue at all: routing customers exclusively through an AI chatbot with no accessible human path.

Now translate that into system requirements. If a regulator asks whether your pricing varies by user and on what basis, the answer has to come from somewhere. In most products it cannot, because pricing logic lives in a rules engine that mutates weekly, the inputs to it come from a customer data platform nobody has fully mapped, and there is no durable record of which user saw which price on which date. The obligation that emerges from this file is not principally do not do unfair personalisation. It is be able to state what your personalisation does, which is an observability and lineage requirement dressed as a consumer right.

That is the same shape as several obligations European product teams have already absorbed. Marking and disclosure duties for generative features, which we covered in the piece on Article 50 transparency marking, turned out to be far more about provenance plumbing than about badges in the corner of an image. The defect and liability exposure we set out in the analysis of software under the revised product liability regime works the same way: the legal question is answered by whether your engineering organisation can reconstruct what the system did and why. Personalisation under a fairness regime joins that list.

The design implication is pleasingly boring. Personalisation decisions want to flow through one service that logs the inputs it used, the segment it resolved, the variant it served and the version of the rule that produced it. Products that already have that for experimentation can extend it. Products where personalisation is a scattering of conditionals across four repositories will spend most of their compliance budget on archaeology before any behaviour changes at all.

You Will Be Asked to Prove the Interface Was Fair, Not Just Assert It

The most consequential thing about the whole file is a framing rather than a rule. Commentary on how enforcement should be designed keeps landing on the same place: businesses should have to demonstrate that their interfaces, recommender systems and personalisation practices comply, rather than wait to be caught. Demonstrate is a word with an engineering cost attached, and it is a cost almost nobody has budgeted.

Consider what demonstrating actually requires. You need to know which interface a given user saw, which means retaining variant assignments beyond the life of the experiment. You need the copy and layout as rendered, not as designed, which means your experiment archive has to hold artefacts and not just a metric delta. You need the cancellation path as it existed on the date a complaint refers to, which means treating flows as versioned objects. And you need the record to survive the redesign that follows, which is exactly the point at which most teams delete the old variants because the dashboard has moved on.

There is a second-order effect on how growth teams work that is worth naming directly, because it will be unpopular. An experimentation programme with hundreds of live tests and a culture of shipping the winner is a machine for generating unreviewed interface changes. Most of them are fine. A small number will optimise a conversion metric by making a choice fractionally harder to refuse, which is the textbook definition of what this regime is aimed at, and the team that shipped it will not have noticed because the metric only went up. The fix is not to stop experimenting. It is a review gate on the subset of tests that touch consent, cancellation, price presentation or default selection, plus an archive that outlives the test.

This overlaps more than you would expect with accessibility, and teams that have done that work recently have a head start. Both regimes ask you to prove a property of a rendered interface across a population of users, both resist being tested at the end, and both are cheap as part of a design system and expensive as a retrofit. We set out that argument in the piece on accessibility debt in AI-generated interfaces, and the machinery is largely shared: component-level guarantees, automated checks in the pipeline, and an audit trail that ties a build to what a user actually saw.

Why This Work Breaks Normal Project Structures

Add up what the preceding sections ask for. Design that can defend a choice architecture rather than just A/B win it. Frontend engineering across every client where a flow is duplicated. Backend work on a subscription state machine that currently lives half in your code and half in a billing provider. Data engineering for personalisation lineage. QA that can test a cancellation path as a first-class journey rather than a smoke test. Release engineering to version and retain interface artefacts. And someone senior enough to say no to a growth experiment that works. That is five disciplines and a decision-maker, and it is the reason this kind of work stalls.

The failure mode is predictable and we have watched it happen on adjacent regulatory files. Legal produces an excellent memo. It becomes an epic. The epic gets groomed into tickets that each touch a different team's surface area, and each team schedules them behind their own roadmap. Nine months later the cancellation flow has been improved in the web app and not in iOS, personalisation logging exists for pricing and not for merchandising, and nobody can answer the only question that matters, which is what a given customer saw in March.

This is one of the clearer arguments for a dedicated development team rather than a fixed-scope compliance project, and the reason is structural rather than commercial. Interface fairness is not a state you reach. Every new checkout variant, every pricing experiment, every notification added to an onboarding sequence re-asks the question. You want the people who built the cancellation state machine and the personalisation logger to still be there when someone proposes a feature that quietly breaks both, which is the general case we set out in dedicated teams versus project-based outsourcing.

It is also an argument for nearshore development specifically, because the decisive moments in this work are conversations and not tickets. Whether a pre-ticked box is a legitimate default or a steered choice is a product judgement with a legal consequence and a revenue cost, and it does not survive being written into a ticket and answered the following afternoon from eight timezones away. Our engineering teams in Serbia work a full business day overlapping European hours and most of the US morning, which is the difference between settling that question in a call and deferring it to whoever writes the code. We compared the regional options directly in Serbia, Poland and Romania as nearshore destinations, and the overlap argument gets its own treatment in the hidden line item in every outsourcing quote.

Where the shape of the gap is narrower, so is the answer. If the product knowledge sits in-house and what is missing is capacity on a specific surface, staff augmentation into your existing squad is faster and cheaper than standing up a parallel team. If the exposure is concentrated in a storefront and its checkout, our e-commerce engineering practice treats cancellation, consent and price presentation as part of the transactional core rather than as marketing surface. If it is a subscription product, the same logic applies through SaaS product development, where the billing lifecycle is the thing being regulated. And where the work is genuinely a design problem before it is a code problem, UI and UX design that can articulate why a flow is fair is worth more than a redesign that merely looks cleaner.

What to Actually Do in the Next Two Quarters

None of this requires a compliance programme yet, and building one now would be premature against a proposal that has not been published. What it requires is that you stop accumulating the specific kinds of debt this instrument will price, and that is a short list of concrete work.

Start with an inventory of consumer-facing decision points, because you almost certainly do not have one. Every place a user consents, subscribes, upgrades, selects a default, sees a price or cancels. Name the owner and the repository for each. The output is usually uncomfortable: a mid-sized subscription product will find between twenty and forty such points spread across three clients, two of which nobody has touched in a year. This is a week of work and it determines the cost of everything that follows.

Then run the click-count test on your own product, honestly. Count the interactions from signed-in home to completed signup, then from signed-in home to completed cancellation, on every client you ship. Write both numbers down. If the second is more than the first, you have a finding that will be found, and given that Taylor Wessing's outlook on the Digital Fairness Act and the Digital Omnibus expects cancellation and subscription mechanics to be among the most concretely specified areas, it is also the finding with the shortest path from rule to fine.

Third, make cancellation a state your system can enter rather than a process your support team performs. Explicit states, a confirmation event that reliably fires an email, a renewal reminder job, and an end date the customer can see in the product. If that logic currently lives inside a billing provider's dashboard, it belongs in your domain model with the provider as an implementation detail. This is the single highest-value item on the list, and the one most likely to reduce support load enough to pay for itself independently of any regulation.

Fourth, put the addictive-design features behind flags before anyone asks you to. Autoplay, infinite scroll, streak mechanics, notification cadence and recommender weighting each want a runtime switch with per-user resolution. You are not turning anything off today. You are making it possible to turn things off in a week rather than a quarter, which is the difference between a settings screen and a re-architecture. And fifth, start retaining what a user saw: variant assignment, rendered copy and flow version, kept for as long as a consumer complaint can reach back. It costs storage now and it is unreconstructable later.