Not-for-profit

What a radio station asks of a website: recurrence, not a calendar

Ask a content management system for a schedule and it gives you a calendar. A radio schedule is a different animal.

Programs recur on their own patterns:

• weekly
• fortnightly
• on the second Tuesday of the month
• on the last Sunday of the month

The listener does not care about the pattern. They want to know whether their program is on this week, and what is playing right now.

The station broadcasts programming by and for communities that commercial and public radio do not reach. It is volunteer-run and listener-sponsored, and a supporter can name the program they are backing when they subscribe.

Almost everything about how a station like this works becomes a requirement on its website: a presenter publishing their own show, decades of broadcasting that has to stay reachable.

Our part in the work: an engineering partner on a Drupal 11 rebuild

Drupal(Opens in a new tab/window) 7 reached end of life, so the station's platform needed a new home. A partner agency brought us in as their engineering partner for the rebuild.

Since 2025 we have worked alongside their team on a Drupal 11 build, providing:

• technical leadership
• platform architecture
• migration engineering
• the delivery process

The brief was never only to move the site. It was to make sure the parts that run every day keep running on their own.

A schedule that tells the truth: weekly, fortnightly and monthly recurrence

We modelled recurrence the way broadcast actually works. Each program carries its own pattern, down to last and second-to-last of the month, the 2 cases most systems quietly decline to handle. Upcoming episodes are generated ahead of time and refreshed automatically, so the schedule a listener sees stays in step with what goes to air.

Then there is the part that only appears once a station is on air. A program booked for 9 o'clock does not begin at 9 o'clock exactly.

Recordings start a little early and run a little long, and the platform matches each recording back to the program that produced it within a tolerance. Without that, the audio archive would be a pile of unlabelled files, and that archive is a large part of what a station with decades behind it actually is.

Bringing the archive across: a Drupal 7 migration with its history intact

The migration from Drupal 7 carried across:

• hundreds of programs with their history
• the station's members and volunteers
• the taxonomy that organises decades of broadcasting
• more than 1,000 redirects, so links people saved years ago still land where they expect

For a client, that reads as continuity: the archive, the people and the saved links arrive with the content, rather than being rebuilt by hand after launch.

Getting there meant joining 2 live databases in a single query, which Drupal does not do out of the box, and knowing where Drupal 7 keeps content that looks absent until you check the right table. Migrations fail quietly on details like that, so the ones this one turned up are written into the codebase.

Built so the station can run it: roles, automation and a live player

A community station's day belongs to its programs, not to its website. The routine work happens by itself:

• upcoming episodes appear ahead of time
• recordings are attributed to the shows that made them
• the schedule keeps itself current
• the program catalogue comes straight from the station's podcast platform rather than being retyped

The live player was built for the audio format the station actually broadcasts, so listening works from the first page. For a client, that reads as time back: the hours that would go into keeping a website current go into programming instead.

Permissions follow how a volunteer-run station is really organised, with presenters, announcers, program makers and station managers each holding exactly the access their part of the station needs. A presenter can publish their own show, and only their own show.

The build runs on Vortex(Opens in a new tab/window), our open-source Drupal project template, with automated end-to-end tests over the journeys that matter, written on our published Behat step library(Opens in a new tab/window).

Where it stands: a Drupal 11 platform in active build through 2026

This is current work: a Drupal 11 platform, actively being built out through 2026. The schedule, the archive, the volunteer roster and the sponsorship model are one system, and each has edge cases only a real station produces.

Hundreds of programs, decades of archive and more than 1,000 saved links, carried from Drupal 7 onto Drupal 11.

Getting them right once is what lets a station's team spend their time on programming rather than on the website.

For platforms kept running by volunteers

Everything on this page is 4 of our services running on one live platform: platform architecture for a schedule broadcast actually produces, custom development for the parts no module covers, migration engineering off Drupal 7, and the DevOps and hosting that keeps releases repeatable.

If you run a community broadcaster, a member-funded not-for-profit, or any organisation whose website is maintained between shifts by people with another job to do, this is the shape the engagement takes: routine work built to happen on its own, roles that match how the organisation is really staffed, and an archive that survives the move. Where budget is the constraint, the same engineering is available with AI-assisted delivery, at the same tested standard.

