Frontend Modernization
for CustomChannels, a streamed music service for businesses
- Client
- Custom Channels
- Industry
- Streamed music for business
- Service
- UX/UI Design|Frontend Development|Legacy Modernization
A product people liked, in an interface they did not
Custom Channels provides streamed music for businesses. Its application worked, but the interface had aged: the customer described a system that was "not friendly enough", and wanted it rebuilt around good UX with room for modern features.
The commercial symptom was specific, and the client named it on the first call: free-trial users did not find the system intuitive enough, and did not go on to purchase a subscription. The interface was losing people at the exact moment a trial user decides whether to stay.
The client had an internal team and considered handling the work in-house before engaging Sphere.
What made the rebuild harder than a redesign
This was not a fresh build. An existing product had to be modernized while its backend was still moving, and the interface had to earn conversions it was currently losing.
Trial users did not convert
Free-trial users found the system unintuitive and did not purchase a subscription — the clearest signal that the interface, not the product, was the obstacle.
An existing application, not a blank page
The application already existed and had to be modernized rather than replaced, so every decision had to respect what was already running.
A backend that arrived in pieces
Backend work sat outside the statement of work and stayed on the Custom Channels side, so the frontend had to be built clickable first and integrated gradually as new endpoints were delivered.
How Sphere delivered it
Sphere supplied a UX/UI designer, a PM/BA and a frontend developer, and ran the engagement in three phases — discovery and planning, design, then development.
1. Discovery and planning
The engagement opened with a discovery and planning phase to establish what the modernized product had to do and where the existing experience was failing its users.
2. A working prototype before a single design file
Rather than debating flows in the abstract, Sphere built a quick prototype as a React application — generated with Claude — and used it as the discussion surface. Main ideas and user flows were reviewed against something clickable, changes were applied quickly, and a new version was shared back with the customer each round.
This is the step that compressed the usual design-review cycle: the customer reacted to a running application instead of a static mockup.
3. Design converted from the validated prototype
The designer converted the agreed prototype screens into the actual design, with working sessions alongside the customer team to settle the main elements and colour schemas. In parallel, technical tickets were created in the client's own Notion workspace so engineering could pick the work up in the system they already used.
4. Frontend built clickable, then wired up
With design complete, the team moved to development. Because the backend remained with Custom Channels, Sphere built a fully clickable frontend application and integrated it against real endpoints progressively, as each one became available.
QA was not part of the statement of work either, but the engagement was still inside its budgeted hours, so the team helped the client with QA rather than leaving the gap open.
Run as Kanban, steered weekly
Delivery ran on Kanban with a weekly sync call with the customer. Each call set the single highest priority for the week, and the team worked to it.
What the client got
A modern frontend, integrated with the live backend
The core deliverable: a frontend application built for the experience the product needed and connected to the customer's own backend as endpoints were released.
A new enterprise contract closed on the new application
The client reported signing a large contract after presenting the new application on the demo environment — the first commercial result attributed to the rebuilt experience.
Design and engineering handover, not just screens
Alongside the application, Custom Channels received the Figma design file, technical tickets in their own Notion workspace, and technical documentation.
A team that absorbed work outside the contract
QA sat outside the statement of work, but was covered inside the budgeted hours rather than handed back to the client.
What the build ran on
Application:
Design & Delivery:
Application:
Design & Delivery:
Where it stands
The product launched as a beta, so conversion figures for the rebuilt experience were not yet available from the client at the time of writing. What the client did report is a signed contract won by demonstrating the new application — and the reason the work landed: to complete the important parts of the functionality on time, the team pushed hard through the closing stretch.
