Developer marketplaces with Robin Warren, founder of Corrello & Blue Cat Reports
Robin Warren gave himself a hard rule while hunting for his next idea after redundancy: it had to be a genuinely recurring problem worth at least £30 a month, or he'd abandon it within a week. Corrello, a Trello reporting dashboard, only passed that test because a friend's marketing agency happened to complain about pulling data out of Trello.
Robin Warren is the founder of Corrello, a Scrum and Kanban dashboard for Trello teams, and Blue Cat Reports, a general-purpose Trello reporting tool — together spanning ten Trello Power-Ups.
We get into the strict rules he set himself while searching for an idea after taking redundancy, how a single guide to the Trello API became one of his best-converting blog posts by proving to developers exactly how much work they were about to sign up for, and why the Trello Power-Up marketplace becoming open to third parties was the single biggest inflection point in the business.
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.
What's the actual story behind Corrello and Blue Cat Reports?
Before this, I was a software developer and effectively CTO — I probably gave myself that title running a development team of about 15 people at a 40-person company. I took redundancy right around when my first child was born, which meant the evenings-and-weekends side projects I'd been building for years without traction had to stop, so I used the redundancy money to try building something properly. I tried a few different things before settling on what became Corrello, which wasn't originally aimed at developers at all, but became focused on building for Trello within a couple of months. It took off, and I kept finding more opportunities in the Trello ecosystem, partly because we already had the code, understood the users, and had a mailing list of Trello users to work from. Corrello is the Scrum and Kanban dashboard — burn-down charts, cycle time, cumulative flow diagrams. Blue Cat Reports came later as a more general-purpose Trello reporting tool, once we noticed a lot of Corrello signups weren't really dev teams and were getting confused by the terminology.
Reporting seems to be a consistent thread through your whole career. Is that a coincidence?
Not really — I'd always worked in reporting before this. My first company built the data systems and reporting tools behind UK general election coverage for the BBC — not the swingometers themselves, but all the data infrastructure behind them, and the screens producers and presenters like Dimbleby were actually looking at. The company right before Corrello, where I spent about 11 years, built reporting systems for public sector performance management. So by the time I got to Corrello, I already had a strong sense of what works and what doesn't in reporting tools.
How did you actually land on the Trello idea after redundancy?
Honestly, a fair amount of chance, combined with deliberately increasing my surface area for luck. I was digging through old side projects, contacting active users, pitching ideas to a mailing list, trying things for about a week at a time in a very manual way, and killing anything that showed no interest, because I was burning through savings with no income. I ended up helping a friend with a marketing agency for a day, essentially doing the job a lead developer would do to help him figure out what to hire for versus what to just buy. Getting data out of Trello was one of his offhand complaints, not a pitch to me — and it took a full 24 hours after going home before it clicked that this could actually be a product. Luck had to basically hit me over the head, but I'd put myself in a position to notice it.
Is there a repeatable version of that idea-finding process?
What I'd do now is go to meetups for marketing teams, or whatever kind of team, and ask people: if I said you could have a free developer for two months, what would you have them build? A lot of businesses have problems they assume a developer could fix, and often they're wrong about that, but framing it that way surfaces real pain points you wouldn't get by asking a software company what to build — they'll just tell you to build their own product. Ask people running small local businesses instead, and somewhere in there you'll find a technical problem worth £30 or £40 a month to them.
You wrote about the rules you set for evaluating ideas during that period. What were they?
The core rule was that it had to be a genuinely recurring problem for the customer, not just a recurring charge for me. Plenty of products get launched with SaaS pricing where the only truly recurring thing is that the founder wants money every month — if churn is through the roof because people subscribe once and cancel, it's because the underlying problem wasn't actually monthly for them. I also set a price floor, something like £30 a month at the time, because it forces honesty: if you can only really justify charging $5 for something, you need enormous volume to make it work, and that ruled out about 80% of my ideas immediately.
You've also written about not spending too long polishing something nobody's asked for. How did that lesson actually land for you?
I think most people intellectually know not to over-build before validating, and I probably knew it then too — but I still had to learn it the hard way myself rather than by being told. I spent real time writing thoroughly tested code for something, launched it, and got crickets. I still lean toward actually building the thing rather than just a landing page with an email signup, though — a landing page only tests whether people will give you an email address, not whether they'll pay. If something takes a year to build, sure, find a shortcut to test the idea first. But if you can build a real version in a month or two, that's a much better test than a fake landing page, especially early on, when you don't yet know what the product even needs to be, and so you can't yet know how to sell it either.
What did the very first version of Corrello look like, and how did you find early users?
Corrello started as a tool specifically for my friend's marketing agency — they had a Trello board per client, several freelancers writing content, and every week someone had to manually comb through every board to catch tasks freelancers had missed. The name is literally 'collate' plus 'Trello,' which was my wife's idea after I'd suggested a string of terrible ones. I built it in about two months, showed it to my friend after the first week, and he said he needed it immediately — that pressure, with no guarantee I'd ever make money from it while burning savings, was one of the most stressful periods of the whole business. I went to Bristol agile-coach meetups and tried cold outreach to my old mailing list, and got maybe seven active beta users out of all of that, only one of whom, my friend, ever became a paying customer.
What actually turned things around after that slow, quiet start?
I gave myself a deadline: launch on Product Hunt and Hacker News, and if there was no real interest after a week, kill it and move to the next idea. I used to tell people at Bristol startup meetups exactly that — I'm giving this two more weeks and then binning it — and they'd tell me I needed to talk about changing the world instead, but that's genuinely how I saw it: an experiment, not a mission. It did surprisingly well on Product Hunt, top five most of the day, and the Hacker News Show HN post brought in one or two thousand trial signups on our free tier. That immediately broke the product's architecture — the Monday morning report was built to reload a user's entire Trello history from scratch every time, which was fine for seven users and would have taken two weeks to process one week of data for two thousand. I spent the next weekend re-architecting it just to keep the emails going out.
Even with that traffic spike, how did you find the customers who'd actually pay?
Almost nobody converted to paid immediately, so I started emailing everyone and asking for 15 minutes on a call — getting someone to agree to that is a much stronger signal than getting them to sign up with an email address, because it filters for people who either genuinely enjoy chatting or have a real, important problem. About half the people I talked to were marketing folks who love trying new things on Product Hunt but didn't actually have a real recurring problem I could solve. The other half were product managers, CTOs, or the one developer on a team informally acting as Scrum master — people who cared about managing an agile process and got genuinely interested that we had any Trello reporting at all, even without dedicated agile features yet. That's where the real signal was: people who, when I mentioned $40-80 a month, said that was nothing for a team of 20 developers, because they had a clearly defined, painful problem — wanting proper reporting without forcing their team off Trello onto something like Jira.
How much did the Trello Power-Up marketplace launching actually change things for you?
Enormously. The marketplace didn't exist until January of the following year, so that entire first year was blogging, occasional Reddit posts and ads, and a lot of building with no reliable channel. I was close to broke and looking at getting a job again right around when the marketplace launched and things started ticking up. Without it, this probably would have stayed a modestly profitable side project rather than a real standalone business. Once it existed, feature requests became a natural, self-organizing priority list — someone would ask nicely for cycle time, or complain angrily that we were charging $30 without it, I'd agree and build it in a week or two, they'd convert, and the next person would show up with the next sensible request. It kept me from being overwhelmed by too many priorities at once.
Is a platform marketplace generally as good a growth channel as people say?
It's a free channel almost anyone can enter, so there's no guarantee of real visibility once you're in it — when the Trello marketplace launched, there were seven third-party Power-Ups; there are around 300 now, many directly competing with mine. Being early into a marketplace is genuinely valuable, and it matters whether the platform actively promotes it — Trello has consistently pushed Power-Ups in front of their users, whereas something like Stripe's marketplace, or app marketplace, exists but I've never seen it actively surfaced to users the same way. Worth checking, before betting on any marketplace, whether the platform itself is actively driving traffic into it or just letting it exist quietly.
How much marketing do you do outside the marketplace itself?
Not a huge amount, historically — more in the last couple of years since I've hired people to handle development and support, freeing me up to experiment. Nearly everyone I've talked to who builds for a platform marketplace says the same thing: 90%-plus of leads come from the marketplace itself, which is exactly why it can work well as an 'engineering as marketing' play if you can build a genuine integration for one. I still experiment outside it, but I expect the marketplace will keep being the majority source regardless.
You wrote a Trello API tutorial that ended up converting really well. What made it work?
It was a quick-start guide to using the Trello API to build a basic chart — downloadable code examples, how to get your API keys, how to pull some numbers out. Trello linked to it, and I also listed it on a developer API directory site, which sent a solid amount of organic traffic since people searching for Trello-related content found it well through Google. The people landing on it were often developers tasked with building something like a burn-down chart for their team, who'd spend an afternoon following the tutorial and come away realizing exactly how much genuine effort a proper burn-down chart, let alone a cumulative flow diagram or cycle time report, actually takes to build well. At that point they could tell their manager: pay $30 for this, or pay me two weeks to build a worse version of it. I built it mostly because I had the knowledge and needed something to write about — it converting that well only made sense in hindsight.
That sounds a lot like Adam DuVander's 'Jedi developer mind trick' concept — showing exactly how to build the thing yourself so people realize buying it is smarter.
Exactly that. Every developer thinks they could build your thing in a weekend, but every good developer is also, in a productive sense, deeply lazy — that's why you don't write the same thing twice, why you reach for existing libraries, why you refactor code to make it reusable. It's advanced laziness, really. So if something turns out to take longer than a weekend, a developer generally doesn't want to build it themselves after all. Showing them exactly how to build it, in enough real detail that they feel that time cost directly, is what gets them to say: let's just buy it instead.