If your Drupal 7 site is still carrying the schedule, the archive or the membership your organisation runs on, tell us what it has to keep doing.

Scattered research: the evidence exists, finding it is the hard part

If your organisation holds knowledge other people need, the problem is rarely a shortage of material. In this centre's field the research is extensive, but it sits in departmental reports, evaluations, literature reviews and journal articles, spread across dozens of places.

A practitioner deciding what to try next rarely has an afternoon to go looking, and an employer trying to do the right thing for the first time often does not know the research exists at all.

Then there are the people the sector exists to serve, and their families, working out what good support should look like.

The centre set out to serve all 3 groups from one place: practical guidance on one side, the evidence underneath it on the other.

Our part in the work: technical leadership and Drupal delivery

A partner agency engaged us as their engineering partner on the build, while the relationship with the centre and the shape of the programme sat with them.

We provided technical leadership, architecture, platform engineering and ongoing maintenance. We also set the delivery process the build ran on:

• automated code quality checks
• automated tests over the journeys that matter
• a release cadence the team could plan around

An evidence base that stays where it is curated: a feed, not a rebuild

The most consequential decision on this project was about where the evidence lives.

The straightforward way to build a research library is to build one: a content type, an editorial workflow, and someone keeping thousands of bibliographic records tidy forever. We took the other route.

The centre's evidence base is curated in an established open-access research archive, by a team that has specialised in exactly that for 2 decades, and the hub consumes it. Records keep their attribution and their permanent links, so the collection stays whole and useful outside the hub as well as inside it.

That meant being a good neighbour to another organisation's system. A nightly sync that asks a partner to serialise its whole catalogue and then discards almost all of it becomes someone else's problem.

We built the feed the other way around, so the hub says what it already holds and asks only for what has changed. The library stays current, and the cost to the source stays flat as the collection grows. For a client, that is the difference between an integration that stays cheap to run and one that becomes a standing cost.

What the audiences got: a filterable evidence base

On the practice side, the hub carries best-practice guides, tools and professional development material, organised around how practitioners approach the work rather than how the material was produced.

On the evidence side, every record is a complete bibliographic entry:

• authorship and publisher
• publication details
• journal and peer-review status
• licence and subject

That depth is what makes the library filterable rather than merely searchable, and faceted search is the part practitioners lean on most.

One property matters more than the rest. Records carry their accessible-format status as a first-class, filterable field rather than as a tag, because a real share of this audience depends on those formats to read at all. Someone can ask the library for material they can actually read.

Built on an open-source design system, accessibility checked on every build

The hub runs on an open-source, accessible, component-based design system whose engineering we had led before this project began. Custom component work went only where this product genuinely differs from any other site: the filters that drive the resource library. Everything else came from the design system as it ships, which is the whole economic argument for using one.

Accessibility is checked continuously rather than at the end. On every build, an automated test reads the site's own sitemap, visits each landing page and records what it finds.

Because it discovers pages instead of working from a fixed list, a new section is covered the day it goes live, not the day someone remembers to add it to a test.

Both dates held: the first release on its promised day, the full hub early

The first release, for practitioners, went live on the date promised at the start. The full hub, serving every audience, arrived ahead of its date at the end of 2025.

2 delivery dates named at the start. Both held, and the second landed early.

Saying it plainly is the point: described, then built, then shipped, on the days that were named. For a client, a date that holds is the difference between planning a launch and hoping for one.

It has been live and in use ever since, and we are still the team on it:

• a steady release cadence
• design system upgrades
• search improvements
• accessibility fixes as they surface

For organisations whose evidence has to reach the people who use it

Everything on this page is 4 of our services running on one live knowledge platform: architecture that decided where the evidence should live, a migration that keeps it current without burdening the archive that curates it, accessibility checked automatically on every build, and ongoing support and maintenance since launch.

If you run a research centre, a peak body or a not-for-profit whose knowledge has to reach practitioners, this is the shape the engagement takes: one architectural decision about where the collection lives, a feed that keeps it current, and delivery dates named before the work starts and then met. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If your evidence base is scattered across reports, journals and someone else's archive, and you are weighing whether to rebuild it or feed from it, tell us where it sits today.

A community radio station's website is its second transmitter, and its archive

