SOL-002

PLANETAPLAY PRODUCT STORY

Product IdeationCPOProduct DesignTechnology researchSWOTUX ResearchBrand DesignUI DesignFrontend DevelopmentLeadershipMVPVODOTTPRDScrumStakeholder management

Role

Multiple roles

Timeline

2008-2014

Team

15

Summary

Planetaplay: the first video-on-demand platform in Bulgaria built directly into a media production pipeline.

Role: CPO. Product owner and product designer. Product ideation, UX research, UX and UI design, brand identity, functional specification (PRD), SWOT and technology research, stakeholder management, product management

Timeline: 2008-2014 (six years)

Client: Payner Media, Bulgaria's largest record label and production company

Team: MVP built by me and two Java developers in GWT. The implementation team was eight developers after the prototype and validation, split into frontend and backend squads with a Scrum master each, and grew to fifteen in the final stages.

Download a short version of the Case Study below:

Planetaplay Short Case Study 6.1 MB

I had worked with Payner Media since the mid-2000s. First as an art director on their music-video production and TV pipeline, where I pushed for higher production values in their sets, scripts and post-production. In 2005 at Nuvizus Communications, my company for web based solutions and user centered design, built their Planeta.tv site on our proprietary CMS Informato (rebranded as Mediato in 2007).

Payner became Nuvizus's longest-running client. By 2008 I knew their catalogue, their production pipeline, and their audience from the inside.

That year they gave me the task to put their video and audio catalogue online.

I accepted the brief as a strategy problem before anything else. YouTube in 2008 reloaded the full page on every action, had no easy to operate playlist, could not integrate with a production pipeline automation and metadata management, and reached Bulgarian users over slow international routes.

The local clone, Vbox, scaled on hardware but offered no real backend, metadata, or controlled embedding. At the same time the Bulgarian ISPs had built direct peering, the country ranked fourth in the world for fixed broadband speed by 2009. That speed existed for traffic that stayed inside the country.

A locally hosted platform could outrun YouTube for local users. This advantage was the difference, and I architected the product around it.

Planetaplay was the first video-on-demand platform in Bulgaria built directly into a production pipeline, and the first that behaved like a desktop application. I led its creation as a product designer, product architect and product manager.

The goal was to deliver entire frontend as a single AJAX page where search, playback, playlists, sharing, comments, and ratings all happened in place, with no full page reload.

This was the first progressive single-page web application in the country at this scale, and the team built the architecture and software solution from scratch.

I delivered the decisions, the research, and the design direction. The SWOT and product strategy, the UX research, the interaction model, the brand and a custom typeface reused across five products, and the technology direction (NGINX over lighttpd after load testing, an FFMPEG transcoding pipeline, a Zend backend, and later a Django services layer).

I also designed and managed the development of all other Payner / Planeta.tv web services like Planetapartner, a Django video API that delivered content and metadata to web media and IPTV partners.

After six years Planetaplay had more than 500,000 registered users (from internet active population at 3,996,006 in 2014), 52560+ hours of playback. 4,858,135shared playlists that brought new users in. Planetaplay had an option of Collaborative Playlists (allowing different users to edit a single playlist), growth model years before Spotify scaled the same mechanic (Spotify introduced this functionality in December 2013). A custom analytics interconnected backend fed production planning, artist ranking, and advertiser reporting.

Planetaplay ran for six years and closed in 2014, when a mobile operator acquired the user base and the technology stack.

It met every UX and adoption target I set. It ended for commercial and organizational reasons that had nothing to do with the product, and I cover them plainly in the retrospective.

You can still review a frozen version in the Wayback Machine capture of planetaplay.com from 2012.

Origins

By 2008 I had spent years inside Payner Media's operation. I worked first as an art director on their music-video and TV production, pushing the culture for stronger sets, higher aesthetic standards, and better post-production. I designed their digital presence at my company for web based solutions and user-centered design Nuvizus Communications.

