Firepype

Startup 01. Drop a file into a folder and Firepype handled the rest: encoding, tagging, uploading, everywhere it needed to go. First for video, then for podcasts.

Ran

Late 2012 to early 2016

Team

Three of us, nights and weekends

Funding

None. Zero outside money.

Built for

Video creators, then podcasters

We’d be up at 5 AM on a Sunday.

Back in late 2012, I was spending my weekends working with a few large churches that were doing full-scale, live multi-camera video productions. Set up at dawn for three back-to-back services, each an hour or more.

And after that? The real grind started. Taking all that footage, encoding it a dozen different ways, and pushing it out to every platform. YouTube, Vimeo, Facebook, FTP servers, internal archives, you name it.

Every destination had its own quirks. One needed MP4s at a specific resolution. Another wanted FLVs with a totally different bitrate. One required an FTP upload. Another had a web uploader that only worked in Firefox.

It was exhausting. And I knew I wasn’t the only one. This was happening every Sunday at churches, media teams and agencies all over the world. People were burning out just moving files around.

It was clearly a broken workflow. So I started asking: what if we could automate the whole thing?

The magic black box

That’s where Firepype was born.

Cloud drives like Dropbox and Google Drive were just starting to go mainstream. Video hosting sites were getting more mature. It felt like the perfect moment to build something that automated media distribution from start to finish.

The vision was simple: drop a file into a folder, and Firepype would handle the rest. Encoding, tagging, uploading. If you knew where a file needed to go and what format it needed to be in, why not build a pipeline that did all the heavy lifting for you?

You drop something in one side, and clean, processed media pops out the other.

So I mocked it up and pitched the idea to my brother-in-law, Michael. He jumped in, and over the next year he built version one. It watched cloud storage folders, picked up new files, processed them, and pushed them to whatever destinations we had wired in.

The first time it worked, I almost couldn’t believe it.

For someone who had spent years doing all this by hand, it felt like pure magic. A file lands in a folder and shows up on YouTube, already converted to my specs, without me doing a thing. I knew we were onto something.

Version two

Eventually Michael moved on to other projects, and that’s when my friend Jimmy stepped in and rewrote everything from the ground up.

He brought a whole new level of polish, flexibility and power to the platform. We added more integrations and cleaner workflows, and officially launched version two in the fall of 2013.

Then the podcasters showed up

At first we focused on video creators: indie filmmakers, church media teams, small agencies. But by early 2015 we saw something else bubbling up.

Podcasting was making a comeback. And guess what? Podcasters had the exact same problem, wasting hours uploading the same episode to Apple Podcasts, Stitcher, SoundCloud and the rest.

So we pivoted.

Jimmy adapted Firepype for podcast workflows. It could ingest MP3s, update feeds, manage metadata, and push episodes to all the major directories. Then he built something incredible: real-time download analytics.

At the time, most podcast platforms gave you stats with a 24 to 48 hour delay. With Firepype you could open your dashboard and watch downloads roll in live, just like Google Analytics. It was insanely cool.

Ads that never go stale

Then we took it a step further.

Because we were already running the publishing pipeline, we could do dynamic ad insertion. If a podcaster structured their show in slots, say intro, content, ads, outro, they could upload a new ad spot any time. The system would quietly recompile the episodes behind the scenes with the new ad, without touching the feed or playback.

That meant a podcaster could sell a campaign across their entire catalog, not just the upcoming episodes. Advertisers loved that. Podcasters loved that. Listeners got fresh ads instead of stale ones from three years ago. And nobody had to touch an RSS feed or re-upload a thing.

Honestly, it still feels ahead of its time.

The thing we never nailed

Marketing.

We didn’t have investors. No ad budget. No conference booths. No podcast sponsorships. Just the three of us writing blog posts, sending tweets, and hoping people would stumble across us.

We never offered a freemium plan either, which in hindsight made it harder to build momentum. The people who really needed what we built weren’t always the ones with the time or budget to experiment with a new paid tool.

By early 2016 it was clear the momentum had slowed. We were all tied up in full-time jobs, and without the funding or focus to scale it up, we made the hard decision to sunset Firepype.

What I kept

Still, I’m incredibly proud of what we built.

We solved a soul-sucking problem, manual media distribution, and gave people back their Sundays. We had real-time podcast stats before anyone else. We built a dynamic ad system that still doesn’t exist on most podcast platforms today. And we did it with zero outside funding. Just hard work, curiosity, and a lot of nights and weekends.

Firepype didn’t make it, but the lessons were priceless. Build for a real pain. Solve it simply. Stay flexible. Know when to pivot. And remember that timing and visibility matter just as much as the tech.

I still think about Firepype whenever I see all these modern tools with their little “Share on YouTube” buttons.

Yeah, we were doing that before it was cool.