Peer-support and community platforms with safeguarding built in.
A policy does not enforce itself.
You have a safeguarding policy and a platform where people disclose things. Purpledecks is a senior software engineering firm in Ireland. We design and build the systems that make the policy real: joining rules, moderation, reporting, escalation, access control, retention. We built the peer-support platform and moderation system for Someone Like Me, with data protection designed in.
Who this is for, and who it is not.
In product circles this work is often called trust and safety. We call it safeguarding, because that is the word in the policy your board signed.
You are a founder, product owner or operations lead at a charity, a peer-support community or a health-adjacent service. You are building or fixing a platform where vulnerable people interact and disclose. You hold a safeguarding policy and duties, and you need them to exist as working software rather than as a document.
The shape matters more than the sector. If your product has user-to-user contact, a foreseeable risk to someone's welfare, sensitive interpersonal data and a real moderation duty, you are in the same place.
You want safeguarding policy consultancy. You want someone to moderate your community for you. You are shopping for a case-recording or case-management product. Nobody in your organisation owns safeguarding by name. Or your product is a medical device, which is a different regime and a different page.
Togetherall, Kooth and Side by Side are operated services. You refer people to them and somebody else runs the service. Case-recording and case-management products are a different purchase again: they hold the record of concerns your staff enter. We are neither. We build and fix the platform you run yourself, and we build the safeguarding into it.
Does the software actually do what my safeguarding policy says?
Twelve questions a board asks, and the safeguarding software we build for each one. Every row has its own link, so you can send one question to the person who has to answer it.
Who can join, and how do we know?
Registration and identity rules, an age gate where under-18s are in scope, and the smallest set of fields a person must give before anything opens to them.
Who can contact whom?
Who can see and message whom is decided once and enforced by the system itself, not just hidden on the screen. Two people get a private conversation only when both have agreed to it.
What can a member do to protect themselves?
Block someone, mute a thread, leave a group, decline a connection, or take a break. Each one is a real setting the system remembers and applies everywhere, not a preference that quietly lapses.
How does someone report a concern?
A report route in every place people talk, and a record of the report that cannot be edited away.
How do we tell urgent from ordinary?
A triage queue with severity, ordering and an owner, so the urgent case is not sitting behind forty ordinary ones.
Who is on duty, and what happens at two in the morning?
Rotas and cover in the tool, and the out-of-hours message a person actually sees, so nobody is left waiting in silence.
Who can read a disclosure?
Role-based access, with the read itself logged. You decide access once and the software enforces it every time.
What can a moderator actually do?
A permission matrix for each role, every action written to an audit log, and no action taken by software on its own.
What data do we actually need to hold?
We go through the data one field at a time and keep only what a feature genuinely needs, so nothing sensitive is collected on the chance it might be useful later.
How long do we keep it?
Retention periods per class of data, a deletion window, export on request, and the deletion running rather than being promised.
What do we let the software decide?
This is human-in-the-loop content moderation. The software spots something and puts it in front of a person, and the person decides what happens next. Nothing is removed and nobody is suspended on the software's word alone.
How do we show it works, and keep it working?
The safeguarding rules are written down as tests the software has to pass, and they run again every time anything changes. If a rule breaks, the build tells us before your members do, and the reports come in language a trustee can read.
In Ireland, safeguarding guidance names a Designated Liaison Person. In the UK the same role is called a Designated Safeguarding Lead. The software does not care what you call it. It needs one named person, with cover.
We name the region your data is stored in, and we hand you the list of every third party the platform sends data to and what each one receives. Trustees ask this. The answer should exist before they ask.
The safeguarding rules are tested as rules, at the backend, on every change. A general administrator cannot open private messages. A report cannot vanish without history.
One platform, live, with four of these built in.
Someone Like Me is a founder-led cancer peer-support platform. Four facts, and then the page that carries them.
We built the peer-support platform for people with cancer, and the moderation system that runs in it.
A person joins one of two communities, patients and survivors, or family and friends. The two do not appear to one another anywhere, and the rule runs through the product rather than sitting on the screens.
Moderation works on intent rather than a banned-word list, and every flag goes to a moderator on the client's team. Software does not act on an account on its own.
Consent is recorded with the exact wording shown at the time. A person can export their data. Retention runs to the periods the client sets, and every change made in the admin portal is written to an audit log.
The Safeguarding Systems Review.
A fixed-price, fixed-length review of your platform against your own policy. It is a new engagement and it stands on its own. You get deliverables, not activities, and the report is yours.
Each price is fixed, plus VAT where it applies.
Ten working days from complete access.
The report is yours and you can take it to any builder. Findings do not change based on who does the fix.
No policy authorship.
No vetting.
No live moderation.
No accessibility conformance audit.
Your roles, and who holds each one.
The name of your designated person, and who covers them.
Whether under-18s are in scope.
Where your organisation is established, and where your users are.
This is a systems and permissions review, not a line by line read of your code. If what you need is a deep source-code review, that is the Readiness Audit, a different engagement with a different price.
There is no safeguarding sample report yet. The sample below is from the Readiness Audit, and it is the standard our reports are written to.
Or write to hello@purpledecks.com. A senior engineer replies. Same day if you catch us in the morning, next working day at the latest. No hand-offs.
What software cannot decide, and who we will not take.
Software can carry a decision. It cannot make one. Whether a case is urgent, whether a person should be removed, what your threshold for harm is, who your designated person is: those are yours, and they belong in your policy before they belong in a product. We build what carries them, and we say so on the page rather than in the small print.
Moderation is labour, not a feature. Somebody reads the queue, and what is in the queue is the worst of what your community produces. So moderator wellbeing and supervision are design inputs here, not afterthoughts: how long a shift runs, how much a moderator sees before they choose to open something, whether the same person carries the hardest material every day, and who they escalate to when it lands badly. A tool that ignores that burns out the people your policy depends on.
A buyer who wants the report to say the platform is fine. We write what we find.
A build where safeguarding is a phase two. It runs through the data layer, so it is not something you add later without opening the whole thing again.
Accessibility is a delivery requirement. We agree the standard, testing method and evidence for each build before work starts.
What the law expects, and where our part stops.
We describe the frameworks and we build the artefacts they expect. We do not advise you on your obligations, and nothing here is legal advice.
In the EU, the General Data Protection Regulation treats data concerning health as a special category under Article 9, so processing it needs both a lawful basis and an Article 9 condition. Where processing is likely to result in a high risk to people, Article 35 requires a data protection impact assessment. Your organisation decides the lawful basis, the Article 9 condition, the retention periods and whether an assessment is needed. We build the controls those decisions need: consent recorded with the wording shown at the time, export, retention with a deletion window, and an audit log. We do not choose your lawful basis and we do not write your assessment.
In the UK, the Online Safety Act 2023 sets out risk assessment duties that apply in relation to regulated user-to-user services. They include a duty to carry out a suitable and sufficient illegal content risk assessment, and a duty to keep it up to date, including when Ofcom make a significant change to a risk profile for services of that kind. Whether your service is in scope is a question about your service, not about your software, and it is yours to answer with your own advice. Ofcom is the regulator, and it publishes the codes of practice and the risk profiles a provider works from. We build the inputs an assessment needs: what your functionality actually allows, who can reach whom, what is recorded, and how a report travels. We do not complete your risk assessment, and no software makes a service in scope or out of it.
In Ireland, the Children First Act 2015 applies to a provider of a relevant service, and the Act defines a relevant service by a list in its Schedule 1 rather than by whether an organisation is a charity. One item on that list is the provision of advice or guidance services, including by means of electronic interactive communications, where a necessary and regular part of the work is contact with children. Whether your service is on that list is yours to answer with your own advice. Where it is, we build what your procedures need in software: the reporting route, the named point of contact, role gates on who can see a concern, and records that hold. We do not decide your scope and we do not write your policy.
In Ireland, vetting of people who do certain work with children or vulnerable persons runs under the National Vetting Bureau (Children and Vulnerable Persons) Acts. Which of your roles need a vetting disclosure is your organisation's decision. In the software it is a role gate: a role that cannot be granted until your record says the check is in place, and a log of when it was granted and by whom. We do not carry out vetting, and your vetting records stay in your own system.
Most of this scales by who your users are. A service used only by adults does not carry the children's duties. A service that admits under-18s carries both, and the software changes: age gating, what a young person can see and be sent, and who is told when something happens.
Those are controls we built. They are not a claim that software on its own makes a service compliant. Legal advice comes from lawyers. The systems and the records come from us.
The questions a board asks.
No. Your policy is yours, and it should be written with people who do that work. We take the policy you have and build the software that carries it. If the two disagree, we tell you which clauses have nothing behind them.
No. We build the tools your moderators work in: the queue, the triage, the permissions, the audit trail. The people are yours, and so are the decisions.
Yes. The duties follow what your service does and who uses it, not what kind of organisation you are. A commercial platform with user-to-user contact and sensitive data is in the same position.
Same work, different word. Trust and safety is the product term, and safeguarding is the word in the policy your board signed. We answer to the policy.
The Digital Services Act is EU law for online platforms, and whether it reaches your service is a question for your own advice. What it asks of software is the same shape as the rest of this page: notice and action routes, records, and reasons a person can be told.
Yes. The report is yours. We would rather you had an accurate one you can act on than a captive one you cannot.
Your policy, your roles, the name of your designated person, whether under-18s are in scope, and where you are established. Ten working days from the point where we have complete access.
Book a Safeguarding Systems Review.
A short call first, with a senior engineer rather than a sales layer. What your platform is, who uses it, what your policy says, and where you already know the gaps are. If the review is not what you need, we will say so on the call.
Email to book a reviewWritten by Barry Gough, Chief Technology Officer.