We built Planeta.tv on our proprietary CMS Informato in 2005. Payner became Nuvizus's longest-running client, and I carried their work from that first site through several iterations. I understood the catalogue, the production pipeline, and the audience before accepting the challenge.

The specific technical and production culture, and an appetite for innovation in the client pulled me toward the project.

The Payner Media web-services map I produced for the project. Years inside their pipeline meant I knew every property Planetaplay would connect to, from Planeta.tv and the artist pages to Planetaface, Planetapartner, and Paynerstore.
Planeta Web Services 111 KB

In 2008, Bulgaria had a fiber boom. The major ISPs and LAN operators wired direct links between their networks. This local peering kept traffic between Bulgarian users inside the country's high-speed backbone, away from the slow international routes. By that year, local area networks delivered 60 percent of Bulgarian user's internet, far faster than ADSL, and dense urban fiber in cities like Sofia made gigabit speeds common inside apartment blocks.

The rollout of fiber pushed the country to fourth in the world for fixed internet speed by 2009 on Ookla's index.

That fourth-place speed applied to local traffic. Routes to international servers, including YouTube's, stayed slow. A platform hosted inside Bulgaria, peered directly with providers like Nettera, Orbitel, and BTC, could serve high-quality video at speeds YouTube could not match for these users, and with no international transit fees to pay.

ISPs already bundled IPTV and VOD with their fiber packages. The market was ready for local content delivery.

Payner Media had a deep library of video and audio, and they wanted it in front of internet users. We choose Flash video, now fast enough to stream over local fiber, as the delivery format.

Challenge and Context

YouTube at the time was a thin experience. Every action reloaded the whole page. There was no way to feed it metadata from a production pipeline, no controlled embedding, and no profiling of the people watching.

For Bulgarian users it was slow on top of that, because their traffic left the country to reach YouTube's servers.

The local clone, Vbox, solved only the hosting problem. It scaled hardware behind a basic player, with no real backend, no metadata, no rich interface, and no controlled embedding.

 

Key characteristics of the 2008 YouTube experience:

  • No Dynamic Loading: There was no AJAX-based content swapping. Clicking a "related video" destroyed the current page instance and loaded a completely new HTML document.

  • Player Interruption: Because the whole page reloaded, the video player stopped completely. There was no ability to keep a video playing in a corner while browsing other pages (a feature known as "Mini-player" or persistent playback, which came much later).

  • URL Changes: The URL in the address bar only changed after the full new page had loaded.

  • When did this change? YouTube transitioned to dynamic loading (Single Page Application behavior) around 2012–2013.

Wayback Machine capture of YouTube in 2008

Payner needed a system wired into their production pipeline. The requirements ruled YouTube out one by one:

  • Metadata pulled directly from the production pipeline

  • Controlled embedding, so clips played only where the label allowed it (this requirement gave the initial brief for Planetapartner service)

  • Format optimization through an FFMPEG transcoding backend and automation into the production pipeline

  • User profiling shared across all their sites (his requirement gave the initial brief for Planetaface service)

  • A dynamic comment section tied to each clip

  • RSS integration with the Planeta.tv news site

  • Cross-links to the Paynerstore merchandise shop and to Payner.bg events and artist management

  • All of it connected and interoperable, under the label's full control

Payner sat alone at the top of Bulgarian music and entertainment. No competing label had the infrastructure to produce, stage events, and distribute at their scale, and competitors had approached them more than once hoping to partner.

SWOT summary

Strengths

  • Largest catalogue and production pipeline in the country
  • Four-year client relationship and insider knowledge of the pipeline and audience
  • Technical judgment already validated by the Vivacom failure

Weaknesses

  • Everything built from scratch
  • A scope I described at the time as close to impossible
  • Strong dependence on one client's vision and management

Opportunities

  • Local-speed asymmetry: a Bulgaria-hosted platform could outrun YouTube
  • A market already shifting to bundled local IPTV and VOD
  • Integrations YouTube and Vbox structurally could not offer
  • Planetapartner's API as an asset beyond the Planetaplay consumer product

