Building MarketOtter in public: marketing software for people who hate marketing
I've shipped software for 30 years through the dot-com bust, 2008, and COVID. In all that time, I treated marketing like a chore — something to tolerate, not build.
So I built the tool I needed.
The problem I kept hitting:
Last week, my Product Hunt integration generated full product-launch listings for what were actually discussion threads. One published before I caught it. Same week, a substring classifier was matching "ad" so broadly it flagged "threads," "dread," "had," and "bad" — which meant 32 of my 242 generated tasks were written as advertising copy instead of what I actually meant. Then I noticed follow-up tasks were dated from when posts were planned, not when they actually shipped. One post that ran eight days late created a follow-up task born eight days overdue.
Those aren't user stories. Those are bugs that surface when you dogfood your own product.
What I'm learning:
The architecture underneath is 57 independent modules — no module depends on another. That's the only way to pull one out safely when it breaks. I built a guard that flags invented statistics in generated copy, then had it accuse my own post of fabricating numbers I'd written by hand. The tool was right. I was wrong to dismiss it.
On the measurement side: one technical post on LinkedIn hit 1,730 impressions with 6 real comments. Short conversational posts on the same account, same fortnight? 75 impressions each.
What I need from you:
I'm running this through my own marketing to surface the actual bugs before anyone else sees them. But I'm also curious: what's broken or missing in the marketing tools you've tried? What made you stop using them?
If you want to kick the tires early, I'm taking beta testers. No pitch — just want to know what's actually wrong.
The dogfooding details make this unusually credible. You’re not describing hypothetical marketing problems; the product is exposing its own failures while you use it.
Another challenge I have found with it is when I do find a failure, it is often less than straightforward to turn that into a usable lesson or modification. Some things are simple bugs which are easy to fix, but more often I run into something that I thought worked a certain way (particularly when interfacing with other apps/websites) and my discovery is that it works differently. It isn't always easy to find a solution that allows me to move directly forward. Still, I would say that dogfooding like I am has been far preferential to hearing customers complain about problems they are having.
That distinction is important. A failure that exposes a wrong assumption is much harder to act on than a conventional bug, because the fix may require changing the workflow rather than the code.
It's also the most important to learn from. Bugs in code are inconveniences and small problems that resolution is rarely lifechanging. Process and workflow changes that improve things overall can be.
That distinction is interesting. I’d be interested in continuing the conversation beyond the thread — would you be open to sharing the best email to reach you on?