Development Agency
Contact Sign in Get a project quote

Service

Radio website development

For station managers and programme controllers at community, commercial and online radio stations who need a website that keeps the stream playing, knows what is on air and lets presenters look after their own shows.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A station website has one job above all others: keep the audio playing.

  • On most station sites the player stops the moment a listener clicks to another page, so people listen with the site open in one tab and never read anything else.
  • The schedule is a static table that the station manager edits by hand when a presenter moves, so the "on air now" line is usually wrong by Thursday.
  • The stream URL changes when the hosting provider migrates and the site keeps pointing at the old one until a listener rings in.

Where it gets harder

Listen-again is a folder of recordings uploaded when somebody remembers, with no expiry, so shows that should have gone after thirty days sit there for a year.

  • Presenters email their show descriptions and photos to the one person who can update the site, and that person is also the person reading the breakfast news.
  • Competitions are run through social media with the terms in a comment thread.
  • Song requests arrive by text to a studio phone and are lost when the handset is full.
  • The station has a loyal audience and a website that does not reflect a single thing happening in the studio.

Scope of the service

What the build covers

A custom radio website build normally covers the player, the schedule and the shows. The persistent player sits across every page and keeps playing through navigation, with stream URL management that carries a fallback so a provider change or an outage switches listeners to a backup without a site edit. The programme schedule holds shows, presenters and slots and drives the "on air now" display, show pages and listen-again. Listen-again segments are published against a show with an expiry so recordings leave the site when the station's policy says they should. Show pages carry playlists, and where the station's playout system provides it, a now-playing feed shows the current track.

Presenters get their own login to update their show description, photo and playlist. The request and shout-out form sends submissions to the studio queue rather than a phone. Competitions carry entry rules, a closing date and a draw, with entries stored for the compliance record. Advertiser and sponsor slots are defined per page template so the sales side can rotate a sponsor without a developer.

Deliberately out of scope

  • The streaming itself, which stays with your stream host and is connected to the player
  • Playout and automation, which stay in the studio
  • Licensing reporting, which the station's rights body handles with data the site can export where relevant

When the scope grows

Scoping scenario

A community station with thirty volunteer presenters wants each presenter to manage their own show page, a listen-again archive that expires after thirty days, a now-playing feed from its playout system and a monthly competition with a compliant entry record. The presenter self-service and the playout integration are what make it a custom build, and the scope document says so.

Deliverables

What you receive

  • Discovery notes from a visit to the studio and a walk through the broadcast week
  • A written scope document naming the player, schedule, listen-again and competition stages and what is left out
  • Designs of the player bar, the schedule page and the show page on phone and desktop
  • The build, connected to your stream host and playout feed where available, deployed to your hosting or ours
  • Migration of show pages, presenter profiles and any listen-again archive you wish to keep
  • Training for the station manager, producers and a session for presenters
  • Handover material and full ownership of the source code and your content

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current site, the stream host account, the playout system documentation and the current schedule.

    Project stage: Onboarding

  2. Planning

    Discovery with the station manager and a producer; stream formats, listen-again policy, presenter self-service and competitions go into the scope document.

    Project stage: Planning

  3. Design

    The player bar, schedule grid and show page are designed for the phone first, since most listening starts there.

    Project stage: Design

  4. Development

    Built in layers: player and stream management, then schedule and shows, then listen-again and now-playing, then requests and competitions.

    Project stage: Development

  5. Client review

    The station runs a trial week with presenters updating their own pages and a producer publishing listen-again, and reports what does not fit.

    Project stage: Client review

  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Stream fallback tested, schedule verified against the on-air log, listen-again expiry checked, launch checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The station runs on the new site; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Stream hosting providers and stream relays
  • Playout and automation systems for now-playing metadata
  • Audio storage for listen-again recordings
  • Email and SMS providers for competition winners and request confirmations
  • Advertising and sponsorship rotation tools
  • Analytics and consent management platforms
  • Social platforms for show promotion

How we would approach it

Worked example

Concept demo

A community station with thirty volunteer presenters

The situation

A community station with thirty volunteer presenters wants each presenter to update their own show page and playlist, listen-again that expires thirty days after broadcast, a now-playing feed from the playout system and a monthly competition with a compliant entry record.

Why it is a custom build

The custom route is needed because the station's playout system exposes its metadata in its own format, and because presenter self-service across thirty logins has to be locked down carefully.

The scope we would propose

  • A presenter role scoped to their own shows, listen-again publishing tied to the schedule with automatic expiry
  • A now-playing connector reading the playout system's metadata output
  • A competitions module storing entries with timestamp, rules version and the draw result

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of streams, formats and whether a fallback stream exists
  • Number of shows and presenters and whether presenters self-serve
  • Listen-again policy, retention period and audio storage
  • Availability and format of now-playing metadata from the playout system
  • Competitions, requests and the compliance records they need
  • Advertiser and sponsor slot requirements
  • Existing content to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Radio station package

A persistent player, programme schedule with on-air display, listen-again with expiry, presenter show pages, requests and competitions for radio stations.

Custom build
View the package

FAQ

Frequently asked questions

When is the package enough?

If your station needs a persistent player, a schedule, show pages and listen-again with a standard stream host, the radio station package usually covers it through configuration. A custom now-playing connector, presenter self-service at scale or unusual competition rules point to the custom route, and we say which in discovery.

Will the player keep playing when listeners move between pages?

Yes. The player is built into the site shell rather than each page, so navigation does not interrupt the stream. This is a core part of every radio build we scope.

Can you show what is playing right now?

Where your playout system publishes now-playing metadata, we connect to it and show the current track on the player and show page. If it does not, the site shows the show and presenter from the schedule instead.

Do presenters need training?

Presenters see only their own show pages, so most learn it from a short guide. The station manager and producers get a longer session covering the schedule, listen-again and competitions.

Who owns the site afterwards?

You do. Source code, content, recordings and competition records are handed over at delivery. Hosting and maintenance are optional and separately agreed.

Get a project quote for radio website software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences