We started the company Squidler in early 2023, after some initial prototyping. The first public version went live in June. But the story of Squidler began much earlier than that. In this post, I’d like to look back and reflect on some of the experiences that led us here, focusing mainly on my own.
Some years ago, I started learning about property-based testing. I found it an effective way of uncovering edge cases and often outright bugs in both the design and implementation of software. Even with purely random test generation, the effect of generating test cases instead of manually defining them had tremendous utility. Later on, I started applying it to stateful systems as integration tests, which resulted in a short book on the topic.
At the same time, the ideas behind the specification system TLA+ had been occupying my thoughts. In particular, linear temporal logic, an extension of propositional logic used to describe how things change over time, caught my interest.
In the beginning of 2020, these streams of thought merged and gave rise to Quickstrom. It started as my personal hobby project but later turned into an academic research project. The results of the case study in our first paper convinced me of the effectiveness of our approach. I knew I had to dig deeper.
While Quickstrom could find a lot of problems in web applications, without requiring the user to manually define test cases, it still required a written specification. That means training engineers and spending precious time writing and maintaining a specification to match your website. That’s a tough sell at most companies.
Mattias (now our CEO) asked me, “What if it could check any webpage?” I scoffed and explained that it doesn’t work that way. Someone has to decide what is correct behavior. You have to have an oracle.
But about a year later, after having applied Quickstrom commercially, we realized that surprisingly simple Quickstrom specifications were highly effective and of relatively low cost. There were gnarly timing bugs in Javascript code, broken processing in backend systems, and much more. Such problems were found by a specification that basically said that:
It’s almost provocative in how simple it is, and it made us re-evaluate Mattias’ question with more open minds.
We formed Squidler around the idea of a service that could check any website. It aims to find bugs, crashes, broken web conventions, issues with visuals, accessibility, spelling, and more. Some of these things are already in place, and many more are coming.
The interface to the user is something we’re really proud of, too. You do nothing more than enter your website’s URL, and we reach out only when there’s something that needs your attention. Squidler explains what happened, how it might be an issue for you, and what you or your technical partner can do about it.
Finally, we’re now working on a machine learning-based runner that checks your site more effectively over time. It learns what parts of your site are worth spending the most time on, in order to maximize the number of problems found over time.
This was a brief look at how Squidler came to be. We’re excited to see what it will become, and we hope that you’ll try it out!