It carries the station's daily work:

• listeners find shows through it
• presenters publish through it
• members subscribe through it

Behind the front page sits what makes a specialist music station what it is: the record of every track it has ever put to air.

Someone catches half a song on the drive home and searches for it 3 days later. That only works if the history is still there and still addressable, which makes the back catalogue both institutional memory and the long tail of how a station gets found.

The station is member-supported and largely volunteer-run, and its presenters are volunteers with their own shows. A platform that needs someone performing a manual step at 9pm on a Tuesday will quietly stop working, because the person who would perform it has a day job.

Our part in the work: architecture, engineering and archive migration

A partner agency holds the relationship with the station and brought us in as their engineering partner. We have worked alongside their team since 2024, across the strands that make up the engagement:

• the solution architecture for a purpose-built radio platform
• the platform engineering and custom Drupal development
• the migration of the station's broadcast archive
• the build and deployment tooling the platform runs on

At the centre of it is a purpose-built radio platform for Drupal(Opens in a new tab/window). It models programs, episodes, presenters and tracks as first-class content, keeps them in step with the station's podcast platform, and serves the schedule wherever it is needed.

Its architecture documentation sits beside the code, so understanding how the platform works does not depend on one person's memory.

The website drives the recording hardware: from timeslot to podcast

This is the part we like best. Drupal is the system of record for the broadcast schedule, and it pushes that schedule out to the station's podcast platform, which records the live broadcast off air, cuts it into an episode, and syncs it back into Drupal as a published podcast.

So a producer changes a show's timeslot on the website, the recording system reconfigures itself, the broadcast is captured, and the podcast appears on the site. Nobody logs into the recording platform. Nobody has to remember.

For a client, that closed loop reads as staff time you do not spend: the step between a schedule change and a published episode does not need a person standing over it. The pattern travels well beyond radio: wherever an operational process hangs off a content change, the same closed loop is worth building.

Keeping the whole archive findable: staged migration and 301 redirects

Well over a decade of broadcast history sat in the station's legacy system: what was played, on which show, on which night. Moving a history that deep into a CMS is not a routine content migration, and the tempting shortcut is always to keep the recent years and let the rest go.

We kept all of it, and built the migration so that keeping it all was the safe choice rather than the brave one:

• the history lands in staging tables first, so the migration reads local data rather than a remote API
• the harvest is resumable, picking up cleanly after an interruption
• it runs newest first, so a partial run still leaves the site current
• every legacy track URL gets a permanent redirect, so years of links from blogs, forums and search results still land where they should

That is the difference between preserving an archive and merely storing one. For a client, it reads as traffic kept rather than lost: the links people already have, and the results already indexed, still land on a page.

Well over a decade of broadcast history kept whole, with a permanent redirect on every legacy track URL.

What listeners and presenters get: a persistent player and a fortnight-ahead guide

The live stream plays in a player that keeps playing as you move around the site, so browsing does not cut the music. Around it sits what a station needs to publish:

• a program guide that runs a fortnight ahead
• a playlist on every episode of what actually went to air
• a gig guide that turns submissions from the public into published events
• news and artist interviews

Access is shaped around how a volunteer station really runs: each presenter manages their own program's episodes and playlists, and the people coordinating gigs, interviews and promotions get exactly the access they need.

Built to be handed on: automated tests, accessibility checks and Vortex

A platform is only as good as what happens after the build, so this one is made to be carried on by whoever works on it next:

• automated tests covering the platform at unit, kernel and browser level
• a mock of the podcast platform's API standing in for the live service in tests
• accessibility checks running automatically on every build
• the project sitting on Vortex(Opens in a new tab/window), our open-source Drupal project template, so its build and deployment tooling is maintained upstream

Known issues are written down with the reasoning for when each will be picked up, because technical debt handled out loud is a habit worth having. Nearly 2 years in, we are still building it.

For platforms where the archive is the asset

Everything on this page is 4 of our services running on one platform: solution architecture for a purpose-built content model, custom Drupal development, an archive migration built to be resumed rather than restarted, and the build and deployment tooling underneath it.

