In this RedMonk conversation, David Mytton, CEO of Arcjet, chats security and developer experience with James Governor. They discuss the importance of integrating security as a feature in developer workflows, the challenges developers face with traditional security tools, and the need for innovation in this space. David shares insights on how Arcjet aims to make security seamless and developer-friendly, akin to other modern development tools. The discussion also touches on the startup journey of Arcjet, its funding, and the evolving landscape of developer tools.
This RedMonk conversation is sponsored by Arcjet.
Links
Transcript
James Governor (00:12)
Hey, this is James Governor from RedMonk and I’m here with David Mytton of Arcjet and we’re here to talk today about one interesting one. Not quite sure what to call it, but we’re gonna call it security as a feature for now. I think the main thing, David, you’ve got a real focus on developer experience. So tell me a bit about what’s the problem you’re trying to solve? Why is developer experience so important? and whether we’re ever gonna finally get developers to care a bit about security and building it into their applications.
David Mytton (00:49)
Developers have been used to some pretty amazing innovations over the last five or six years where developer experience has really been the focus. We’ve got new platforms being released, cloud platforms, Render, Railway, Vercel, Netlify, Fly, that really do focus on the developer experience when deploying code. And the IDE is getting better every day as well, whether it’s VS Code is the leader for a while and then it got forked and we’ve got all the really interesting AI IDEs.
And just the focus on developer experience when it comes to building and building your application and writing your code is something that developers are used to. When it comes to security,
That’s just another story and we just haven’t seen the innovation that suddenly when you go into production, developers have to use a completely separate system. It’s often point and click or it’s entirely disconnected from their code and it just gives developers a lot of headaches and the result of that is the reputation that they just don’t care about security because it’s completely outside of their workflow. It’s just not in how they’re used to doing things. And this idea of getting developers to think of security as a feature, think actually…
aligns with how developers think about everything. They’re fixing bugs or they’re building features for users, what the customer is asking for. And security should just be another feature that comes in, whether it’s asked for by a compliance team or a big customer or because it’s something you need to make sure you’re handling certain things in your application, like just filtering, validating user input. It should be thought of just like we’re integrating a database. We’re thinking about performance. We’re setting up our design. These are all just features
that developers have to think about today and security should just be another one. Unfortunately, that’s not really how most developers do it. The incentives are very misaligned and it’s often forced on them by security teams. And it feels like just toil that they have to deal with. Has that been your experience? You’ve been talking to developers? It’s just a lot of hassle.
James Governor (02:50)
Yeah, think that’s
exactly right. mean, you know, let’s face it, we’ve been through this. I mean, we’ve been talking about shifting security left for quite a while now. But it’s sort of interesting, you know, even though the sort of the players that we would associate with that idea and, know, Snyk is obviously a good example of that. It ended up being to a point, a different workflow, having to go sort of manually fill in a bunch of information.
alongside the task that you were doing. And I think, you know, we, if we’re about developer experience, we’re thinking about developer flow and yeah, so developers have definitely been faced with being given more responsibility for security or being told they had more responsibility for it. Whilst at the same time, yeah, the tool chains and the processes didn’t really map to that. And I mean, honestly,
David, and we’ve still got organizations where you’ve got a separate security organization that really is not very well integrated with what the engineering team is doing. So I think that the tools to your point have really, yes, when I talk to developers, they definitely find that security is something that’s a hassle for them.
That’s one of the reasons they’re constantly, I think, rebuilding something. And when it’s done well, you do see possibly explosive adoption effects. I if you look at Supabase making auth something that’s a little bit easier, that really drives adoption for them. So I guess the answer is yeah. When I talk to developers, the tool chains are just not… They’re just not buttery. They’re not…
They’re not the sorts of experiences, I think, as you’ve said, that they’ve been led to expect in some of the areas of their daily work.
David Mytton (04:50)
Supabase is a great example because it’s basically made the database a feature. You don’t really think about Postgres being the underlying database until you start getting into…
James Governor (04:58)
Not at all.
David Mytton (04:59)
all the advanced details later on. And Supabase has built this amazing product on top of Supabase and developers, they just suddenly realize later, oh, they’re using a database and they’re using Postgres. And that’s what we’re trying to do with security as well, is that you’re trying to solve a problem, you reach for a particular tool that solves that specific problem, but then when you look at it in detail, what you’ve actually done is you bought a security product. And.
They are very different disciplines. And if we go back to the database example, in the olden days, you’d have DBAs who would manage the database for you, deal with the schema, the performance, the upgrades. And at the extreme scales, you still do have specialists like that, but that’s not the majority of applications these days. Startups, medium-sized organizations, they’re not hiring DBAs. And security is still in that early era where it’s a completely different discipline. Often, security specialists are not
engineers or at least they’re not product engineers, they’re not usually writing code in the same way that an engineer is. And that’s just how it used to be with databases as well. And this is where I think security should go and hopefully is going, is that developers get to integrate it as part of their code just as another feature rather than it being on a completely different layer of the stack looking at different signals that have no connection to the application. Because ultimately security is all about context, it’s understanding what the business logic
James Governor (05:55)
Mm-hmm.
David Mytton (06:23)
is trying to achieve and you can’t do that if the system is entirely separate.
James Governor (06:28)
Okay, tell me what sorts of use cases that you’re actually, what are we talking about in terms of these features? Like what are the things that you’re making easier to integrate? What are the security sort of those annoying problems or annoying things to implement that you’re doing for the developer? What do you do?
David Mytton (06:49)
So we think about it as pre-prod and once you go into production. so there’s actually been some interesting innovations on the preprod side of things. As you’re writing code, this is able to tie into AI, is able to do static analysis. So interesting tools like Semgrep, for instance, or Socket for dependency analysis, that are able to give you useful insights before your code goes into production. Those are much more connected into your code. They run locally, they run in CI, and developers are able to use them. And there’s been some really interesting focus on DX there. Once we go into production, which is where I’m focused at,
it’s another story because often that is added later. It’s not connected to your application in any way and you usually can’t run it locally. It’s only deployed in production and these kind of network level tools, they analyze packets, they don’t understand users, they don’t understand sessions, they don’t understand authentication.
And what we’re trying to do when it comes to these production security issues is to build a product that can tackle those in the same way that developers are used to. So specific examples of bot detection, that’s very popular right now, particularly with AI kind of muddying the water around what is a bot and which one is a good bot versus a bad bot. But even traditional problems like sign up form spam, form spam, you just have a simple lead form on your website, then I’m pretty sure everybody has seen
the spam submissions that get sent through those. E-commerce is another example where we’ve been doing a lot of work where fraud has basically existed since the beginning of the internet and the beginning of e-commerce. And going through a sensitive checkout flow, that really needs to be connected to your business logic because the worst thing you can do is just as someone’s about to press checkout is just to block them on the network and serve them a generic 403 error.
In that case, you want to know that you’re in this flow. Maybe you know that the user’s logged in. Maybe they’re a repeat customer. Maybe they’re not. And you can then tailor the security rules based on what you know about the user. And then maybe flag the order for review, or even give it priority service and reduce the level of security just based on the characteristics of the user. And this is connected to what developers think about when it comes to security, is they are getting spam sign-ups or.
they’re getting bots scraping their website or they need to deal with email validation. To solve those, you buy a bot detection product or you buy a WAF. But developers don’t think about that. They think about the problem that they need to solve.
James Governor (09:22)
And so, well, again, specifically, so bot detection is one. What are the, you know, is there a sort of a, yeah, what is the list of functions that you’ve initially tackled so that developers, as they’re working, be like, aha, I need an X. What are the Xs? Or I need X, Y, and Z. What’s X, Y, and Z? Or Zed?
David Mytton (09:41)
Yeah, so developers typically come just for one thing, and then they’ll see that we do a load of other things. So bot detection is pretty common. So let’s take the sign up form spam example. You’ve got a form on your website. It’s a sign up to your application, and you’re getting loads of fake accounts, people abusing the service. So to solve that problem, you need to do bot detection first, make sure it’s actually a human signing up.
You need to do rate limiting to prevent multiple submissions and spam. You probably want a WAF component in there as well to protect the form in case you have made a mistake or there’s a vulnerability in the framework or the server that you’re using. And then you also need to do email verification and validation to make sure it’s a valid email, stop free email addresses if you want to, or certainly to stop disposable email addresses. And for all of these, you’ve either got to build it yourself or you’ve got to buy a product.
a separate product for each one of these categories and then you’ve got to integrate it. What we do with Arcjet is to offer each of these as individual components. We call them primitives and you can use each one individually or you can compose them to build up layers of protection. So for the form protection component, that is bot detection, rate limiting, email validation and WAF and you can integrate those all in just a couple of lines of code with Arcjet and the idea is that that solves a very specific developer problem.
It’s a couple of lines of code. You drop it in, it solves the problem, and you move on to something else. But because each of these are individual components that can be configured independently, as your use case becomes more sophisticated and you want to tweak the rules, change things dynamically at runtime, then you can do that because you have the full power of it all just being code.
James Governor (11:30)
So, well, I’ve got two questions immediately there. But if we think about as code, one of these is very notable, I think, about your platform. Let’s just say you didn’t start with Java. You are very much about modern languages, modern frameworks. So tell me a bit about your decision-making, what you feel you need to support, and I guess from that perspective, what your initial developer adopters look like.
David Mytton (11:57)
Yeah, so building this, was looking at where are most applications being built today, most new applications, and what kind of security challenges are they facing on these new platforms. So our target, the little tagline we have is developers building using modern frameworks, deploying to modern platforms who don’t have a security team, because those are the developers who are really having to solve the problem. And on these modern platforms, they are…
They’re new and they’re doing loads of interesting things, but that also means the security story is a lot less mature than, say, deploying on AWS. And they’re often also serverless environments, which makes using traditional security tools really difficult, because in serverless environments, the serverless function is going to spin up dynamically. It might stay warm for a period of time. It might not. It might recycle.
And you only have a very limited runtime environment. So you can’t install an agent, for instance, from one of the traditional tools. And often all of these platforms will also bundle a CDN, their edge network, where they do caching. And so putting another CDN in front of that CDN causes problems. It slows things down. It obfuscates the headers that get sent through.
It causes routing problems, and that’s why someone like Vercel, for instance, specifically says, do not use Cloudflare in front of us, because it causes all of these problems. And so that basically rules out all of the traditional security products. You can’t use a network proxy, and you can’t install an agent. And then these new applications are basically being built in JavaScript. It’s JavaScript on the front end, and it’s JavaScript on the back end. It might be TypeScript, it be Node, it may be Deno or Bun, but it’s essentially JavaScript.
James Governor (13:36)
Yep.
David Mytton (13:41)
And this is where a lot of the innovation has been happening over the last few years is JavaScript certainly has an interesting reputation for how fast it moves. There’s always a new JavaScript framework to play around with, which can be super annoying, but also really fun with all the new things that are coming out. But it’s the most popular language in terms of new applications. And so that’s where we started. Arcjet is literally MPM install Arcjet. It’s a dependency in your application. It’s in the package.json file. and you bring it into your code just like any other library.
James Governor (14:14)
Okay, and how does it work architecturally? I’m like, you know, I’ve got a couple of lines of code, but obviously there’s a bit more happening than that. So where does that, where does that actually happen?
David Mytton (14:24)
So the SDK bundles a WebAssembly module. And this is an implementation detail for our users. They don’t need to know about it. I think it’s super cool. It’s how we do things. But as far as the developer’s concerned, it makes no difference. But what it enables is to have a secure sandbox so we can pipe in the full HTTP request. Arbitrary HTTP is really dangerous to deal with. And so having it inside the WebAssembly sandbox, is a
a key feature of WebAssembly gives us a secure environment to do the analysis. And it also does the analysis at runtime performance equal to native code. And so we get this secure sandbox. can run the rules locally in your environment so that the body of the request, for instance, never leaves your environment. We can do all the analysis locally. One of the things we can do, for instance, is personal information detection.
And most of the other services that offer this require you to send that data out to a cloud service through an API, which I think kind of defeats the point of doing it, because you never want to handle that person. Yeah. So I think that should be analyzed entirely locally. So we can do that with the WebAssembly. And the WebAssembly module is written in Rust. WebAssembly also is cross-platform.
and although currently we only support JavaScript, we’re working on other SDKs for other languages like Python, Ruby on Rails, Java, and we can compile it once to WebAssembly, and then the work we have to do for the next SDK is just about hooking that WebAssembly component into the language runtime itself.
James Governor (16:05)
Okay, cool. I mean, think there’s still a little bit, I mean, for all the, the powerful idea of WebAssembly, there’s still a little bit of, there’s still a little bit like, we’re still kind of waiting for it to take off. Security seems like a good context for it. And that’s an interesting implementation detail from your perspective.
David Mytton (16:19)
Thank you
That’s right, I think we’ve seen some really interesting WebAssembly products. I think Figma is obviously the one that everyone always cites, just because it’s been so successful in using WebAssembly to implement their design tool. And we’ve seen startups and projects use WebAssembly for WebAssembly’s sake, rather than using it as a, because it’s the best technology necessarily. And I don’t think, I’d question how successful some of those platforms have been.
when you have to write your code to compile to WebAssembly and deploy that WebAssembly module to a cloud service. I think the server-side WebAssembly is where the most interesting stuff is happening, or least until Microsoft released their recent WebAssembly sandbox for AI tools, basically a sandbox that the AI agent can run inside. then you can, because WebAssembly has this capabilities-based model where it has basically the…
It can’t do anything by default, and you have to tell it, yes, you can access the network, or yes, you can access certain libraries on the host. And that means it is truly secure by default. And this is a real challenge with AI doing stuff by itself. An agent with arbitrary access to the internet, arbitrary access to personal information, and different APIs on the host is really dangerous. And it’s where we see a lot of the recent attacks.
And Microsoft released a Rust-based WebAssembly tool just a few months ago where the agent will run inside the WebAssembly sandbox and then you can choose what you want to give access to. So that only works because of WebAssembly, but it’s not selling it because it’s WebAssembly. And that’s kind of why I see the subtle differences. And I think that’s how we’re also using it is you’re not using Arcjet because it’s using WebAssembly.
you’re using Arcjet because of the features that WebAssembly allows us to do.
James Governor (18:25)
Right, okay, interesting. And tell me a bit more then about the, you sort of mentioned being able to run these rules locally. And I mean, you’ve even sort of, I mean, it’s definitely marketing by an engineer, David, you’re, what was the, you use the term local first? So, yeah.
David Mytton (18:26)
Thank
Local first. Yeah.
James Governor (18:50)
Tell me, I I think this is interesting. So we’ve got the notion of local first security. And I think from my perspective, it’s just an interesting one because it’s not necessarily a term that everyone’s using. But say a bit more about that as a sort of, I guess, a… as a principle and also I’m interested in whether you think it might start getting used more broadly.
David Mytton (19:17)
It’s probably a terrible marketing tagline. I think developers love it. And you see this with local first, like the consumer apps, like a note taking tool or some other tool where everything is synced locally. All your data is available on your computer, hopefully in like a plain text format so you can easily move it somewhere else. And that means it works offline and it maybe it syncs to a cloud service if you want to sync across devices. we’ve just not, consumers just don’t care. They’re not interested in it. It’s the challenge with privacy.
And the fact that consumers are very happy to use services for free in return for giving their data away, they just, on the margins people care, but really ultimately it’s not worked out as a marketing strategy. Apple is probably the biggest company that’s been able to do it, but I think it’s kind of incidental just to Apple’s philosophy that they want to run everything on the device, and so it’s local first, it’s privacy first, just in their approach. But we’ve seen that consumers generally, they’re not too interested in it, but.
And so that’s why I think it’s not a very good marketing tagline for us. And it’s not the headline on the website, but it’s in the details. And what I’ve found is that when I explain how Arcjet works, just like when I was talking about the person information detection side of things, security engineers in particular, but developers, that’s when they get it and they understand, okay, so that’s what local first means. That makes intuitive sense to me.
James Governor (20:31)
Yeah.
David Mytton (20:43)
rather than them going onto Google and searching for local first security. Pretty sure there’s zero searches for that term. But when we’re explaining it in the context of a sales discussion or going into the technical architecture, saying that we will try and run all the security analysis in your environment inside the WebAssembly sandbox first, makes sense from just the data side of things and not sending it to the cloud, but also performance. Because when you run the Arcjet SDK,
and the rules you’ve configured mean we can take a decision locally, like with the personal information detection or with the basic email validation, we can return in less than one millisecond the result. so the overhead is basically negligible. And that combination of the privacy component of not sending data anywhere and also the minimal latency makes the local first tagline work, but it doesn’t work by itself.
James Governor (21:36)
Yeah, yeah. mean, certainly, yeah, anything that reduces latency makes developers happy. I that’s, I mean, I guess all users, but developers in particular. Although we do see, I mean, it’s quite interesting living in a world where developers are back to waiting for things because, you know, waiting for agents to go off and do things.
David Mytton (21:44)
Yeah. Yeah, well that latency is like 10 seconds, 30 seconds. That’s serious latency. You can’t…
James Governor (22:03)
Yeah, but also, mean, DevTools were things that we weren’t paying for and now we are.
David Mytton (22:09)
Yeah, yeah. This is
important because Arcjet is often put in this category of runtime application security products, RASP, which existed kind of 10 years ago and basically failed as a category because the way that those products had to integrate into the code base was monkey patching code, it was causing performance problems, it was getting in the way of developers doing things, and as soon as you have a tool that’s doing something,
that may possibly slow down your application. If there’s any performance issue or any kind of problem somewhere, the developer’s gonna blame that first. And so this category of RASP just failed because of the poor developer experience, the latency and the interference with code. And whilst what Arcjet is doing is very similar in many ways, it’s completely different on the architectural side of things, which means we don’t have any of those issues.
James Governor (23:01)
Okay, yeah. So I mean, again, and funnily enough, it’s a term also not used by developers very much. One of the ways to describe it is sort of inner loop. Just being in the, well, rather than it being a separate production thing, it’s much closer to what the developer does. Okay, so I think one of the questions for me is, there are some, and look, obviously, you
Competition is what this whole business is about in a sense, solving customer needs, but there’s competition wherever you are. But increasingly, mean, there’s sorts of functions that you’re talking about providing. Whilst they may not be provided local first, they’re increasingly sort of platform concerns. expect, know, if you’re, you we mentioned Vercel, certainly Vercel, Cloudflare, they’ll be like, don’t worry, we’ll solve this problem for you.
They’re pretty good at getting people to adopt their technology. what’s your perspective on how do you build that independent story, that independent business when competing against cloud platforms is not easy?
David Mytton (24:22)
And we’ve seen this with Vercel. They added their WAF product first. They’ve added Firewall, which is their bot. They’ve got a bot protection product. And they recently just copied us with their bot ID product, which is an SDK that you install. But these are all tied to Vercel. And show me a developer that deploys to just a single place. The challenge there is you’re then tied into that platform, and you’re using that security product. Then if you decide you want to move from Vercel to fly.io,
and it’s a different architecture because you’re deploying almost a Docker container. How they do it behind the scenes is not actually Docker, but it looks like a Docker container. Let’s say you’ve got a marketing website on Vercel, you’ve got an internal tool on fly.io, then you’ve got some core infrastructure on AWS and GCP. You’ve now got four separate cloud environments with four separate paradigms on how they all do security. And whilst you could put Cloudflare in front of AWS,
you can’t put it in front of Vercel and you can’t put it in front of fly.io. We’ve partnered with Fly we’re they’re recommended application security product and the great thing about how we’ve imprinted the Arcjet SDK is it’s completely agnostic to where you’re running it. And so you can move the code from your local laptop where it runs in the exact same way when you deploy it to Vercel and then if you decide to move that same application over to Fly, you don’t have to do any changes with Arcjet.
really a truly platform independent security platform. And that’s part of the story for developers, because they’ll often start in one place and end somewhere else. Or in large organizations, there’s going to be all sorts of different platforms in use. And this is where we start to talk to security teams who need to deal with compliance across all these different platforms. They want to have visibility everywhere. They want to make sure that there’s a consistent set of rules that are deployed in every environment. And if you’ve got
four separate tools on four separate platforms, most of the security breaches that you see are due to configuration problems or holes, basic holes that you just didn’t realize existed. It’s not some amazing zero day that got through 37 layers of security and just happened to find the right floor that was sold for a million dollars on the dark web. You actually left an S3 bucket misconfigured and it was public by accident. It’s these simple problems.
And it’s because there are so many platforms, so many tools, so many configuration options. And having this cross-platform product, I think, is one of the selling points for organizations once they start to get larger.
James Governor (26:52)
Right, so let’s talk a bit about that business model. And particularly, mean, so you’re building developer experience first. You you do want developers to get excited about using the tools. And, you know, certainly if we go back, that Snyk story was supposed to be, developers will like it and they will get the organization to use it. Tell me a bit about that balance between like, when would you begin, when would you begin, you know, when does the security team
know, ping David and say, hey, my dads are saying this is, you know, about a mousetrap. We need to talk. You know, the story sounds pretty good. We’re not sending data off somewhere else. So yeah, like what’s the free tier for developers? If there is one, how do developers get started? And then when, when do the annoying security people get involved?
David Mytton (27:49)
So think about this in three separate stages. There’s companies that have no security team at all. So it’s just developers doing it when they have time. Then there’s when you make your first security hire. And that’s generally as you start to scale. So maybe series B, perhaps late series A in a startup world. And that’s where you have someone come in to start dealing with IT security, getting things sorted out from a compliance perspective. And they are probably one of the busiest.
James Governor (27:53)
Right, yep.
David Mytton (28:17)
It’s the busiest person in the organization because there’s so many things you have to deal with. And our goal at that point is that they recognize Arcjet and they know that we’ve dealt with a load of things on their checklist. And then the third stage is when there’s an actual security team. And that’s when the buying conversation shifts. The first two stages, it’s very much in the engineering side of things. It’s the developer who’s installed it. You just sign up. You click to join through Google or GitHub, whichever social login you’re using.
You can install it, npm install Arcjet, within just a couple of minutes, and then you deploy it it’s running. The free tier gives you half a million requests per month, and there’s certain restrictions on different features that you can use. And then above that, there’s basically request-based pricing, and it’s split out by the different features that we have. So email validations are built separately from the personal information detection, for instance.
So it’s request-based within quotas that we allow, but it’s a soft limit. So we basically want people to use the product, try it out, and then start having a conversation with us once they start to be successful, really. Half a million requests a month basically allows any side project to use it for free. And then you start to get into the pay tiers, which start at $25 a month for once you get into the serious usage.
When we’re talking to security teams, that is often a completely separate question. It’s product security engineering and the CISO organization, as opposed to the CTO or engineering organization. And they have very different incentives. The security organization is risk mitigation compliance. And it’s often default to no in the less developed organizations, rather than trying to enable developers.
Whereas developers are trying to solve the problems that we talked about and they’re trying to find a tool that will just allow them to move on to the next thing, deal with the customer request. And the tension comes when those teams have to interact because security is often forcing developers to do things that are not going to have customer facing impacts. They’re not going be building a new feature. They’re not going to generate revenue necessarily. And this is where we see the historic tension between those security and engineering teams.
And my hope at this point is that because the developer experience is something we focus so much time on, when developers are asked to use Arcjet or they go out and they look at different tools and they’re evaluating them, the developer experience is the thing that is the clinching factor for developers. And for security teams, it’s the fact that we can deal with all of their questions and their concerns on these new platforms. In large organizations,
there’s probably already a security organization. There’s a lot of tools that they already use and they probably have a well-defined pathway for developers deploying things. what I have seen over the last year or so is that as AI has become a mandate within organizations, developers are given almost like a separate area of the org with different permissions and the ability to buy things and use the best tools rather than necessarily using the ones that are within the normal envelope of the organization.
So that means they can pick Next.js, they can pick Vercel, and they can pick all of the really interesting cool developer tools which maybe the core organization for the core product is not using. And when they’re thinking about security, our goal is to help developers continue to ship quickly, but to do so with confidence so that they can deal with all the security challenges but still maintain the velocity that the new AI world really needs.
James Governor (31:56)
Wow, that’s a great snippet. That one’s definitely getting cut and used in social. Nicely done, So I guess one question, mean, the sorts of people that are going be interested in security as a feature, in the sort of frameworks that you support. I mean, those are largely startup people. So just tell us a little bit about your sort startup journey, where you are on that, funding round, investors.
David Mytton (32:00)
Thank you
James Governor (32:26)
Some of that, you know, I just know that the sorts of people that are going to be interested in this tooling are interested in those questions. So where are you on that journey?
David Mytton (32:34)
Yeah, so Arcjet’s raised a total of $12 million. We closed our Series A earlier this year, 2025, and the round is led by Andreessen Horowitz and Plural, who are the European fund with ex-Skype and Twilio founders there. Also participating in the round was ex-CTO and the ex-CEO of Twilio. So we’re really focusing on the developer side of things.
I’m getting experience, people who build developer first products to scale in the past. And we’ve got about 20, 25 other angel investors as well. So we’re well capitalized. The company has been around about two and a half years, founded in 2023. This is my third company. My first one, Server Density, I started in 2009, which is a cloud monitoring product. We raised a little bit of money and then sold the company in 2018 to StackPath, which was an edge security network.
I ran product engineering for them until the end of 2019 and then left and started console.dev, which is a DevTools newsletter that I’ve been writing now for five years. I know you still get it every week. Just little reviews of interesting developer tools. And through that, just playing with developer tools all day, every day, spotted this disconnect between security, which I was just doing for fun, doing hacking challenges.
And the dev tools which was having all of this innovation, all these really interesting products coming about and just the lack of anything in security, which prompted me to start playing around with different ways of implementing things, messing around with WebAssembly, and that ultimately became Arcjet.
James Governor (34:12)
By the way, everyone, yeah, just to Dave’s point, the console.dev newsletter, I mean, it’s sort of my job to keep abreast of what’s going on in developer land and keep an eye on cool new tools and communities and why they’re adopting them. And it’s a really good newsletter. you know, if you’re interested in, what I like about it is it just boils things down to…
you know, just a few things that you might consider. It doesn’t, you know, it’s not like trying to be entirely comprehensive, but it’s just, are some cool things. This is the good, the bad, and possibly the ugly. And so, yeah, no, it’s really good newsletter, and I heartily recommend that you subscribe. Okay, I don’t think we need to do the full six hour Lex Friedman style podcast today.
David Mytton (35:01)
Thank you.
James Governor (35:11)
But really interesting to hear about, I think a different approach to security, one that will hopefully appeal to the modern dev. So yeah, basically David, thanks so much for joining us today. And I don’t know if you’ve got any sort of yeah, I don’t know, final thoughts about, so the world is how it’s gonna change and why developers should come and check out Arcjet.
David Mytton (35:37)
think the motivation for developers is perhaps changing their reputation. It’s not that developers don’t care about security, it’s just they have really bad tools and they’re focused on solving problems, not buying a WAF. And so that’s what we’re trying to do with Arcjet is just to make security something that they can do in the same way as they have fun with Tailwind, making things look nice, set up a database without having to think about scaling it with Supabase, mess around with networking like with TailScale or deploy something.
quickly to 10 different regions around the world with fly.io. And those kind of really interesting taglines for each of those products, we want to do the same with security.
James Governor (36:14)
Okay, there you go. Developers do like security. They just haven’t found the right tools yet. And on that happy note, thanks so much, David. Thanks all for joining us. And yeah, look forward to you all staying on board with MonkCast. There’s gonna be plenty more great interviews to
No Comments