Posts

We bootstrapped to $11 million in ARR

Image
This year Thinkst Canary crossed the line to $11M in ARR. That number is reasonably significant in the startup world, where Lemkin refers to it as “initial scale” . For us; it’s a happy reminder of Canary's spread into the market. $11M ARR certainly isn’t our end goal, but it provides the fuel for us to keep building the company we want to work at. We got here without raising a dime in capital, shipping a hardware/SaaS hybrid, sitting way outside Silicon Valley. That’s different enough from many startups that we figured it was worth a post with some thoughts on how we got here¹. Bootstrapping To be clear, we’re not anti-VCs. From the beginning though, we wanted to try bootstrapping. In the past we’ve spoken on how founder ego can nudge you towards building VC-backed companies (and why you might not need to), but that’s less focused on VCs and more aimed at founders. ( Bootstrapping, ego, and the path less travelled: 13m48s ) Launch Canary launched in mid-2015, after we worked on i

On SolarWinds, Supply Chains and Enterprise Networks

Image
The recent SolarWinds incident has managed to grab headlines outside of our security ecosystem. The many (many) headlines and columns inches dedicated to the event are testament to the security worries that continue to reverberate around the globe.  But we think that most of these articles have buried the lede.  Most discussions take the position that our enterprises are horribly exposed because of supply chain issues and that any network running SolarWinds should consider themselves compromised.  We think it's actually more dire than that (and suspect it's going to get worse). Let us lay out the case for why SolarWinds should concern you even if their tools are nowhere near your networks. It’s easy to whip up a think-piece in the wake of a public security incident, especially as a vendor. The multitude of vendor mails riding the SolarWinds incident are overflowing our inboxes. But even a stopped clock is right twice a day, and this is one of those times. An abstracted, low res

Hackweek 2020

Image
Because we can One of our great pleasures and privileges at Thinkst is that every year we set aside a full week for pure hacking/building. The goals for our "Hackweek" are straightforward: build stuff while learning new things. Last week was the 2020 Hackweek work-from-home edition, and this post is a report on how it went.  Now in its the fourth year, our Hackweek has come to serve as a kind of a capstone to our year, and folks start thinking about their projects months in advance. The previous   editions produced some truly awesome projects, and topping would be was a serious challenge. Without q uestion  this has been our finest so far. We run Hackweek for multiple reasons. We're a company of tinkerers and builders, and dedicating time towards scratching that itch just feels right to us. Of course, there's sometimes downstream benefits to the Thinkst, either in terms of the projects folks worked on, or skills they've picked up. (Replacing our Redmine with Phab

New features aren't Solved Problems

Image
One of the big disconnects in infosec lies between people who build infosec products and people who end up using them on the ground. On the one hand, this manifests as misplaced effort: features that are used once in a product-lifetime get tons of developer-effort, while tiny pieces of friction that will chaff the user daily are ignored as insignificant. On the other, this leaves a swath of problems that are considered “solved” that really aren’t. The first problem is why using many security products feels like pulling teeth. This is partially explained by who does what on the development team. The natural division of labor amongst developers means that the super talented developers are working on the hairy-edge-case problems (which by definition are edge-cases) while less experienced developers are thrown at “mundane” / CRUD parts of the system.  But most of your users will spend most of their time on those "mundane" parts of the system. It’s those common paths that are most

Small things done well¹

Image
Bad design is bad In 2015 Moxie Marlinspike pointed out that the manual page for GPG is (now) 50% of the novel Fahrenheit 451. Any software whose man page approaches 20 thousand words better have a good excuse, and GPG can only gesture vaguely at decades of questionable design. GPG gets a bad rap but it isn’t really much of an outlier. Security software has a long history of crumby, unintuitive interfaces and terrible design choices. A deep dive into the factors behind awfully designed security software isn’t the purpose of today’s blogpost, but suffice it to say there is seldom pressure from the end users. Security software mandated by a security team is often rammed down users’ throats, so it doesn’t bother being pleasant. It’ll sell anyway. We’ve worked hard to buck this trend from our first version. It’s one reason why we are one of the few pieces of security software that customers actually talk about in terms of love: https://canary.tools/love Recently, we released a major upda