David Mytton - Arcjet and console.dev
A friend's dev tool tried to sponsor David Mytton's newsletter while it was still pretty rough. He sent the money back. Console.dev has never been pay-to-play, and returning that sponsorship is the proof.
David Mytton is the CEO of Arcjet, which helps developers protect their apps once they're in production — bot detection, rate limiting, email validation, attack protection — built into the application layer itself rather than sitting at the network edge like Cloudflare or Akamai. Before Arcjet, he spent four years running console.dev, a newsletter and podcast built entirely around trying out developer tools and writing short, honest reviews of what he liked and didn't.
We get into why he thinks go-to-market is the genuinely hard part of building a dev tool compared to product, what he's learned about writing technical content that actually gets read, and the very specific discipline he's built around documentation and onboarding — down to why he thinks the CEO should personally sign up for their own product every single week.
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 does Arcjet actually do?
It helps developers protect their apps once they go into production. There's lots of tooling for pre-production — static analysis tools like Semgrep, GitHub's code scanning — to stop you writing bad code in the first place. But once you push to production, you're typically relying on something like Cloudflare, Fastly, or Akamai for network-level protection, and those are great tools, but they're not built for developers — they sit at the network edge, don't know anything about your application code or the context of a request, and you can't test them locally. You'll write your app, push it to production, turn on the security layer, and it breaks things. Arcjet sits inside your application instead, at the middleware layer and in your API routes, so you can test it locally, in staging, and in CI — then in production it handles things like rate limiting, bot protection, email validation, and attack detection.
What kinds of problems bring people to Arcjet specifically?
Developers aren't usually thinking about security challenges in the abstract — they're facing a specific problem once their app is live, like spam signups, people creating loads of free accounts, or wanting to give different rate limits to paying customers versus everyone else on their API. We're seeing a lot of use of bot protection and dynamic rate limiting tied to pricing plans or who's logged in. A concrete example: sending SMS for two-factor auth is expensive, and if someone's spamming your verification flow, that costs you real money — you want to rate limit that, but you also don't want to just brute-force block everything on the network, because a human might submit a form twice by mistake. Arcjet gives you signals in your own code so you can change your app's logic based on what's detected, rather than a blunt network-level block or allow.
You've built two companies in this general space — Server Density before, now Arcjet. What's the throughline?
Server Density, which I started in 2009, was a server monitoring product, like Datadog or New Relic before either of those existed — I sold it in 2018. After that I did a master's in environmental technology focused on sustainable computing, then wanted to get back into tech and started console.dev because there wasn't really anywhere developers could go specifically to discover good tools — Hacker News has interesting stuff, but no way to filter for devtools specifically or know what's actually worth your limited time. I spent four years trying tools every day and writing very short reviews — about 200 characters on what I liked, 300 on what I didn't. In parallel I was getting into the security side, doing hacking challenges, and started wondering what developer tooling for security actually looked like — there was plenty for pre-production, but nothing like the Vercel or Supabase of security, where the developer experience is the whole point. Arcjet came out of prototyping that, using a WebAssembly component that runs server-side in the SDK so a lot of the analysis can happen locally with high performance.
There's a story about you returning sponsorship money to a friend's dev tool. What happened?
Console only reviews things I genuinely like, and I applied the same rule to sponsorship — you can pay to prioritize us looking at your tool sooner, since we have a long backlog, but you can't pay to be in the newsletter if it isn't good enough yet. A friend's tool sponsored us at an early, pretty rough stage, and I sent the money back because it wasn't quite good enough at the time. I kind of copied this from Tim Ferriss — it feels like the ads on his podcast are only ever for things he actually uses, even the ones he's paid well for, and that integrity is what lets an audience trust you. When there is a sponsored review in the newsletter, it's still an honest one, with what we like and don't like, and it's always something I think is worth the reader's time. Products evolve, so it's not permanent — but it has to earn its place.
What's your actual process for writing technical content that works?
My goal is a blog post a week, and I encourage the team to write too, though it's hard to get engineers to do it since it's not really their job and writing prose is a different discipline from writing code. The posts that do well are usually about something that took a long time to solve technically. A recent example: we wanted to add redaction to our Go logs so we're not storing IP addresses and personal data long-term for compliance reasons, and the obvious approaches using Go's reflection API weren't performant enough — they added a couple of milliseconds, which sounds small, but our API's SLA is 20 milliseconds for a full security decision, so that's a real chunk of the budget. I spent real time finding a better approach and wrote about it, and people now Google for that post because it's a genuinely hard problem. Until you've written about something, I don't think you've fully solved it — writing forces you to actually understand it.
Which companies do you think get technical content right, and why?
Supabase is excellent at technical blog posts, Fly.io and Tailscale are really good too — they talk about their product, but really they're talking about the interesting technical problems they solved. Cloudflare is a great example even though they're a competitor to us: their blog is run by their CTO, who has final say on everything, and they go into real technical detail about running a network of 300-plus data centers handling something like 15 million requests a second. Developers love that, and it's been a great recruiting mechanism for them, as well as a way to attract people who'd want to use the product. The common thread is that it isn't content in the SEO-fluff sense — it's genuinely interesting technical material people want to read, the same principle that applies to video and podcasts, which are both important but very slow to grow.
You've said the CEO should personally test onboarding regularly. Why?
Onboarding is the one thing every single user goes through, but once your team builds it, almost no one on the team touches it again. I think there's something to having the CEO own that specifically — sign up for your own product on a new email address first thing every Monday morning and see what it's actually like. Docs and quick-starts drift out of sync with releases constantly, not through malice, just because a docs PR gets missed under time pressure, and someone needs the responsibility to catch that regularly. I compare it to a border agent at passport control — if you've just been on a 12-hour flight, that first interaction matters enormously, and it's the same for a developer with limited time trying to solve a problem with your product.