Back to work
Client platformCustom WordPress platform engineering

Custom WordPress audio platform

AudioMazes

Custom WordPress audio platform with persistent playback, gated access, and secure AWS-backed delivery.

Project summary

Built core platform logic for playback state, access control, and media delivery on a client-owned WordPress product that behaves more like a streaming app than a content site.

Persistent playback, gated access, and AWS-backed delivery in one WordPress platform.

Abstract audio waveform illustration for AudioMazes

Project summary

Platform status

Live client platform

Engagement

Ongoing maintenance

Built core platform logic for playback state, access control, and media delivery on a client-owned WordPress product that behaves more like a streaming app than a content site.

Buyer-facing summary

Client problem

The platform needed gated audio playback, persistent listening history, and secure media delivery inside WordPress.

What I delivered

I built a custom WordPress audio system with playback state, access control, user progress tracking, and signed AWS CloudFront delivery.

Business result

Users could resume audio across sessions while the WordPress server avoided heavy media delivery.

Problem

AudioMazes needed to behave less like a typical WordPress content site and more like a lightweight streaming platform: long-form audio, playlists, gated content, and listening history that actually persists across sessions.

That combination falls apart quickly if it is assembled from unrelated plugins. The player, the membership rules, and the delivery layer all needed to share state cleanly, so most of the important behavior had to be custom-built.

Needed to fit inside an existing WordPress investment rather than replace the stack entirely.
No public screenshots currently available because the live platform is client-owned.

What I built

Custom audio player and playlist system

Built playback logic around persistent state, playlist ordering, and resume-from-last-position behavior tied to logged-in users rather than relying on short-clip player plugins.

Listening history and progress tracking

Recorded the events that make the product feel reliable in real use: what a user played, where they stopped, and how to restore progress when they return later.

Membership-aware access control

Enforced membership rules at the data and file-access layers so a user without the required tier cannot bypass the UI and hit a media URL directly.

AWS-backed media delivery

Moved audio delivery to S3 and CloudFront for performance and cost control, while still preserving gated access through signed URLs and expiration rules.

Custom audio player logicPlaylist and listening-history systemsMembership-aware access rulesS3 and CloudFront delivery with signed access

Technical decisions

Player state, membership checks, and media delivery had to stay in sync without constant full-page reloads.
Signed URLs and access expiration were necessary so CDN delivery did not bypass membership rules.

The hard part was coordination, not any single feature. Playback state, membership checks, and CDN delivery all had to agree with each other in near real time.

The implementation took a few iterations to keep server-side authorization strong without adding visible lag whenever a user resumed or switched tracks.

Outcome

The platform now feels like a product instead of a collection of posts and audio files.
The origin server avoids the worst part of concurrent streaming load because CloudFront handles media delivery.
Listening history became one of the most useful parts of the experience because audiobook users care deeply about picking up where they stopped.

What I would improve

If I were starting from zero, I would evaluate a dedicated media-oriented architecture earlier instead of letting WordPress absorb streaming-adjacent responsibilities over time.

WordPress works well here as the existing CMS and membership shell, but you can feel where the platform ends and the custom system begins.

Tech stack

WordPressPHPAWS S3AWS CloudFrontCustom Audio Delivery

Next step

If you need similar work, let’s talk through the constraints first.

The useful part of a project like this usually starts before code: understanding what the CMS should own, what should live in a backend service, and where integrations or automation can stay maintainable.

Start a conversation