At Mocoda, we spend our days building for other people: websites, apps, and digital products for clients who trust us to deliver. Every so often, though, you build something for yourself, and that turns out to be the most honest project you will ever run, because the client is you and you cannot spin yourself.
ContentForge is that project. It is a desktop tool we built to run our own content: take an idea, draft it with AI, edit it like humans, publish it, and turn it into the dozen little pieces every platform wants. We built it because we were tired of renting that workflow from half a dozen subscriptions that did not talk to each other. Here is what shipping it taught me, and most of the lessons had nothing to do with AI.
Why We Built Instead of Subscribed
The honest starting point was not a grand vision. It was annoyance. Our content workflow lived across a writing tool, an image tool, a scheduler, a transcription service, and a handful of browser tabs held together with copy and paste. Each one was a monthly fee. None of them knew about the others. And every one of them wanted our content, our brand voice, and our clients’ material sitting on their servers.
Build versus buy is a decision I have made a hundred times on client projects, and the answer is usually buy. Your time is worth more than the thing you would build, and someone else already maintains it. But the calculus changes when the tools you would buy do not fit how you actually work, when the subscriptions stack up faster than the value, and when the thing you are handing over is the one asset you cannot afford to leak. That is when build wins. This was one of those times.
Why It Runs on Your Machine, Not in Our Cloud
So we made a deliberate choice: ContentForge is a desktop app, and everything runs on your own machine. There is no ContentForge cloud, because there are no ContentForge servers. Your drafts, your brand voice, and your clients’ material never leave your computer. Your API keys live in the operating system’s own keychain, not in a database we control, because the most secure place to put a secret is somewhere we can never see it.
That one decision rippled into everything. You can run it entirely on local AI models, free and private, or plug in a cloud provider when you want more horsepower, and you are never locked to a single vendor. And there is one line we refused to cross: ContentForge never fires content out to your social platforms on its own. It builds every piece, sizes every image, writes every caption, and then tells you it is ready. You decide what actually goes out. Automating the busywork is the point. Automating the judgment is how you wake up to a mess you never approved.
The Gap Between the Plan and the Product
Here is the part most people leave out of the build-it-ourselves story: the tool we shipped is not the tool we spec’d. It never is. The interesting work was closing the gap between the two, honestly, one decision at a time.
A few of those decisions:
- We wanted to publish straight into every platform. One platform had no door. We planned a clean, direct connection to each content system our clients use. For most of them, that worked. For one widely used website platform, there simply is no public way in for blog posts, no matter how badly the spec wanted one. So instead of faking it or pretending the feature existed, we built an honest workaround and documented exactly what it is and what it is not. The spec does not get a vote when reality says no.
- We planned to bundle our own AI voices. We shipped the ones already on your computer. Turning a post into a short video needs a voiceover, and the original plan was to ship sophisticated neural voice models inside the app. Then we asked a simpler question: what is already on the machine? Every modern operating system ships perfectly good voices for free. We cut the heavy approach entirely. Smaller download, nothing to maintain, no cost, good enough. Cutting it was the right call, and it was still hard to delete code we were proud of.
- It was built for us. Then we had to make it for anyone. The first version was quietly full of Mocoda: our folders, our defaults, our workspace baked in. Turning a personal tool into something a stranger could open and understand meant tearing all of that out and building a real first-run experience. That is the unglamorous tax on every “we built it for ourselves” project, and it is usually bigger than you expect.
There were quieter gaps too. The automated scheduler worked perfectly until we hid the window, at which point the operating system throttled it to save battery, and posts that were due did not go out. The fix lived deep in the plumbing, not in anything a user would ever see. We ended up writing more than a hundred automated tests, and most of them guard precisely these boring, invisible edges, not the shiny features. That is the last ten percent nobody demos, and it is usually where the real work hides.
The Lessons Were Old Ones
None of this was new. These are the same lessons thirty years of project management already taught me, just wearing different clothes:
- The spec is a hypothesis, not a contract with reality. Your job is to find out where it is wrong as fast and as cheaply as you can.
- Cutting scope is not failure. Insisting on the bundled voices, the perfect connector, and the flawless first version would have meant shipping nothing. Saying no to good ideas is how the necessary ones get finished.
- Honesty scales. Every place we wrote down what the tool does not do, instead of hiding it, is a place future us, or a future user, does not get burned.
- The last ten percent is the job. The demo is easy. The thing that still works when the window is hidden and the battery is low is the actual product.
The Bottom Line
ContentForge runs our content at Mocoda now. It does the boring parts so we can spend our attention on the parts that need a human. But the more valuable thing it produced was not the app. It was a reminder that the discipline of shipping, deciding what is in, what is out, and what reality will not allow, matters far more than the technology you ship it on.
That is also the whole idea behind ThirtyYearPM: practical, local-first tools built by someone who has actually shipped them, for project managers who would rather have something real than something hyped. ContentForge is the first thing out of that workshop. It will not be the last.