Threats

  • YouTube improving, and international speeds catching up
  • Monetization rules opening the region to global platforms over time
  • The client's management and lack of deep technical domain knowledge

A recent failure made the client take my plan in a serious manner. Vivacom, a mobile operator, had attempted to build a VOD platform with Payner before this, and it failed. They tried to push video on mobile phones at the time when 3g connection existed without possible technological solution (at the time Docomo created the only successful implementation).

While NTT Docomo initially launched mobile video services (i-motion) on its 3G FOMA network in November 2001, the company expanded video accessibility in 2008. On January 24, 2008, NTT Docomo announced a partnership with Google to enable YouTube playback on FOMA 904i series handsets and later models. Later that year, in June 2008, the launch of the 906i series further advanced 3G video capabilities by introducing support for Flash 8, Windows Media Video, and direct Blu-ray video transfers.

Vivacom (at the time brand name Vivatel) had big plans but not the technical expertise and budget to deliver. Payner Media asked me to consult, I reviewed their technical and production plan, and gave a negative assessment. The project failed as I predicted, and Payner came back to build to my vision instead.

Reasons for Market-Wide Failure of Vivacom's project

  • Prohibitive Data Costs: In the 2007–2009 period, 3G data tariffs in Bulgaria were high relative to average income. Streaming video consumed significant data, leading to "bill shock" for users, which stifled adoption.
  • Technological Limitations: Early 3G networks often struggled with consistent bandwidth required for smooth video streaming. Users frequently experienced buffering, low resolution, and dropped connections, making the experience inferior to traditional television.
  • Handset Scarcity: There was a limited availability of affordable 3G handsets with large screens and capable media players. Most consumers owned basic feature phones that were not optimized for video consumption.

Note: Planetapartner service delivered a way to embed clips on partner sites. I designed it as an API service with administrative CMS/CRM, the team rebuilt the system on Django and Python, that delivered content and metadata ready for to IPTV set-top boxes and other endpoints integration.

Decision delivered by following the logical technology advancements and insider information about the investment of M-tel into IPTV and satellite TV bundles (Mtel TV, later A1 TV). This gave grounds to the opportunity in which I have pitched the Planetapartner service to Evrocom and Megalan ISP's.

Discovery and User Insights

I treated this project as a research problem before a design one. The specific audience and content demanded a logical solution.

We ran surveys and polls on the fan forums, sat through observation sessions with selected users, and interviewed Payner's editors and personnel about the production process. For the interface itself, we ran split tests, and because no off the shelf analytics existed yet, we built a primitive heat-map solution to record and quantify how people actually clicked and moved.

 

The audience split into two age groups, 14 to 25 and 30 to 45, and we designed for both.

This audience cared about speed of interaction more than features and more than visual polish. They wanted to reach the next clip, fast. That single insight set the constraints for the whole product.

Thes users mental model for managing music came from the most popular desktop player at the time WinAmp. That pointed straight at a familiar usability principle.

 

WinAmp User Base Data:

  • Active Users: By late 2007 and continuing into 2008, Winamp boasted about 90 million active users worldwide. This figure represented the peak of its usage in the post-founder era under AOL ownership.
  • Market Position: It remained the dominant software media player for Windows PCs, widely preferred over competitors like Windows Media Player and iTunes for local file playback due to its extensive skinning engine, plugin ecosystem, and low resource usage.

H2 - Match Between System and the Real World "The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order." (Nielsen Norman Group)

This audience already thought in playlists and track lists, so I designed the core around a compact, WinAmp style list with Artist, Title, and Album columns, and ordered content slightly different from the way the music industry does, Artist to Track to Album, the hierarchy the audience already lived in.

Jakob's Law. People spend most of their time on other products, so they expect yours to behave like the ones they know.

By mapping the interface onto WinAmp and onto standard media-player controls, I let the audience reuse habits they already had, which made the product fast to learn as well as fast to use.

