Why we built Magpiie

Magpiie didn't start as a startup pitch. It started as a Notion doc full of complaints. We were running content production for a media studio, juggling 40 active drafts across 12 clients, and the workflow was held together with Slack threads, color-coded spreadsheets, and a lot of caffeine.

We tried every tool on the market. Frame.io was too heavy for our team size. Wipster felt thin. Vimeo Review was a feature, not a workflow. Google Drive was where good intentions went to die. So we did what every frustrated team does: we started writing scripts and Notion templates to glue the gaps together.

When the workaround becomes the product

The breaking point came on a Friday at 11 PM. A client had approved V3 of a launch video. Then the brand lead chimed in with a "tiny tweak" that required a full re-edit. We had no record of who approved what, no way to surface the unresolved comments from V2, and the editor had to scroll through a 400-message Slack thread to figure out what the client even meant.

That weekend, we sketched the first version of what would become Magpiie. Frame-accurate comments. Versioned approvals. Carry-forward feedback. State machines for every note. The features weren't novel individually: they were obvious. What was missing was a single tool that put them together for the workflow we actually had.

Built by the people who use it

Every feature in Magpiie traces back to a moment of pain in our own studio. The Compare view came from re-watching V3 with a stopwatch to see what changed. The "Won't fix" state came from a client who kept resurfacing the same note we'd intentionally rejected. The activity log came from the inevitable "wait, who approved this?" that ends every project.

What being the customer changes

Building for yourself is not automatically an advantage: plenty of tools are built by people who stopped doing the work years ago. What it buys you is a shorter feedback loop on your own mistakes. A feature that sounds good in a planning doc and is annoying on a Friday deadline gets found in the same week, by the people who shipped it.

• Reviewers never needed an account, because our clients would not have made one
• Comments had to survive a new version, because ours never did
• Approvals had to name a version, because "approved" alone had already burned us
• The empty state had to be usable, because most projects start at 11 PM

What we deliberately have not built

We are not trying to be the whole pipeline. Magpiie does not edit, host, store, or manage your project plan, and every quarter someone asks for one of those. Saying no keeps the review surface fast, which is the only thing we are actually trying to be best at.

We're not building Magpiie to disrupt anyone. We're building it because we needed it. If it solves the same problem for you, and we're betting it will, that's the product.

"Build the convenience we couldn't find."

The complaints, and the features they became

It is worth being literal about this, because "built from experience" is something every company claims. Each item below started as a line in that Notion doc, written in frustration, and each one is now a specific piece of the product.

• "Nobody can tell which file is current." Became auto-stacked versions with a visible status on every draft: Draft, Editing, In Review, Changes Requested, Approved.
• "The client wrote a paragraph about a moment I cannot find." Became frame-accurate comments, plus freehand drawing for the notes people cannot put into words.
• "I do not know whether this note is being worked on." Became the five states, and In progress in particular.
• "We already decided not to do that." Became Won't fix with the reasoning attached, so a rejected note stops resurfacing.
• "Did the fix actually land?" Became Compare, which ghosts the previous round's notes onto the new cut so you verify in one pass.
• "Who approved this?" Became a timestamped approval against a specific version, and an activity feed that records events as work happens.
• "The thumbnail was approved somewhere else entirely." Became one project holding video, shorts, thumbnails, scripts and audio, reviewed identically.

None of those are clever. They are the obvious answers to problems anyone running production has had. What was missing was not invention, it was a single tool that treated them as one connected problem rather than seven unrelated features.

The decisions that came from being the customer

Three choices were made early, and each of them costs us something. They are worth stating because they are the ones a company optimising for a spreadsheet would have made differently.

The first is that clients never make an account. That closes off a growth loop every investor asks about, where each reviewer becomes a signup. We could not do it, because our own clients would not have signed up, and a review tool the client refuses to open is not a review tool.

The second is flat per-plan pricing rather than per seat. Per seat is the better business model and it is also the thing that made us hesitate before adding a freelance producer for three weeks. A tool that makes you think twice before including someone is quietly shaping the work, and not for the better.

The third is that the review surface covers the whole deliverable. Video-only is a cleaner product and an easier story. But a YouTube upload ships as a cut, a thumbnail, a title and a voiceover, and approving one quarter of that is how a video goes live with last week's thumbnail.

Where we are now, and what is next

The parts that started as complaints are shipped and in daily use: frame-accurate commenting across video, thumbnails, scripts and audio, the five-state revision model, Compare with Smart Revisions carrying notes onto the new cut, and Collaboration Hub, the real-time workspace tied to the draft.

Workflow and task management is in private beta now, which is Tasks and Accountability, per-stage boards with auto-assignment and an audit trail, alongside Auto-Sync Workflow, where upload triggers assignment and approval triggers publish. Cinematic Storage and an optional AI Co-Pilot are in beta too. Further out sit Mood Boards, YouTube Analytics, Scripting Studio, YouTube Publishing, Brand Guidelines and Performance Tracking.

The direction that list implies is deliberate. We are not trying to become a better place to store video. We are trying to become the place a piece of content goes from idea to published, with review as the spine. Dates on any roadmap slip, ours included, so read them as intent rather than contract.

What we got wrong on the way

A founding story that runs from problem to product without a wrong turn is a story that has been tidied. Three things we were confident about turned out to be wrong, and each cost us a rebuild.

• We assumed reviewers wanted more controls. They wanted fewer. Every option added to the client view reduced the number of comments, because each one is a decision someone has to make before doing the thing you actually want.
• We built approvals as a project-level flag before realising it is meaningless without a version attached. "The client approved it" is not a fact unless you can say which cut they were watching.
• We treated thumbnails and scripts as attachments hanging off a video. They are deliverables with their own rounds and their own approvals, and modelling them as second-class was the reason packages kept shipping half-approved.

The pattern in all three is the same: we designed for the person who knows the tool, and the person who matters is the one who has never seen it and will not be trained. That reviewer sets the pace of every round, and they do not care about your feature list.

Why the studio still runs on it

The most useful thing we did was refuse to stop doing the work. Production still runs through the same product, on real deadlines with real clients, which means every rough edge is found by us before it is found by you, usually within a week of shipping it.

It also keeps the roadmap honest. Features that sound compelling in a planning document tend to lose to unglamorous ones, because after a Friday night deadline nobody argues for a clever addition over making the comment box load faster on a long cut. That bias toward the parts you touch a thousand times, scrub, comment, jump, mark resolved, is the whole reason the tool feels quick.

"Build the convenience we could not find."