Why are we building Mediapapa

We’ve spent our careers inside WordPress, as users, contributors, and builders. Some corners of the platform have largely stayed the same while everything around them changed. Mediapapa is what we are building to change one of them: the Media Library experience.

What we’re building

The WordPress Media Library has been stable for years. Reliable, yes — but stability and usefulness aren’t the same thing.

The Media Library tab exists. Most users open it once, find what they need by scrolling or searching, and close it. There’s no reason to come back — no way to understand what’s actually in there, what’s unused, what’s slowing things down, what’s referenced nowhere. It was built to list files. It does that. But the way people work with media has changed a lot since then: more file types, higher quality images, stock photos from Unsplash, Pexels or Openverse, embedded GIFs, podcasts, videos. The average media library today looks nothing like it did a decade ago. The gap between what’s built in and what teams actually need has quietly grown.

Mediapapa is how we’re trying to change that. Not by patching one specific problem, but by thinking about the media library as a whole.

For our product, it means opening your media library and actually understanding what’s in there, what’s healthy, and what needs attention, without having to do it manually. And then giving you tools to fix what needs your action.

Why we built it

After years of building complex WordPress projects at Be API, we’d seen the same pattern repeat: media libraries that had quietly grown beyond anyone’s control, and no reliable tool to deal with it. Rename a file, track where it’s used, audit what’s broken — each time, it required custom work or compromises. Not because the teams were disorganized. Because WordPress never gave them the tools to stay on top of it.

WordPress core moves carefully — and rightly so. A change that ships to millions of sites has to work for all of them, from a simple blog to a large editorial platform. That kind of scope means the media library gets maintained, not reinvented. The basics work. Everything beyond that is left to plugins.

We looked at what existed. Some plugins solved one specific problem well — image compression, or file renaming, or duplicate detection. But nothing treated the media library as a whole. Nothing was built for teams who had been living with a real library for years and needed to understand it, clean it up, and keep it under control.

That’s what we decided to build.

Building at a transformational time

The web is moving fast. WordPress is evolving fast. The block editor keeps maturing, the admin will change, and the way people build and manage sites is on the verge of a significant shift.

A different pace of content

AI and automation is changing the pace at which content and media get created. What used to take weeks now takes hours. Images, videos, audios, generated assets, excerpts, metadatas, the volume is no longer the bottleneck. The bottleneck is everything that comes after: integrating the tools, maintaining control over what gets published, reducing the time between an idea and a live page.

More content, more to manage

That shift changes what a media library needs to do. A site that used to grow slowly over months can now accumulate content in days. The need for workflow, visibility, and organization hasn’t disappeared, it’s become more urgent. More content means more to manage, more to audit, more room for things to go wrong.

Built to stay close

The needs that matter aren’t always the ones people talk about openly. They show up in the workarounds teams build around missing features, in the manual steps nobody has documented, in the friction that slows things down without anyone naming it. That’s exactly where we want to be active and make things better.

Building for what comes next

That means staying close to how WordPress evolves, following the block editor as it matures, watching how the admin changes, and understanding how real teams work with their media day to day. It also means building with feedback from people who are actually using the plugin, not from assumptions about what they need. The problems we’ve seen at Be API across years of demanding projects gave us a starting point. The people using Mediapapa are what keeps it moving forward.

We’re building the tools you’ll need to navigate it.