To test the direction before committing to it, I produced two interface versions. One followed the YouTube pattern. The other: the research driven compact list. The compact list won. It gave quicker and clearer interaction, and it fit the average desktop resolution of the time, packing more usable content into a single viewport without scrolling the whole page.

The research settled a set of interface decisions:

  • Search positioned prominently in the center of the fold, where the users who came in by name would reach it first.
  • Navigation which is clear and high in contrast, with rich tooltips that surfaced an artist photo, album, and track details on hover.
  • The playlist zone could switch to the comments thread in place, through AJAX, so a user could read and post comments while the clip kept playing, with the video staying in view.
  • Sharing built in from the start, both to help people pass clips around and to drive growth. The two age groups behaved more alike than I expected. Both leaned on that central search, and both searched the same way, by favorite hit or favorite artist. The main difference emerged in the younger group which commented and shared more.

Core navigation behavior barely differed between them, which told me one interface could serve both without compromise.

Every one of these decisions traces back to a usability principle, and I mapped them with intent.

The heuristic evaluation map I produced, connecting Nielsen's heuristics and the UX Laws to specific Planetaplay decisions.
Planetaplay heuristic map 77 KB

Technical Architecture

My focus is UX design, product design, and product vision, and the technology decisions exists to serve those and business logic. I made every choice to protect the one thing the research demanded, the speed of interaction.

The prototype & MVP.

Before the real product, we built a working prototype for idea validation, a team of three, me and two Java developers. We used Google Web Toolkit so we could move fast across the front-end and back-end from one codebase.

Much of what I had sold the client had ambitious ideas to the point of seeming impossible, so the prototype had to prove the whole vision. Four months in, it worked, and it gave me a complete set of technical and design requirements for the real application. It also showed the client where the project could fail, and that earned the trust for bigger budget and technological experiments.

The second team built the production system from scratch. I selected PHP and the Zend Framework and PostgreSQLfor the back-end, and a full single-page AJAX frontend on top. Outside of jQuery, the JavaScript libraries we take for granted today did not exist, so we created from scratch the rich interface, the animations, and the pixel-precise layout.

Building lean meant we controlled every millisecond of the experience.

The single AJAX page emerged as the critical point of Planetaplay application.

If it failed, the whole product would fail with it. This is what let the interface behave like a local application, and that application feel projected the whole selling point.

NGINX over lighttpd, decided by load testing.

In 2009, while lighttpd dominated the market, my benchmarks revealed a superior option. NGINX outperformed the competition by serving more concurrent pages, stabilizing memory usage, and maintaining resilience under high demand and critical factors for a video platform performance. This data driven choice established our architectural pattern. Pairing proven, stable technologies with experimental ones through rigorous testing, selecting each based on its criticality to the system.

I specified the back-end as a full functional model from the start. Each core entity, Artist, Album, Media, and Partner, had its own admin map covering listing, editing, file handling, and transcoding modules.

Backend mindmap media
Planetaplay backend media 95 KB
Backend mindmap artist
Planetaplay backend artist 113 KB
Backend mindmap album
Planetaplay backend album 109 KB
Backend admin map for the Partner entity, the controlled-distribution side that became Planetapartner.
Planetaplay backend partner 97 KB

Underneath the application sat a PostgreSQL schema that held the catalogue, the playlists and their sharing, the sessions and ratings, and the social layer. An FFMPEG pipeline handled transcoding and format optimization, and I adopted MPEG output for future-proofing the library against the coming shift away from Flash.

The PostgreSQL schema. The sended_playlists and media_sessions tables are where product strategy lived: one drove the sharing loop, the other fed the custom analytics.

The infrastructure under it ran on XEN virtualization with NFS-backed web servers on Debian, fronted by Apache and NGINX (NGINX in front to handle video delivery, proxying dynamic requests to Apache. NGINX served the heavy video content (FLV) directly, while passing PHP/HTML/AJAX requests to the backend Apache server).

