The challenge
People come to Optery because their personal details are exposed online. That makes trust the product. The service handles exactly the kind of data its users are trying to protect, so the APIs behind it have to be secure, and the experience has to make a stressful task feel manageable.
The data-removal workflows sit at the centre of the product, and they are where performance, reliability and usability matter most. A slow page, a confusing status or an unclear next step can make someone give up on getting their data removed.
Joining an established product also sets constraints. Changes have to fit an existing codebase and real users, so improvements are made carefully and incrementally rather than by rewriting what already works.
Scope note: Optery’s scanning engine and machine-learning work were not part of my role, and this is not a claim to have built the product. My work was on the frontend and backend:
- Secure backend APIs for the privacy and data-removal workflows
- Performance improvements across those workflows
- Responsive frontend experiences for the data-removal features
- Better data models, reliability and usability
What I built
On the backend, I worked in Python and Django, building secure REST APIs for the privacy and data-removal workflows. When personal data is involved in nearly every request, security is the first design question: who is calling, what they are allowed to see and what the response actually needs to contain. Returning less is often the most effective control.
Security on a privacy product is also about what is kept and shown. Personal data should appear in a response, a log or a screen only where it is needed, and access should follow the same rule. I applied that principle to the APIs and interfaces I worked on.
I also improved performance across those workflows. In a privacy product, speed is not cosmetic. Every slow step in the data-removal journey is a moment where a user can lose confidence in the service that is meant to protect them.
Part of that work was improving the data models underneath. Clearer data models make APIs easier to secure and to reason about, and they make the system more reliable, because the state of a record is explicit rather than implied by scattered logic elsewhere in the code.
On the frontend, I developed responsive React experiences for the data-removal features. Users check on their privacy from whatever device is to hand, so the interface has to work cleanly on a phone as well as a desktop, and it has to make the next step obvious.
Working on both sides of the API meant a change could be carried through end to end: a better data model, the API that exposes it and the screen that uses it, delivered together rather than handed between people.
Architecture and stack
- Frontend
- React
- Backend
- Python · Django · REST APIs
Outcome
My contribution helped give Optery’s users a faster, more reliable path to controlling their online privacy, with secure APIs and responsive interfaces behind the data-removal features. Better data models improved reliability and usability across the platform.
For Optery’s team, the improvements were structural rather than cosmetic: data models and APIs that are easier to secure and maintain, and frontend features that work on any screen size.
This is the kind of work I now bring to clients directly: taking an existing product that handles sensitive data and making its APIs more secure, its workflows faster and its interfaces easier to use, without a rewrite.
- Secure backend APIs for the privacy and data-removal workflows
- Better performance across the data-removal journey
- Responsive React interfaces for the data-removal features
- Clearer data models, with gains in reliability and usability
“He was able to deliver many parts of our system, communicate efficiently, and was fun to work with throughout the engagement.”
Chen AtlasCTO & Founder, OpteryLast updated 2026-10-03