Building ContentMK: From Scattered Tools to One Platform - ContentMK
How managing two real websites with duct-taped-together tools led to building ContentMK — a desktop content management platform born from years of hands-on publishing.
I’ve been publishing content professionally for years. Not the “thought leadership” kind — the kind where your mortgage depends on organic traffic, affiliate revenue, and sponsored content actually performing. I run two very different sites: MK Library, a niche resource site, and The Weekly Driver, an automotive publication. Both live in WordPress. Both generate revenue. Both need constant attention.
And for a long time, I managed them the way most publishers do: badly.
The Spreadsheet Phase
It started with a Google Sheet. One tab per site, columns for URL, title, target keyword, last updated date, status. I’d open it every Monday, scroll through hundreds of rows, and try to figure out what needed work. Half the dates were wrong. A quarter of the entries were for articles I’d already deleted. The status column was a fiction.
I’d update a post on WordPress, forget to update the spreadsheet, and spend the next month thinking that article still needed attention. Or worse — I’d update the spreadsheet but not the article, and convince myself the work was done.
If this sounds familiar, you’re not alone. Every publisher I’ve talked to has some version of this spreadsheet. And every one of them knows it doesn’t work.
The Tool Sprawl Phase
So I started building tools. Not “ContentMK” — just quick internal utilities to scratch specific itches.
MKL Content Tracker handled article inventory for MK Library. It pulled data from WordPress, tracked article ages, and flagged stale content. It worked, but it only knew about one site.
TWD Content Tracker did the same thing for The Weekly Driver, but with automotive-specific metadata — year, make, model tracking, coverage gaps across manufacturers. Completely separate codebase. Completely separate database.
FSM Content Dashboard was the overview tool for Frog Stone Media, my publishing company. It tried to give me a bird’s-eye view across both sites. Revenue data, content velocity, upcoming deadlines. It pulled from both trackers but was always slightly out of sync.
FSM-CRM handled the business side — guest post clients, sponsored content orders, invoicing, collections. It had its own database, its own UI, and no connection to the content tools at all.
Four tools. Four databases. Four maintenance burdens. And they didn’t talk to each other.
I’d be looking at a revenue report in the CRM, see that a sponsored article was underperforming, switch to the content tracker to check its SEO data, then open WordPress to actually make the fix. Three windows, three logins, three mental models. For one task.
The “Just Build It” Moment
The breaking point was mundane. I was trying to figure out which articles across both sites hadn’t been updated in over six months, cross-reference that with which ones had declining search traffic, and prioritize them by revenue impact. It required opening four tools, exporting three CSVs, and spending an afternoon in a spreadsheet pivot table.
That’s when I realized these weren’t four different problems. They were one problem — managing content at scale — that I’d been solving piecemeal because I’d never stepped back to design a real solution.
ContentMK is that solution.
What Makes ContentMK Different
Most content management tools are built by developers who read about content management. ContentMK was built by a publisher who does it every day.
It’s desktop-first because latency matters. When I’m reviewing 200 articles across two sites, I don’t want to wait for a cloud service to load each page. ContentMK runs locally. SQLite database on my machine. Express API on localhost. Full-text search returns in milliseconds. The app opens instantly and stays responsive no matter how many articles I’m managing.
It’s modular because not everyone needs everything. MK Library needs SEO tracking, internal link management, and content planning. The Weekly Driver needs all of that plus automotive metadata and different freshness thresholds (car news goes stale faster than evergreen guides). I shouldn’t have to pay for features I don’t use, and I shouldn’t be forced into a one-size-fits-all workflow.
WordPress sync is a first-class feature, not an afterthought. Both my sites run on WordPress. ContentMK connects via the REST API with encrypted credential storage, rate limiting, conflict detection, and a full changelog. When I update an article in ContentMK, it pushes to WordPress. When someone edits a post on the site, I see it on the next sync. One source of truth, always.
Privacy isn’t a marketing bullet point — it’s the architecture. My content data, my revenue numbers, my client list — none of that leaves my machine unless I explicitly choose to enable Cloud Sync. There’s no telemetry by default. No cloud account required. I can export everything at any time. When you’ve built your livelihood on your content, you don’t want it sitting on someone else’s server.
Built on Real Workflows
Every feature in ContentMK exists because I needed it. Content health scores exist because I got tired of manually auditing articles for freshness, SEO, and link quality. Auto-status detection exists because I kept finding year-old posts that nobody had flagged for review. The WordPress Sync Engine exists because maintaining a content tracker that’s separate from your CMS is a recipe for stale data.
The Interlink Manager exists because internal linking is one of the highest-ROI SEO activities, and nobody does it systematically. Content Planning exists because my “idea backlog” was a mix of sticky notes, bookmarked tweets, and draft emails to myself.
Even the AI integration came from a real need. I use Claude Code for research and analysis. Being able to query my content data directly from the AI — “which articles on MK Library haven’t been updated in 6 months and have declining search traffic?” — saves hours of manual digging.
From My Desk to Yours
ContentMK started as tools I built for myself. The decision to turn it into a product came from a simple observation: every content publisher I know has the same problems I had. They’re all maintaining some version of the spreadsheet. They’re all toggling between too many tabs. They’re all spending time on content administration instead of content creation.
The difference is that I spent years building and iterating on solutions across two real websites with real traffic and real revenue. ContentMK isn’t a theoretical product designed by committee — it’s the tool I use every day, refined by the kind of problems you only discover when your business depends on it.
If you’re managing content across one site or ten, and you’re tired of the spreadsheet-and-browser-tabs approach, take a look at what ContentMK can do. It was built for people like us.