The teams worked in three-week Scrum sprints in ActiveCollab, with SVN for version control and Rsync setup for deployment, and the last week of each sprint went to user testing, validation and the monthly client demo.

The architecture held for the life of the product.

Between 2010 and 2011 we moved the back-end administration to Django and Python and added the services layer, including Planetaface for unified identity, login and user data points. None of that touched the core frontend. The single-page AJAX foundation I had committed to in 2008-2009 carried Planetaplay, without a rewrite, until the end of service.

Branding and Visual Identity

The final brand mark with the media-type icon set I designed for the platform.

Naming

The client proposed Planetavideo, Planetashow, and Paynermedia. I rejected all three. "Planeta" was already established from the TV brand (Planeta means Planet in Bulgarian). The second half needed to describe an action, and "play" sounded as the most direct verb for what the product does. Two years after launch, NOVA TV created their VOD under the name NOVAPLAY, which followed the same logic. Google rebranded Android Market to Google Play in March 2012 for similar reasons.

Official Google Blog (March 6, 2012): In the official announcement titled "Android Market is now Google Play", Google Engineering Director Chris Yerga explicitly stated the rationale: "We’re bringing together Android Market, Google Music and Google eBookstore under one brand: Google Play." He explained that the name "Market" was too restrictive because the store had evolved beyond just apps to include movies, books, and music. The term "Play" reflected the dual nature of the content: "playing" games and pressing "play" on media.

I applied similar naming approach across the ecosystem: Planetapartner for the distribution API, Planetaface for the identity layer, and designed logotypes and brand identity for each.

Logo

The logo mark started on paper. I sketched the play-button triangle inside a circle, where the circle represents "Planeta" (planet) and the triangle is the universal play action.

I wanted the play triangle to have more soft curves and strong brand differentiation.

Hand-drawn logo sketch showing the play triangle inside the back/forward interface element.

I paired the mark with the custom typeface, tested in both light-on-dark and dark-on-light brand color combination.

Logotype showing light-on-dark and dark-on-light brand color combination.

Another version isolated the mark for use as a standalone icon, which I needed for favicons, app shortcuts, and the Planeta TV integration.

The standalone icon mark on dark and light.

The final version locked both into a system that worked across dark UI surfaces and the burgundy brand panels.

The final logo system. Both the full lockup and the standalone icon tested across dark and burgundy surfaces.

Custom typeface

Every designer has a contradictory view on Comic Sans font face. I studied why it works anyway. The analysis is simple: Comic Sans has mass appeal because its childish shapes and comical character make it feel accessible. The Planetaplay audience spanned ages 14 to 45, so I needed that same accessibility, but with enough craft to hold up as a brand typeface.

I took the accessible appeal of Comic Sans and mixed it with a cleaner Helvetica contour. The result: a custom font with character and high readability. I drew it by hand, vectorized it, and applied it across the entire brand group of five products: Planetaplay, Planetaface, Planetapartner, Payner Radio, and Paynerstore.

Color palette

Burgundy and cosmic latte. The reasoning came from my time as an art director inside Payner's production.

In 2004, I had spent time at Payner driving adoption of more professional video production: higher-quality sets, better scripts, and proper mise-en-scene. Pop-folk content in Bulgaria merged with clear pop tendencies and copied American pop culture.

The video clips depicted expensive cars, opulent interiors, high fashion, and success symbolism. The audience expected and responded to that visual language of luxury.

Payner's existing brand color is blue. Safe, but it had no emotional connection to the content or the audience. Their in-house graphic designers had also copied Apple's Aqua UI style directly into the Payner logotype. I cleaned those shapes away from the Aqua styling and created cleaner forms.

Burgundy matched the audience expectations of value and luxury. Cosmic latte color gave the dark-themed interface enough warmth to keep it from feeling cold or corporate. The palette worked because I understood what the content communicated and what the audience expected from it.

UI implementation