If you run a broadcaster, a publisher, or any member-supported organisation whose back catalogue is the reason people find you, this is the shape the engagement takes: an archive treated as first-class content rather than an attachment, a migration that keeps every legacy URL addressable, and the operational steps that would otherwise fall to a person driven from the CMS instead. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are moving a long archive onto a new platform and cannot afford to lose what is already indexed, tell us what the archive looks like.

When a web address is not enough: permanent identifiers for research

If your organisation publishes research, you already know the quiet problem with links. A report goes up, people cite it by its web address, and then the site is redesigned, the domain moves, or the publication changes hands.

The citation still exists. It just no longer resolves to anything.

That is what a Digital Object Identifier is for. A DOI is a permanent handle that belongs to the work rather than its current location, so a reference made today still resolves in a decade, wherever the record now lives. For a policy research body, it is the difference between publishing on the web and publishing something citable.

The Analysis & Policy Observatory is Australia's open-access repository of public policy and research, holding more than 43,000 resources. At that scale, minting an identifier is a workflow question rather than a technical curiosity.

Done by hand, each one means assembling XML, calling the national service that issues them, and pasting the result back onto the right record.

Our part in the work: a portable Drupal module, built to a date

Media Insights, who have worked with the Observatory for many years, brought us in as their engineering partner to build it. We provided:

• the architecture
• the Drupal(Opens in a new tab/window) engineering
• delivery onto the client's managed hosting through an automated build pipeline

All of it against a specification and a delivery date agreed up front.

We designed it the way you design something meant to outlive its first installation: a portable, installable module with its own settings rather than site-specific code.

The site chooses which content type gets identifiers, and the fields already on it are mapped onto the metadata through the interface, so another site with entirely different field names can install it and map instead of forking it.

For a client, that portability reads as ownership: what you paid for is not welded to the site it was built on.

How it works for the people using it: request, approve, mint

An identifier is permanent, and that shapes everything. Once one is issued and registered with an outside authority, it cannot meaningfully be withdrawn, so minting is treated as a decision rather than a button.

The flow is deliberately short:

• a contributor who has published something requests an identifier for it
• editors see every request on a single dashboard, with the record, its published state and who asked, and mint or cancel from there
• everyone is notified at each transition, including when a request is cancelled, so "no" is a real answer rather than silence

For a client, that reads as accountability: every request has a visible state and an action attached to it.

On a workflow with a human approval step, what goes wrong is rarely technical. It is a request sitting unseen while someone waits and wonders.

Records change after publication, so the module can also submit updated metadata for an identifier that already exists. Correcting the description behind a permanent identifier is what keeps a system accurate instead of frozen on the day it launched.

Built to the standard, not to the site: DataCite metadata in Drupal

The identifier attaches to the landing page for the work rather than to the file, because a citation should point at the catalogue record, not a PDF that may later be replaced.

Behind it, the data model follows DataCite, the international metadata schema the Australian service was built on, rather than a shape that happened to suit the site. Every element has a direct equivalent in the schema, so if a record can be assembled, it can be minted. Services and resellers can change over the years without the model changing underneath them.

A rule we carry into any integration of this kind: whatever an outside authority issues has to survive an ordinary save. An identifier that quietly vanishes when someone updates a record can fail silently, and the loss may not surface until the day someone tries to cite the work.

What it adds up to: a delivered module and a partnership still running

The module was delivered and accepted, and it went into service minting identifiers against published records.

A repository of more than 43,000 resources, and a partnership still producing work nearly a decade later.

The more durable outcome is the relationship. This was the first thing we built with Media Insights for the Observatory, and nearly a decade later that partnership is still producing work drawing on the same catalogue.

A small, tightly specified integration is often the best first project a partnership can have: finite, checkable, and a fair predictor of how the next one will go.

For publishers whose records have to outlive their URLs

Everything on this page is 3 of our services on one tightly specified integration: architecture modelled on an external standard, Drupal development shaped as a portable module, and delivery onto managed hosting through an automated build. Work of this shape, bounded and specified before it starts, is also where AI-assisted delivery earns its place.

If you run a research repository, a university publishing arm, or a government body that publishes evidence, this is the shape the engagement takes: a specification and a delivery date agreed up front, a workflow your editors can actually work, and a module you can take with you.

If you are working out how to get permanent identifiers onto what you publish, or you are minting them by hand today, tell us how you publish.