My educational background is in marketing and I recently jumped back in to build some software that is tangential to digital marketing. Siteimp is a website integrity scanner that runs full scans across entire websites and returns detailed information on accessibility, content engineering, and troubleshooting information like broken links/images and sitemap problems. It also has a monitoring module so can let users use their existing Windows hardware to monitor websites (or any devices on their network that can support ping or fetch requests).
And so, it’s a very useful tool and when it’s released, it will be sold on a buy once basis.
The conundrum
One of the central and inescapable quirks of Siteimp is that it has a heck of a lot of moving parts. It’s a set of very fast robots that can find every public page on a website (within limits set by robots.txt) and run payloads against them. But that’s complicated and things can break.
It’s also meant to be the first in a series of tools and so it’s an opportunity to start defining style and what I call corporate app-wide behaviour. But… that only works if you can get a lot of feedback.
And so, complexity met a need for quality and feedback, which means really good technical support. And that meant contact forms. If you’ve been following along, you’ll know that I built a tool to collect contact form submissions from static sites several years ago. Slack has proven to be the perfect place for contact form submissions because a lot of those submissions are incredible product feedback.
So… what about using it for technical support requests inside of a Windows app?
I already had all the source code (because I built it) and so I knew Formimp inside and out. It seemed like the natural tool to use. Since it’s built for the web, it’s just an API with a front end I built before I learned to design stuff. The easiest possible implementation path would have been to just point the form to an endpoint and be done with it.
But, I had other requirements too. For example, Siteimp can monitor any application that responds to ping or fetch that is available to the machine it runs on. So, it can monitor security cameras or your website. So, you need a good way to get the messages out to the users when something goes wrong. And here’s the thing about monitoring. I’ve been on pager duty a lot in my life and 99% of the time, if you get paged, it turns into a Slack conversation. Why not just start there and cut out the middleman?
So I suddenly had this need to support tech support requests coming to a channel that I control that conflicted with a need to let users configure Siteimp to send notifications to channels they control. Without building in a way to automatically register each new Siteimp user on Formimp with a build_id and no password, the “point it to the API and be done with it” approach wasn’t going to work. And, I’ve got to tell you, the thought of setting up Formimp accounts at build, managing all of those users on a server and handling support for that would have really really sucked.
But again…. I solved 90% of the problem before, so had something to stand on. It only took a couple of days, but I rewrote Formimp (the necessary parts) in Rust. When I dug into the desktop environment, a lot of the stuff I needed for the web didn’t really apply. For example, there is no antispam. So in other words, if you would like to send me spam without any filter or restrictions and get a response, all you have to do is pay me for my application. It’s a win-win.
And so weirdly, between something I call the HelpDrawer, and how I envision modals would look if they had been invented by blind or sight impaired people, Siteimp has pretty world class support for something built by such a freakishly small team. We have an excellent contact system that people can use without leaving the app. And internally, it means that whenever an early user has a problem, everyone knows. We don’t silo off tech support somewhere and hand it to a student. Tech support is inherently first class because we get the requests where we engineer the product.
Formimp-desktop currently supports both Discord and Slack. And it would not have been possible to pull it off in two days if the state of contact forms on static sites would not have annoyed me ten years ago. And so to sum up this whole experience, the 78 way is excellent because you only really have to solve 1.5 problems a week to get to the 78 solutions mark a year. If you build every solution in such a way that it can be extended, after a decade, you’ll end up with 780 solutions to 780 problems. And then you get to be blown away by how often we solve variations of the same problems.