Work · current role · 2022 – present
Privacy and consent platform work
Most people see privacy as a setting. My work has been the backend side: service contracts, release paths, monitoring, and audit trails that make those choices behave consistently.
Public boundary
- No internal architecture diagrams, service names, vendors, dashboards, or incident details.
- No exact traffic, record-count, region, partition, or compliance-review numbers.
- Deeper context belongs in a serious hiring conversation, not on an indexable page.
Selected outcomes
- Owned day-to-day backend and platform work for consent services used by consumer-facing product surfaces.
- Moved a production API path with phased rollout, validation, and a rollback plan written before release.
- Designed and ran a regulated data migration against a fixed compliance deadline.
- Helped raise the security floor across service repositories, build checks, and dependency remediation.
- Built check tooling that made on-call preparation easier for other engineers.
What it does
The platform is a source of truth for consent and preference state: the policy context, the user choice, the product surface that collected it, and the downstream systems that need to honor it. Storage is only the first requirement. Engineers also need to trace the decision later without guessing.
The work splits roughly four ways: keeping the read path available, keeping the write path correct, evolving the data model for new regulations as they land, and making the platform understandable for future engineers.
Things I've owned end-to-end
A small selection. I can share more detail in a serious hiring conversation.
Moving a production API path
Moved a production API path with phased rollout, validation at each step, and a rollback plan written before release. Security hardening landed with the same work, so the change improved both the operating model and the control posture.
Running a regulated data migration
Compliance work required a large population of consent records to move through a fixed renewal path. I handled spike research, pipeline design, staged rollout, validation against source-of-truth queries, and documented rollback. Wrote up a separate piece on this: the regulated migration case study.
Building an event-driven service
Designed and shipped an event-driven service around consent-record changes. The handler was the smallest visible part. The contract, test coverage, deployment path, and operational behavior mattered just as much.
Raising the security floor
Helped move a service portfolio toward stronger build maturity: dependency scanning, static analysis, infrastructure checks, and remediation of the resulting backlog. Coordinated across teams to land changes in dependency order.
Check tooling for on-call preparation
Built a small tool that checks the health signals that matter before on-call and surfaces what drifted overnight. It started as a personal tool and became useful enough for teammates to adopt.
What I've learned
The useful work is usually the part someone else has to live with.
A few things I would keep carrying forward:
- Distributed systems need a failure plan. Every "just deploy it everywhere" assumption needs a matching plan for disagreement, rollback, and ownership.
- The integration layer is real work. API contracts, deploy pipelines, observability, runbooks, and service boundaries are what make product changes repeatable.
- Regulatory deadlines force clarity. A hard date makes the plan concrete and exposes the parts that are still hand-wavy.
- Cross-team coordination is engineering work. A broad migration has to be sequenced, communicated, and rollback-ready. The code is only one part of the work.
What I'd do next
If I owned this platform for another two years, I would push hardest on three things: tighter contracts at the service boundaries, stronger failure-mode rehearsal, and a clearer model for how AI-assisted developer tooling fits into on-call work without taking ownership away from the human on call.