CutDaCord — Operating a media application as a connected service
A private platform combining household accounts, client integration, asynchronous workflows and service observability.
- Web and TV interfaces
- Account API
- Database and background workers
- Media integration as a separate service
- Shared observability alongside
The problem
A media application is only one part of a usable service. Account lifecycle, household access, client behavior, background work and operational recovery all have to agree. CutDaCord is my work on the system surrounding that experience.
The system I designed
I built around existing open-source media software and concentrated on the application and operating layers: a member interface, household account management, backend services, asynchronous job handling and monitoring.
The account interface and embedded media-client experience have separate responsibilities. That separation allowed the member experience to evolve without forcing the same changes into every TV-client view.
Engineering decisions
Use existing media software for the capabilities it already provides, and make the integration boundary explicit. My contribution is the surrounding application, service coordination and deployment work; upstream media software retains its own authorship.
Represent background work with visible states. A task should be traceable through completion, failure and recovery rather than disappearing into a worker.
Protect account rules at the database boundary. A household limit is not enforced reliably if two concurrent requests can both pass the same preliminary check.
Operate the whole stack. Correlation IDs, metrics and centralized logs help connect a user-facing symptom to the service or background task responsible for it.
A failure that changed the design
Removing a household member deactivated the account but retained an email address protected by a uniqueness constraint. Re-adding that person could fail even though the interface showed the prior account as removed.
The member lifecycle was revised to release the original address during deactivation. Related review moved account-limit enforcement under a database lock. The historical implementation record describes backend tests, frontend tests and browser checks across the member interface and embedded experience; these were not rerun for this page.
What this demonstrates
CutDaCord brings together product behavior and infrastructure: account lifecycle, concurrency, compatibility across clients, background processing and deployment. Its value as a case study is how those pieces behave together.
Role and limits
I conceived the service, designed its architecture and product rules and directed implementation and operations. Coding agents contributed substantial implementation and review work.
Source and operational access remain private. The system depends on upstream software and finite storage capacity. This page does not document content acquisition, distribution rights or commercial availability, and should not be read as a conclusion about any of them.
Next: CareOps — A healthcare-operations AI assistant where the software, not the model, decides what it can see and do.