DCP+

The product

DCP+ is Decentralized Pictures’ streaming platform for films and episodic content. It brings catalogue discovery, rentals, purchases, subscriptions, and advertising-supported viewing into a single experience, with protected playback across web and connected TV.

The familiar act of choosing a title and pressing play crosses several systems: viewer identity, card payments, wallet signing, blockchain settlement, content entitlements, and DRM-protected media. My work connected those boundaries into a usable client application. A successful journey meant that viewers could find content, understand their access, complete a transaction, and watch with progress retained for their next session.

My engagement

I joined DCP+ through Lazer Technologies in June 2025, embedded within the client’s engineering team. Working alongside product and engineering stakeholders, I helped refine requirements, translate product goals into application behavior, and resolve the integration questions that stood between implementation and a working viewer experience.

From August 2025, I was the primary engineer responsible for the client applications. My scope covered application architecture, feature and integration ownership, technical investigations, connected TV, operational tooling, and release preparation. That responsibility required moving between product details and system behavior: understanding what a viewer needed to accomplish, deciding where the application should own that behavior, and collaborating across service boundaries to make it work.

I carried that approach through catalogue and account experiences, commerce, playback, and episodic viewing. The goal was a coherent product whose parts could evolve together, with maintainable contracts between the interface and the services behind it.

Application architecture

I restructured the application around explicit route boundaries to make session responsibilities predictable. Global providers had allowed unrelated dependencies to interact, producing inconsistent request initialization and flashes of content before redirects. Each route needed a clear answer to what session, permissions, and data had to be ready before its experience could proceed.

The resulting structure separated root infrastructure, authentication routes, the main streaming session, and page-local data and permissions. This gave initialization a clearer order and reduced coupling between experiences. Application lifecycle work, including bounded recovery and cleanup, also addressed repeated SDK initialization and made recovery behavior easier to reason about.

Generated OpenAPI types and view models stabilized the interface as API contracts evolved. Generated types exposed contract changes during development, while mapping code kept endpoint-specific shapes out of presentation components. Those boundaries supported discovery, profiles, personal libraries, and series and episode experiences without tying every component directly to a service response.

The Next.js backend-for-frontend provided another deliberate boundary, moving session tokens into HttpOnly cookies with CSRF protection. Together, these decisions made access, data readiness, and lifecycle management explicit responsibilities within the application.

Commerce and authentication

Wallet signing helped establish a viewer session, but continuous wallet connectivity was unnecessary for browsing and playback. When unexpected sign-outs appeared, targeted telemetry showed restoration failures while the wallet SDK was still connecting. I used that evidence to reconsider the dependency instead of simply adding more reconnection attempts.

I made the viewer session the authority for application authentication and treated the wallet as an on-demand signing capability. This separated access to the streaming experience from the availability of a wallet for a particular purchase, subscription, or renewal operation. In-place signing recovery let the viewer address a wallet problem within the transaction workflow.

Commerce required similarly clear boundaries. I implemented Stripe purchasing, wallet-signed transactions, subscriptions, and reusable payment methods, connecting the interface to the steps needed for access. Payment completion, blockchain settlement, and a playable entitlement could arrive separately; showing them as one event produced misleading calls to action and indefinite pending states.

I consolidated five sources of client settlement state into a unified transaction state machine. It gave the application one consistent model of progress, including a longer-than-usual state, while preserving the distinction between paying for content and being able to play it. That made the client workflow clearer and gave technical investigations a more precise starting point.

Playback and connected TV

I integrated DRM-protected playback with FairPlay and Widevine across HLS and DASH delivery, then built the surrounding experience: custom controls, audio and subtitle selection, progress tracking, resume, and playback recovery. The work extended beyond displaying video to maintaining a consistent viewing session across browsers and devices.

Safari exposed a difficult authorization boundary. Protected content played in Chrome, but Safari’s native HLS path did not carry the expected authorization headers. Playlist tokens did not propagate as needed, cross-site cookies were dropped, and alternative playback paths did not resolve FairPlay decryption. Working with the client’s engineering team, I helped establish a functioning path using signed CDN cookies, a CDN alias on the application’s site, and appropriate CORS configuration.

Later compatibility work introduced an iOS 17.1 and newer path using Managed Media Source for authorization injection with FairPlay support. Playback recovery also became a product interaction: Watch Here let a viewer reclaim playback after another session took over.

A shared TypeScript core carried API clients, view models, session logic, streaming behavior, and error handling across web and TV. I built the Samsung Tizen experience around those foundations, with device sign-in and remote navigation adapted to television use. A signed build passed Samsung Seller Office pre-testing in June 2026, establishing a tested distribution path toward store submission.

Delivery and reflection

The engagement produced a live streaming web product and an end-to-end purchase-to-playback journey. A real purchase settled on-chain and became playable in March 2026. Safari DRM playback followed in April, the web service and Cannes beta in May, and a production web release in July. In October, I prepared the v0.3.0 release package, bringing together later work on episodic content, subscriptions, advertising, settlement, and recovery.

Additional contributions made the product easier to operate. I implemented VAST advertising behavior that allowed content to continue when inventory was empty or ad requests failed. Localization automation connected a scoped Laravel import endpoint to CI publishing, using merge-safe updates and translation diagnostics to replace manual resource imports in development and staging.

This work reinforced how much reliable delivery depends on understanding the complete product journey. Clear route responsibilities, explicit transaction state, and evidence-led playback investigations made complex integrations easier to explain and maintain. Being embedded in the team let me connect those technical decisions to product requirements and carry them through implementation, validation, and release preparation.