Industries · Media & Entertainment
We build the systems media businesses run on: content platforms and paywalls, subscriber management, video delivery, rights and metadata, audience analytics and lifecycle programmes that keep readers and viewers coming back.
You own the code and IP Weekly demos Reply within one business day
OlDevs is a full-stack technology studio in Vancouver that builds software for publishers, broadcasters, studios and creator businesses.The work covers content platforms and paywalls, subscriber and entitlement management, video delivery, rights and metadata handling, audience analytics, and email and lifecycle programmes. We work as one accountable team, show a working demo every week, and hand over all code, designs, accounts and IP to the client. Every engagement starts with a scoping conversation, so request a quote to begin.
Key facts
Media & Entertainment
The problems we are asked to solve most often — and how.
A meter set too tight kills discovery, and one set too loose gives the archive away. We build metering, registration walls and entitlement checks that hold up under caching, syndication and crawler access, then test the rules against real reader behaviour.
Encoding ladders, storage, players and CDN rules decide whether a launch or a live event holds together. We design delivery so playback starts quickly on poor connections, and so a sudden audience surge does not take the rest of the site down with it.
Titles arrive with windows, territories, embargoes and takedown obligations, and none of that stays still. We model rights as data rather than as a spreadsheet convention, so availability, geographic rules and expiry are enforced by the platform instead of by memory.
Trials, bundles, gifting, group licences, dunning and grace periods rarely fit the plugin that started it all. We separate identity, entitlement and billing state so support staff can answer a subscriber question without opening three admin panels.
Every tag, wrapper and consent script added to a page competes with the article the reader came for. We audit the stack, move what we can to the server side, and set budgets so advertising revenue and page performance stop being treated as a trade-off.
Analytics in one place, the newsletter in another, subscriptions in a third, and no shared view of a single reader. We build a first-party data layer with consistent identifiers so lifecycle programmes, reporting and editorial decisions all draw on the same numbers.
Process
Discovery
We sit with editorial, ad operations, subscriptions and engineering to map how content, rights and money actually move today, and where the current stack costs you time or audience.
Architecture and plan
We agree the content and rights model, the entitlement rules, the delivery approach and the measurement plan, then sequence the build so the highest risk piece is proven first.
Build in weekly demos
Development runs in short cycles with a working demo every week. You test real articles, real episodes and real subscriber states rather than approving a static design.
Launch and migration
Archive, metadata, redirects and subscriber records move under a rehearsed plan, with the old and new systems compared until the numbers agree, then a switch you can roll back.
Growth and iteration
After launch we keep working on conversion, retention, performance and reporting, releasing changes in the same weekly rhythm and reviewing what each one did to the numbers.
How we work
We start with how the newsroom, studio or creator team actually publishes. A platform that fights the daily routine gets worked around, so we design the tools to match the way stories, episodes and releases really move.
Designers, engineers and marketers sit on the same team with one point of contact. Nothing is handed between a build agency, a media agency and an analytics vendor, so nobody has to reconcile three versions of the plan.
Every week you get something you can click through, not a status report. Editors, ad operations and subscription staff see the real thing early, which is when changing direction is still cheap.
We build to WCAG 2.2 AA, including keyboard-operable players, visible focus, sensible reading order, and support for captions and transcripts in the content model rather than added afterwards.
Events, identifiers and reporting definitions are agreed with your business team while the feature is being built, so subscription funnels, article performance and campaign results all reconcile to the same source.
Code, designs, accounts, pipelines and IP belong to you. No proprietary layer you cannot take elsewhere, and no dependency on us to keep the platform running once the work is handed over.
Recommended
Weekly
Working demo cadence
WCAG 2.2 AA
Accessibility standard applied
1 business day
Reply time to every enquiry
FAQ
Usually yes. Media teams build years of workflow habits around their CMS, and replacing it is rarely the first thing that needs doing. We can build a separate front end, a paywall layer or a subscriber system that reads from what you already run, then revisit replacement later if the CMS itself turns out to be the constraint.
By treating the rules as a product decision rather than a plugin setting. We look at which content stays open, how metering interacts with caching and syndication, and how crawler and referral traffic is treated, then implement it so the same rule is enforced everywhere. We are developers, so the policy itself stays yours.
Both, depending on scale. For most publishers, integrating an established encoding, storage and delivery provider is the sensible route, and we build the ingest, metadata, player and entitlement layers around it. Where the requirement is unusual, we design the pipeline directly and tell you which case you are in first.
Subscriber records are personal information, so we design for data minimisation, clear consent capture, export and deletion paths, and proper access control from the start. Canadian work commonly involves PIPEDA and, for Quebec audiences, Law 25. We build to the requirements your counsel sets; this is engineering support, not legal advice.
Yes. We build web apps, iOS apps and Android apps, and for media clients the usual pattern is one content and entitlement back end serving all three. That keeps a subscription bought on one platform recognised on the others, and keeps article, episode and rights metadata in a single place rather than duplicated per app.
Carefully, because the archive is often the most valuable asset you hold. We inventory the content and its metadata, map old URLs to new ones, plan redirects and canonical rules, migrate media and rights data, then run the old and new systems side by side until the numbers agree. Search visibility is checked before and after the switch.
Both. Advertising operations, subscriptions and lifecycle email all pull on the same audience data, so we treat them as one system. That covers the ad stack and its effect on page speed, consent handling, subscriber conversion paths, newsletter and retention programmes, and reporting that shows which revenue line moved. Request a quote to talk it through.
Let’s connect
We’ll reply within one business day with next steps and a tailored quote — no obligation.