I designed the full interface in Adobe Fireworks and translated the results into HTML/CSS prototypes ready for testing, validation and production.

Fireworks handled both vector and bitmap at screen resolution, which is what a pixel-perfect application-style interface requires.

SVGs were not available in browsers at the time, so everything shipped as sprite-based PNGs with button states, loading animations, tooltip animations, and the random video thumbnail grid.

The compact disc login icon. Designed and rendered in Fireworks with realistic light and shadow.
The media-type icon set I designed for the platform: artist (microphone), photo, video, TV, and mobile/devices.

We delivered the frontend in pure JavaScript and CSS with an MVC model. No frameworks. Search speed, metadata listings, and the rich tooltip system were all built by hand. As a whole one of the most challenging parts of the entire implementation.

The complete UI component library, designed in Fireworks. Every button state, transport control, search element, scrollbar, tooltip style, and icon variation used across the platform.

The Final Solution

The interface shipped as a single PHP/AJAX page. Everything happened in one viewport. No page reloads, no navigation away from the content, no waiting. The entire architecture served the speed of interaction above everything else.

The Planetaplay interface as shipped. The top half (above the fold, primary value proposition) shows the three discovery paths (category tabs, random thumbnail grid, sidebar widgets), the search field, the transport controls, and the login area.

Two-zone contrast layout

I split the interface into two contrast zones. The video and audio player sat in a high-contrast dark zone that pulled the eye to the center. The playlist and interaction area sat in an intermediate-contrast zone around it. The viewer's attention went to the content first, and the controls stayed reachable without competing for focus.

H8 - Aesthetic and Minimalist Design. "Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility." (Nielsen Norman Group)

The two-zone layout applied H8 through contrast allocation. The player zone held the video and the transport controls. The playlist zone held the compact list, the search results, and the action icons. Nothing decorated, nothing duplicated.

Fitts's Law. The time to reach a target depends on its size and distance.

The player, the most-used element, occupied the largest and most central area. Transport controls sat directly below it, within the shortest possible reach.

Three discovery paths

The interface gave three routes to the same destination. Each route served a different user behavior, and all three converged on content selection.

Browse. A random thumbnail grid cycled square clip icons on intervals. Casual users could scan and discover visually without typing or deciding. The grid served as accidental discovery engine.

Search. The search box sat at the center of the fold, the highest-priority position for users who arrived with a name or a title in mind. Results loaded in a sortable tabular list with an immediate result count.

Curated. Editor's choice playlists in the category tabs (Exclusive, Promo, Folk) and sidebar widgets (Top 10 from the TV charts, Most Watched, New premieres) gave guided discovery driven by Payner's editorial team.

The information architecture: user arrival through three discovery paths, convergence on content selection, and the two-zone playback surface.
Planetaplay Information Architecture 167 KB
The annotated interface with each functional zone labeled. Every element visible here loads at once via AJAX.

Hick's Law. Decision time increases with the number of choices.

Three discovery paths, not ten. Sidebar widgets capped at three categories. The interface reduced choice without reducing access.

H1 - Visibility of System Status. "The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time." (Nielsen Norman Group)

The random thumbnail gridcycling on intervals, the live transport state, and the animated tooltips all communicated system status continuously. The interface felt alive and responsive at every moment.

The compact list

Below the player (below the fold, provides depth and supports decision-making, housing detailed information), the playlist view followed the WinAmp model directly. Three columns: Artist, Title, Album. A custom scrollbar. A sort pop over. Download (for audio), share, and add-to-playlist icons per row. Tabs to switch between the active playlist and search results.

The compact list view. Columns follow the hierarchy: Artist, Title, Album. The result count shows at the bottom, and every row carries download, share, and add-to-playlist actions.
The annotated compact list. The playlist tooltip shows artist photo, song title, star rating, artist name, and album on hover. The Planeta.tv RSS feed is visible in the right sidebar.

