Developer onboarding with Kilian from Polypane
Kilian Valkhof followed standard marketing advice for Polypane's email onboarding — send a nudge an hour after signup, email every two days during the trial — and just annoyed developers. His fix: fewer emails, sent from his personal address, deliberately ugly so they don't feel like homework.
Kilian Valkhof is the founder of Polypane, a browser built specifically for web development — responsive design, accessibility testing, dark mode and reduced-motion testing, and general site-quality checks in one tool.
We get into why standard email-marketing playbooks actively backfire on developers, the exact sequence of emails he sends across a two-week trial, why his least-fancy email consistently gets the best engagement, and why he deliberately never wrote a definitive guide to any 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.
What is Polypane, and who is it actually for?
Polypane is a browser I originally built to help with responsive design — the whole idea started from thinking it was silly to keep resizing my browser window constantly, so what if I didn't have to? Since then it's grown into a tool covering different media queries like dark mode, light mode, and reduced motion, forced colors, accessibility testing for color contrast and site structure, meta tags, and general quality checks like web vitals and HTML validation. It's become a tool for pretty much everything involved in building genuinely good websites — which is exactly what ambitious web developers want, since they're always trying to get the most out of the work they do.
You said your onboarding journey started by doing everything wrong. What did that look like?
Developers are hyper-aware of when they're being marketed to, and hyper-aware of when what a company wants doesn't line up with what they, the user, actually want — every tool promises you'll be 10x more productive, and it's never true, so developers automatically dismiss that kind of language. None of that needs explaining to a developer. But when I had to actually market an app, I did what most marketing advice tells you: standard email flows say to send a follow-up an hour after signup in case someone forgot about your tool. That doesn't work on developers — it just annoys them that you've emailed twice within an hour, once for signing up and again asking if they remember you. Similarly, advice to email at least every two days during a trial so people don't forget you exist is just irritating if someone's actually engaged and doesn't have short-term memory loss. It all sounds obvious said out loud, but I had to discover it myself through a lot of annoyed replies from developers.
What does your actual email sequence during Polypane's two-week trial look like now?
There are really two types of emails during the trial: status updates, like reminding someone they're halfway through with a few days left, and information-gathering emails, which is where most of the useful feedback comes from — a few days in, I ask what they like and don't like, and I get a huge amount of valuable feedback from that. After the trial ends without a conversion, I send an email simply asking why — which often surfaces something like 'life happened, I got pulled onto a different project,' and gives people a natural opening to ask for a retrial, which happens a lot.
Why do you deliberately keep these emails plainly designed rather than polished?
A beautifully designed marketing email, with a header and a smiling photo of your customer success rep, feels like work the moment you open it. Trying the app should be the work — the email shouldn't be. One day after signup, I send a plain email titled 'How to get the best out of your Polypane trial,' pointing to the in-app getting-started tutorial and a video of me walking through it myself, so people can either do it themselves or watch me do it. A few days later comes the 'Quick question' email asking what they like and don't like. All of these come from my personal email address, and replies land in my regular inbox — no ticketing system, no fancy logic. A lot of people are visibly surprised that I actually read and reply, sometimes within ten minutes. If I'm going to email you, you should be able to email me back and reach an actual person — that feels like a fair deal, and I work hard to make good on it.
You mentioned a customer testimonial email that outperforms expectations. What makes it work?
It's honestly my most 'fluff' email, roughly halfway through the trial, and despite my own expectations, people genuinely enjoy reading it and seeing how other companies actually use Polypane — it does very well on opens and click-throughs even though it feels like the least directly useful one. I co-write all my case studies with the companies involved, and I deliberately stick to a real, comparative pattern rather than vague before-and-after hype — you can't credibly claim things are better now without comparing to something concrete. In one case study, a company had developers do the same fixed set of monthly tasks in Chrome versus Polypane and timed themselves — 30 minutes in Chrome came down to 6 minutes in Polypane. I didn't invent that framing; the company owner just decided to time it themselves.
Isn't a claim like '30 minutes down to 6 minutes' risky, since it's so easy for a skeptical developer to go check?
That's exactly why it works — a developer could disprove a false claim like that in minutes, so you genuinely couldn't say it unless it were true. I actually tried vaguer taglines before, like 'improve your workflow efficiency three times,' pulled from other comparisons where something went from an hour to twenty minutes, or three weeks to two — and nobody believed those, again because every tool claims some multiple of efficiency that never actually plays out, since saved time usually just gets absorbed by other work. What people respond to is a real company genuinely using the tool and talking about it — and while it's obviously not going to be negative, since it's a case study on my own website, it's also not exaggerated, because developers can smell exaggeration from a mile away and there's no point trying to deceive people who'll find out immediately anyway.
What happens as the trial nears its end?
Three days before the trial ends, I send a short reminder that there are three days left, along with an offer to extend the trial if they haven't had time to properly try it — which is never a problem for me to grant. I keep these deliberately short, because I don't want to receive overly long emails myself, so I don't send them either. Twenty-four hours before the deadline is my most sales-oriented email — it links to an ROI calculator and a template letter people can send their own manager to justify getting a paid license, since a surprising number of developers don't realize they could ask their employer to pay rather than covering it themselves. The math looks very different depending on who's doing it — a developer might mentally compare the price to Netflix or Spotify and balk, while an employer looks at it as roughly ten minutes of that developer's time and it becomes an easy yes.
What happens to people who don't convert after the trial ends?
I send a link to subscribe right when the trial ends, then a check-in two weeks later asking if anything was missing or the timing just wasn't right, and a final one-time email around three weeks out summarizing what's new in Polypane and inviting them to try it again. I get real uptake on both of the later ones — some people admit they actually did convert, just using their work email rather than the trial one, which is a nice ego boost, and others come back specifically because a new feature caught their interest.
Looking back, how much better did the sequence get after you started cutting things out?
The improvement mostly came from what I removed, not what I added — an onboarding flow only works up to the point someone unsubscribes, which I obviously respect immediately. I found developers need fewer emails overall, and less frequent ones — you really don't need to email every two days. I also cut a 'want a personal demo?' email, which is standard sales advice for upselling in conversation, but most developers just don't want to spend an hour listening to someone talk about a product when they have actual work to do — only one or two people who scheduled a demo actually showed up, so I dropped it, and the rest of the sequence performed better once fewer people tuned out entirely. I also removed an appeal-to-authority email featuring testimonials from well-known developers — it can help get someone to try a tool in the first place, but once they're actually trying it, they care about what it does for them, not what it did for someone else, so it wasn't adding value mid-trial.
If you had to boil down everything you've learned about onboarding developers, what would it be?
Make sure anything you send is something your audience can actually act on, and doesn't read as something they have to immediately dismiss as overly salesy, like it came from a no-reply address, or otherwise signals 'this is just broadcasting, not a conversation.' I think of onboarding emails as a two-way street — I'm trying to help you evaluate Polypane, and you, as a developer trying it, can help me understand how to actually make it work better for you. That framing, rather than pushing content at someone who's meant to passively receive it, is the whole thing.