The Online Safety Act Is a Product Requirement Now: A UK Founder’s Pre-Launch Checklist for 2026

Most founders do not wake up excited about online safety regulation. Fair enough. But if your app lets people post, message, review, share or form communities, the UK’s Online Safety Act is now part of the product brief, not a document you ask a lawyer to skim the week before launch.

The Act became law in 2023, and its duties are being brought into force in stages. By 2026, Ofcom’s codes and guidance are a live part of launch planning for many services. You do not need to become a regulatory expert. You do need to show that you have thought about foreseeable harms, built sensible controls and kept a record of your decisions. This is not legal advice, and anything high-risk deserves specialist review. Think of it as a product checklist.

Work out what you are actually operating

Start with a feature map, not a legal textbook. The Act covers user-to-user services and search services. Many apps are user-to-user without calling themselves social: marketplace reviews, comments under articles, in-app chat, creator profiles, group chats, live Q&A, shared playlists with comments. If one user can see or interact with content from another, flag it.

Write down the surfaces where content appears and where people can contact each other. Include the boring bits: direct messages, profile bios, image uploads, usernames, links, reporting forms and recommendation feeds. This map will drive everything else, and it is much easier to maintain than a frantic memory of what shipped last sprint.

Treat the risk assessment as a design tool

Risk assessment sounds like a binder that lives in a cupboard. In practice, it should be a working list: who could be harmed, how likely that is, how severe it could be, and what reduces the risk. Children and adults at risk deserve specific thought. So do scams, harassment, grooming, illegal content and the strange ways people misuse features you thought were harmless.

Record your assumptions and review them when you add a new messaging feature or make profiles public. A small team can keep this lean. The important thing is that the assessment changes how the product works, not just how the spreadsheet looks.

Sort out your age story before design freezes

Age assurance is not only for adult products. If children can use your app, decide whether that is intended. If it is not, how do you prevent it proportionately? If it is, what defaults protect younger users? Avoid collecting ID from everyone by reflex. Collect what you need, explain why and document the decision.

Age gates, feature restrictions, private-by-default profiles and safer DM settings can do a lot before you reach for heavy verification. The worst outcome is a vague assumption that someone else has handled it. The second worst is a clunky check that blocks genuine users and still does not answer the question.

Make reporting, blocking and complaints boringly easy

Safety tools should not be hidden in a settings maze. Reporting, blocking, muting, hiding and complaints need to be findable at the point of harm. Test them on a phone, on a train, while distracted. A report flow that demands email verification when the user is already logged in is a design failure.

Complaints need an acknowledgement, a route to review and a record. Moderation needs a queue, owners and an escalation route, including safeguarding. If you cannot staff a 24-hour response, do not imply that you do. Clear expectations beat heroic promises.

Line up your terms, notices and moderation policy

Your community guidelines should match what the product actually does. Plain English. What is allowed, what happens when someone breaks the rules, how to appeal. Just-in-time notices at the point of posting can be more useful than a 12-page document nobody reads.

If you use automated moderation, say so. If humans review reports, say roughly when. If you remove content, explain the next step. Alignment matters more than elegance: a polished policy that describes a different app is worse than a plain one that tells the truth.

Let defaults carry some of the weight

Private profiles for younger users, DMs limited for unknown adults, safer discoverability, rate limits, spam controls, keyword filters and content warnings can all reduce risk before a report is ever made. Safety by design means the safe path is the easy path, not a treasure hunt through settings.

This is also good product thinking. Most users do not want to configure their way to a safe experience. Sensible defaults make the app feel calmer and more trustworthy, which is not a bad brand position for a UK launch.

Keep a paper trail a small team can maintain

One owner. One folder. A simple log of risk decisions, moderation actions, complaints, training and vendor checks. Update it monthly. If Ofcom asks, or a serious incident happens, you want evidence, not a scramble through Slack.

Have an incident plan too: who calls legal, who handles comms, who preserves evidence, who contacts the relevant authorities. A one-page plan that people have actually read beats a 40-page plan nobody can find.

A launch gate you can actually use

• Feature map marked as user-to-user or not
• Risk assessment completed and reviewed
• Children’s access and age assurance decision documented
• Reporting, blocking and complaints tested end-to-end
• Moderation capacity and escalation route agreed
• Terms, guidelines and in-product notices aligned
• Records, training and incident plan in place
• Specialist legal review for anything sensitive

The point is not to tick every box and collapse. It is to show that you have designed for safety, not just bolted on a policy. In 2026, that is part of shipping a credible UK app.