H6 - Recognition Rather than Recall. "Minimize the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another. Information required to use the design (e.g. field labels or menu items) should be visible or easily retrievable." (Nielsen Norman Group)

The entire interface sat in one viewport. Genre tabs, sidebar widgets, the search box, and the compact list: all visible simultaneously. The user never had to remember the location of functionality, because is always in view.

Full website view

Animated tooltip system

Every functional element in the interface carried a rich animated tooltip. Hovering over a thumbnail or a playlist row surfaced the artist photo, song title, star rating, artist name, and album. The tooltip served as in-context micro-documentation. The user learned the interface by moving through it.

The playlist tooltip (left) and the media-type navigation icons with a regular tooltip (right). Every functional element in the interface exposed contextual information on hover.

Playlist sharing, comments and the growth loop

Users built playlists for specific occasions: events, birthdays, house parties. They shared the playlist link. They were able to edit and save playlists as a group. The data also shared storage in the unified service login Planetaface. The recipient opened Planetaplay with the registration flow and playlist already loaded. A new user arrived inside a working session, with content already playing.

The playlist zone also switched dynamically to a comments thread via AJAX. Users could read and post comments while the clip kept playing, with the video staying in view. The two functions shared the same screen space and swapped without a reload.

Comment section loaded the content in the new tab within the playlist and search results zone. Comments and playlist sharing (plus group editing): available only for the registered users.

Ecosystem integration

Planetaplay connected to every other property in the Payner Media network. Planetaface provided unified login, sessions data and user profiling across all sites. Planeta.tv fed news through an RSS widget in the sidebar. Paynerstore linked from content pages to merchandise. Payner.bg provided event and artist management data. Planetapartner delivered authorized embeddings and IPTV endpoints. All services shared embedded data with widgets.

Planetaface universal login in context. One profile across all Payner Media sites, with comment count, rating, and profile access.
The Planeta WEB Services ecosystem. Solid lines carry content and metadata. Dashed lines carry identity through Planetaface.
Planeta WEB Services Ecosystem 185 KB
Planetaface unified login implementation with Planeta.tv website.
Planetaplay widget implementation with Planeta.tv website.

The original AJAX architecture held through the entire product lifetime. Between 2010 and 2011 I moved the backend administration to Django and Python and added the services layer, including Planetaface. None of that required changes to the core frontend. The foundation I committed to in 2008 carried the product until it closed in 2014.

Validation and Impact

Numbers

Planetaplay launched on November 10, 2009 and ran until 2014.

  • 500,000+ registered users. Bulgaria's population is about 7 million. Over 3 million people used Planetaplay over the product's lifetime. One in six of them registered. Ookla's index
  • 52560+ hours of video playback.
  • 4,858,135 shared playlists. Users built playlists for home parties, birthdays, and social events, shared the links, and new visitors arrived with content already loaded and playing.

Most users never created an account. The zero-registration design decision meant the real audience was larger than the registered count. 500,000+ represents the people who wanted to save playlists, comment, or rate, enough to register voluntarily.

Custom analytics

I designed a custom analytics backend because nothing on the market did what I needed. The system tracked user actions, playback metrics, and engagement drop-off: the exact point where a user stopped watching a clip. The data fed four outputs.

Production optimization.

Payner's editorial team used engagement data to inform which artists to invest in. If a clip lost viewers at a consistent point, production could act on the feedback.

Artist ranking. Playback hours and ratings across the catalogue gave the label a quantified view of artist performance, beyond TV ratings.

TV show creation. The Top 10 and Most Watched data from Planetaplay fed back into Planeta TV programming.

Advertiser reporting. The media_sessions table tracked per-clip playtime and drop-off, which gave advertisers concrete engagement numbers.

Release lifecycle

The team shipped in five stages, each expanding scope:

Pre-alpha. Video library uploaded through automation. Focus on backend metadata control.

Alpha. Basic frontend: search, sorting, playback optimization, loading time.

Beta. User registration, profiles, custom playlists, sharing, comments, and moderation.

