Go slow & build good things, with Rob Moore from Churnkey
Rob Moore evaluates dev tools as a buyer, not just a seller — and his real framework isn't time versus money, it's time versus energy. A tool that saves hours but demands days of learning an unfamiliar API wrapper can lose to one that's simply less exciting but takes ten minutes to install.
Rob Moore is the co-founder and CTO of Churnkey, a tool for cancellation flows and failed-payment recovery that started as an internal tool built to fix a 10-13% monthly churn problem at a previous company.
We get into the energy-versus-money framework he uses to evaluate dev tools as a buyer, why Churnkey ditched schema-based API docs for plain text and copy-paste examples, how he actually discovers small indie dev tools on Twitter, and his contrarian take on 'ship it before you're ashamed of it.'
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did Churnkey actually come about?
It started as an internal tool for a podcast marketing company I was working on called Wave. We had a serious churn problem — 10-13% month over month — and threw everything at it, including tens of thousands of dollars on outside consultants, over six to eight months trying to figure it out. What ended up working, far beyond what we expected, was a cancellation flow that took into account how customers were actually using the product and presented dynamic offers at the point of cancellation — pauses, discounts, trial extensions. Before we sold Wave, that flow had already cut our churn by a substantial margin, and we liked it enough to productize it starting in early 2021. Today Churnkey also handles failed payment recovery, or dunning — when a customer's card needs updating, we send an automated retention campaign to help them fix it easily.
Dunning has existed as a category for years. What was the actual opening for Churnkey there?
Dunning tools have been around for six or seven years, with a handful of competitors, and the market had genuinely gone stale — not much real innovation. We took what we'd learned building personalized, real-time offers into the cancellation flow and applied the same thinking to failed payments: instead of just prompting someone to update their card, we can say update your card now and get 30% off this invoice, plus 20% off your subscription for the next couple of months.
As a developer evaluating other dev tools to buy, what actually drives your decision?
We often assume developers are purely rational — this will save me time, so I'll use it — but I think it's much more about energy and excitement than pure logic. It's less a time-versus-money equation and more a time-versus-energy one. Code is uniquely scalable: you write something once at your kitchen table and, in principle, 10,000 companies can use that exact same code. To actually get someone to adopt it, there needs to be real activation energy — either you're removing something genuinely painful, like billing logic that everyone hates writing and testing, or you're introducing something new that's exciting enough to be worth learning. The harder and more painful the problem you're solving, the more excited I personally get about a tool, because I know almost nobody else wants to solve it themselves either.
How do you weigh how much a tool saves you against how much you have to learn to actually use it?
You have to be honest about the energy required to implement something, not just the time it saves once it's running. If you wrap Stripe subscription handling in a simplifying API, that's genuinely useful, but I still have to learn your API wrapper — that's a real cost. Great marketing and compelling use cases can get someone over that activation-energy threshold, willing to spend two or three days integrating and learning a product properly. But something like Churnkey isn't inherently exciting — nobody wants to talk about churn — so the real lever available to us is making the energy required to install it as low as humanly possible. A useful pattern I've seen work well elsewhere is giving a tool a small, specific entry point you can integrate quickly, then letting people expand into the bigger surface area of the product once they're already in.
What have you specifically done at Churnkey to lower that activation energy?
Documentation, obviously, but it has to actually be done well. As a small team building for potentially thousands of customers at once, every hour you spend debugging one customer's specific issue is an hour taken away from everyone else — so you have to be relentless about turning any repeated support request into a documentation or UX fix instead. I'm more bearish on 'engineering as marketing' and more bullish on engineering as customer support: good error logs and genuinely clear UX do more scaling work than content ever will.
Documentation often falls behind the actual product. How do you keep it in sync?
We used GitBook for a while, which works fine but is enough of a hassle to edit that we simply weren't updating docs as often as we should have. We switched to Super, which wraps a Notion page — you edit a normal Notion doc and the changes show up on the docs site in real time. That ease of access has made a huge difference: if I'm troubleshooting something with a customer and realize the docs need updating, I just do it right then instead of making a mental note and forgetting about it a week later. We also moved almost entirely away from schema-based API documentation, like OpenAPI or Swagger — technically correct, but a genuine pain to actually use. We're now roughly 70% plain text and 30% examples, almost no formal schema. Showing a concrete example that developers can copy and adapt to their own use case works better for everyone than abstractly describing every parameter.
Do you think AI coding assistants like Copilot change how documentation should be written?
It's something to watch. I was recently working with the HubSpot API on calls I'd never used before, and Copilot already knew the correct syntax — a real advantage for HubSpot, since it meaningfully lowers the burden on developers using their API. It's possible that putting good code examples directly in a public GitHub repo becomes part of a documentation strategy in itself, since tools like Copilot can pick them up. That mostly benefits products that have been around long enough to have examples in the training data — a brand-new product won't get that benefit yet.
Can you walk through a recent example of a dev tool you personally decided to buy?
I recently switched to LogSnag, a small logging product built by a solo developer. The entire pitch is radical simplicity — instead of something like Sentry or CloudWatch trying to automate everything for you, you just hit an API endpoint with a log name and category, and there's a clean dashboard to see events flow in. As a developer, you already know exactly what you want to log and pay attention to for your specific problem — you don't need the tool to guess for you. That simplicity pitch, being the deliberately simpler option compared to something more automated and complex, is what sold me.
How did you actually discover LogSnag?
Twitter, which seems to be the real hotspot for indie developers and small SaaS builders. The creator was sharing UI he'd built as he went — a form of building in public that's less about broadcasting MRR and more about sharing the actual product development process, which I find much more interesting, being someone who cares a lot about good UI. I found another tool, Wobaka, a simplified CRM, the exact same way — not a dev tool specifically, but the same underlying mindset: with so much choice everywhere, something that does one job very specifically, without being overweighted with features, at a reasonable price, is genuinely compelling.
Is Twitter a viable marketing channel for developers building small tools, even though marketing doesn't come naturally to a lot of engineers?
I think so, and it's not natural for most developers to put on a marketing hat and actively sell what they're building — I've personally always fallen for the 'build it and they will come' fantasy. It's just not true. You can build the best software in the world and it still needs marketing. The small dev tools that succeed have generally found a real marketing strategy, and a lot of them found it on Twitter specifically. I have a startup from four or five years ago where I put all my effort into building and basically none into marketing, and it's genuinely frustrating to build something great that goes nowhere purely because nobody heard about it.
There's a popular startup mantra that if you're not embarrassed by your first version, you shipped too late. You seem to disagree.
I go the opposite direction — go slower, build things you're genuinely proud of, and share your process along the way. Especially as an individual developer, if you build something you're not proud of, it's really hard to come back to it on a weekend when you don't have dedicated time to work on it; a half-finished, embarrassing project just doesn't pull you back in. If you're hesitant to share something because you know it has real holes in it, that hesitation compounds — it's harder to share, which slows down feedback and growth even more. Taking a craftsman's approach, building something you'll still be proud of three years later, actually makes it easier for developers to keep sharing their small projects as they grow, rather than something optimized purely for shipping speed.
You've talked to a lot of founders about churn since launching Churnkey. What's the biggest gap you see between first-time and repeat founders on this?
Churn is a problem every company faces — you can build the best company in the world and you'll still have it, and it's just not as exciting as growth or landing new customers, even though retaining an existing customer is far cheaper than acquiring a new one. Second-, third-, and fourth-time founders almost never question this — they get into a Churnkey demo and immediately know they want to either build something like it or buy it, because they already understand the outsized effect churn has on the bottom line. First-time founders are naturally more excited about growth, which is completely understandable, but usually need more convincing to invest in churn reduction through dynamic cancellation flows and failed-payment recovery.
What's a concrete tactic companies can use to actually reduce churn?
Dynamic point-of-cancellation offers — think of what Audible does when you go to cancel: they offer a pause, or a bonus credit, and it's far more effective than I ever expected. It reframes cancellation as something other than a black-and-white moment where a customer clicks cancel and you assume they're just gone — it's actually an opportunity to refresh the relationship. That matters even more during an economic downturn, when churn is up across the board for nearly every company we're connected to. Positioning your company as understanding that budgets are tight right now, and meeting customers in the middle for a few months while their situation improves, can be genuinely effective, especially for B2C products.