The Tech Stack Behind a 6-Niche B2B Content Operation (And What We'd Change)
We built this stack in public, which means we can describe it with full honesty — including the parts that have sharp edges. Here is what we use, why we chose it, and what we would change if we were starting over today.
Ghost: Publishing Layer
Ghost is our CMS across all six niche sites. We chose it over WordPress because Ghost's performance profile is dramatically better at scale, its membership and newsletter features are native rather than bolted on, and its API is clean enough to automate against without wanting to throw your laptop out a window.
We did not use Substack because it owns your subscriber list and extracts 10% of paid revenue at scale. We did not use Beehiiv because, while the product is well-designed, we needed the flexibility to self-host and control the entire publishing pipeline. Vendor lock-in on the distribution layer is existential risk for a content operation.
Sharp edges: Ghost 5.x dropped the HTML field in the Admin API. Content must be submitted as Lexical JSON, not HTML. This is not documented clearly and causes silent failures — the post appears to save but stores an empty document. We handle the conversion in our automation layer.
n8n: Automation Layer
n8n is the connective tissue of the stack. Every event that needs to trigger downstream action — a new subscriber, a published post, a hot lead crossing a scoring threshold — flows through an n8n workflow. We run approximately 12 active workflows covering subscriber sync, content pipeline, lead qualification, and error alerting.
We chose n8n over Zapier for cost and control. At our workflow volume, Zapier would cost several hundred dollars per month. n8n is self-hosted and the only infrastructure cost is compute.
Sharp edges: n8n's node parameter schemas change between versions, and documentation lags the actual implementation. We spent more time than we should have debugging parameter format mismatches. Rule now: always check the installed version's schema before building a new workflow node.
"The companies that own their data infrastructure have a compounding advantage. Every vendor you depend on is a single point of failure — and a leverage point against you at contract renewal time."
— Patrick Campbell, Founder, ProfitWell (2022)
Listmonk: Email Delivery
Listmonk handles all bulk email sends. It is open source, self-hosted, and genuinely excellent. Deliverability requires proper DKIM/SPF/DMARC configuration and a reputable sending provider behind it — we use Resend for SMTP relay.
Sharp edges: Listmonk's subscriber type field requires the value 'api' for programmatically created subscribers. If you set it wrong, the subscriber import silently accepts the record but the subscriber cannot receive campaigns. This cost us a week of debugging.
Mautic: Behavioural Scoring
Mautic sits between Listmonk (delivery) and EspoCRM (sales). It tracks email opens, page visits, form submissions, and asset downloads, and scores contacts against those behaviours. Contacts that cross our scoring threshold — currently 50 points — are automatically synced to EspoCRM as qualified leads.
The scoring model is simple by design: opens are worth 5 points, page visits 1 point, form submissions 15 points, asset downloads 10 points. We adjust weights based on which behaviours correlate with conversion in our segment data.
EspoCRM: Sales Handoff
EspoCRM receives the leads that have passed Mautic's scoring threshold. It handles everything past that point: deal tracking, activity logging, contact management. Our n8n workflows write directly to the EspoCRM API when a lead qualifies.
Dify: AI Chatbot Layer
Each of the six niche sites has a Dify-powered chatbot embedded in the footer. The chatbot is connected to a knowledge base built from published posts in that niche. Readers can ask questions and get answers grounded in our content. This extends dwell time and gives us a signal about what readers are actually curious about.
Stack Economics
What We Would Change
If we were starting over, we would spend more time on the data model before writing the first workflow. The cross-tool subscriber synchronisation logic is the most fragile part of the stack, and fragility here causes subscriber records to drift out of sync across Listmonk, Mautic, and EspoCRM. Better upfront schema design would have prevented half our operational incidents.
We would also instrument the entire pipeline from day one with Umami analytics and n8n execution logging. Debugging a subscriber who fell off the pipeline six weeks ago is significantly harder than watching the pipeline in real time from the start.
The open-source-first principle remains non-negotiable. Every tool on this list can be replaced without losing the data. That optionality is the most valuable architectural decision we made.