Release Candidate. Widgets (Most Viewed, Top 10, Premieres), random thumbnail grid, RSS parser, advertising management, custom analytics.

General Availability. November 10, 2009. The full product.

Business outcome

The product met every UX and adoption target. The business context moved faster than the client's ability to capitalize on it.

Two potential deals failed. I pitched Evrocom, an ISP, and proposed a partnership and IPTV deal, but the deal failed because their solution lacked open-sourced code. The Megalan ISP (acquired in the same year by Mtel the largest mobile operator at the time) deal had the stronger opportunity. With direct payment-per-user model and initial deal for the user acquisition would have mapped the Planetaplay user base onto their IPTV infrastructure.

Megalan had a capable technical team with FOSS solution in place, and the Planetapartner API was already proven for the integration they needed. The deal got killed by a lack of incentive from Payner Media's side and internal management problems that had not surfaced during the earlier years of partnership.

The Planetapartner landing page showing Services, Registration, and Login
The Planetapartner partner application form, with audience thresholds and per-file access codes.

Planetapartner, the controlled-distribution layer I built for a requirement YouTube structurally could not meet. Partners apply, declare their audience, and receive a per-file access code, so the label keeps control of where each clip plays. The system was paired with usage data and analytics. The solution was extended for controlled content distribution to IPTV partners.

Wayback Machine capture of Planetapartner.com

In parallel, the market shifted. International internet speeds increased across Bulgaria. EU monetization rules opened YouTube to the region with proper ad revenue. The local-speed advantage that had made Planetaplay viable in 2009 got narrow.

An undisclosed mobile operator (under NDA) acquired the user base and the technology stack. Payner closed Planetaplay in 2014 and pivoted to partnerships with Apple Music/Tidal/Deezer/Spotify and global content providers.

After the closure, I and my team at Nuvizus Communications rebuilt Planeta.tv and Payner.bg with a new focus. YouTube and streaming platforms integration, live shows, an event system, and artist booking. The model shifted from owning the platform to driving streams through the Planeta.tv news site.

Retrospective and Learnings

What worked

The product met every target I set for it. The numbers confirmed the design decisions. Planetaplay architecture held for the full six years without a big rewrite. The AJAX single-page foundation, the two-zone contrast layout, the three discovery paths, and the compact list all shipped in yearly 2009 and remained the interface until the product closed.

The research-first approach paid off. Testing two interface versions before committing to the build, load-testing NGINX before the launch, and prototyping the entire vision in GWT before writing the production code meant nothing shipped without validation.

The growth loop worked as designed. Playlist sharing and group edditing brought new users in.

What did not work

The business context moved faster than the client's willingness to act on what we had built.

Two partnership deals failed at the decision stage. The Evrocom deal fell apart over implementation requirements. The Megalan/Mtel deal amounted the real loss. The right partnership with direct Minimum Guarantee + Cost Per Subscriber (MG + CPS), a capable technical team on their side, and a proven API and administrative control in Planetapartner ready for IPTV integration.

Internal management problems at Payner surfaced at the moment the deal needed executive commitment, and the opportunity closed.

The product delivered ahead of its market window. The UX, the technology, and the user base, all in place.

What I carried forward

Planetaplay is the most complex project I have built and managed. The scope covered ideation, UX research, UI design,technology research, brand identity, functional specification, Scrum process, stakeholder management, hiring, and people managementacross a rotating team of fifteen. I consulted with domain experts at every step and made the final call on every major decision.

I improved my technical skills and knowledge, built solid experience in managing a team under pressure, developed my communication and presentation skills, and strengthened my habits for documentation and administration.

The multidimensional skills I used on Planetaplay became the foundation of how I position my work today.

Product design, when practiced at the level where you own the vision, the research, the interface, the brand, and the technical direction together, is the most complete model I know for building solutions.

Planetaplay is where I proved I could hold it at once, and where I developed an intuition and knowledge how to lead teams towards successful implementation.