A cancer diagnosis is special category data under Article 9 of the GDPR. Private messages can carry health data too.
A cancer peer-support platform with moderation built in, live and in use. Purpledecks built the backend, the admin portal, the data layer and the infrastructure it runs on, and built the screens with the founder.
It is on the App Store and Google Play.
The founder is a cancer survivor. She wanted somewhere people affected by cancer could find someone whose experience actually resembles their own, and talk to them privately. Not a forum. Not a feed. One person, one conversation, and only if both sides want it.
Matching people on their diagnosis means holding health data about every one of them. Letting them talk in private means somebody still has to be able to keep the place safe. That is safeguarding. A policy does not enforce itself, so it had to be built into the places where people connect and talk. People arrive at a hard point in their lives, and the software cannot make that harder.
A person joins one of two communities. Patients and survivors, or family and friends. The two do not appear to one another in discovery, in connections or in chat. That rule runs through the whole product rather than sitting on the screens.
People are matched on cancer type, diagnosis stage, age, gender and distance. Distance searches use a geospatial index rather than reading every profile. You wave at someone. Nothing happens until they wave back. When they do, the connection forms and a private chat channel opens on its own. Discovery also keeps anyone you have already passed over out of view for a cooling-off period.
The backend runs as one service on AWS Fargate, on PostgreSQL. Socket.io carries the real-time chat, with Redis routing messages between instances so it runs across more than one. Endpoints that return personal data require authentication. Input is validated before it is used. Secrets sit in a secrets manager rather than in the code. Logging is structured and built to exclude profile data, diagnoses and message content.
The web tool the platform is run from. Multi-factor login and role-based access. User management, moderation, a report workflow, and content management for the podcasts, the support service listings and the reference data behind the profiles.
The founder worked in the design tools she already knew and handed over screens and brand assets. Our own UX designer worked beside her, and we built the screens across the whole app. You do not make a good designer learn your tooling.
The product and the moderation policy are the client's. We built the software around them, and the systems it runs on.
App Store review brought the conflict to the surface. Under guideline 5.1.1, an app may not require someone to enter personal information to use it, unless that information is directly relevant to what the app is for or required by law. The review called for phone number, gender, date of birth, location, diagnosis and interests to be optional. Most of those are the fields the matching runs on. So registration asks only for what the account needs. The app asks for the profile details afterwards, explains why, and leaves them optional. The features wait on the data. The signup does not.
A cancer diagnosis is special category data under Article 9 of the GDPR. A small user base does not make it ordinary personal data. The client decides the lawful basis, the Article 9 condition and the retention policy. We built the controls those decisions need.
Where consent is the basis, the system records the response and the exact wording shown at the time. A person can export their account data. Retention runs to the periods the client sets. When the deletion window ends, the account and the data covered by the client’s retention policy are removed. Every change made through the admin portal is written to an audit log.
Those are controls we built. They are not a claim that software on its own makes a service compliant.
A banned-word list flags ordinary cancer conversation and misses the same behaviour phrased another way. We built on intent instead: whether something is doing the thing that is not allowed, rather than whether it contains a particular word. What the rules look for underneath is the client's to keep, not ours to publish. We built the workflow that applies them. Every flag goes to a moderator on the client’s team. Software does not take anything down or act on an account on its own. Human in the loop, by design rather than by exception.
The hard part was not deciding what to flag. It was deciding what to leave alone. People talk about the frightening parts of an illness without breaking any rule, and if all of that goes to review the queue becomes noise and ordinary conversation starts to feel policed. That boundary took more thought than anything else in the build.
The easy failure here is a system that is safe and useless. Flag everything, and the people who need the place most stop using it.
Integration tests run against a real PostgreSQL database rather than stand-ins, exercising the backend routes.
The tests do not only check that the code runs. They check that a patient cannot reach a family member's profile through the backend, and that an admin role cannot do another role's job. Those rules cannot depend on what a screen happens to show, so the tests check them at the backend.
Development and production are separate, and production data is never copied into development. The pipeline runs the tests before a production release, so changes are tested before anyone on the platform sees them.
QA on iOS and Android hardware, with the defects found fixed before sign-off rather than logged and carried.
For a clean build we can stand over, we fix defects in our own work reported within ninety days of handover. We do not make that promise on every engagement. On this one we can.
"I'm very much a person who needs to understand how things work, not just approve them. Brian explained things properly, every time, until it made sense to me. I felt like Brian and his team held my hand through the whole experience, and I'm delighted with the end result."
We build and rescue platforms that hold sensitive data and have to keep people safe. Building one, or fixing one that has gone wrong? Talk to the senior engineers who would do the work.
Technical review by Brian Egan, founder, who worked on the build.
Purpledecks is a senior software engineering firm based in Ireland, in the EU, working since 2012. We build and rescue software that has to work.
