The software industry is awesome but sometimes I get frustrated by it. It feels like all our best engineers are tied up building programs-for-programmers-to-program-programs-for-programmers.
There’s a whole real world out there and it’s really interesting! I rebuilt a warehouse management system for a steel distributor recently. One of the columns in the orders table in the legacy database was “Eye to Sky”. I had to know more! When I asked the internal stakeholder what it was about he told me that most customers don’t have the same kind of heavy lifting equipment on site that the distributor does in the warehouse. If the order is for a 5 tonne steel pipe, they need to make sure it’s in the right orientation when they load it onto the back of the truck. If it gets there and it’s horizontal when the customer needs it to be vertical it might as well not be there. The only option is to turn the truck around, bring it back to the warehouse, flip it over with the crane and drive it back out there. Eye to sky.
That legacy application was a hodge-podge of Access over MSSQL written by well-intentioned amateurs. The business had grown around it to the point that it was a national enterprise with 4 warehouses in different states and the system was just buckling under the load. The company found it really challenging to attract decent engineers to the problem because it just didn’t look sexy enough.
If we as an industry want to “make the world a better place” we’re going to need to start interacting with that world a little more. I’ve made a conscious effort to turn my practice outward and solve problems beyond the tech industry. I’m not curing cancer or ending poverty, but I’m choosing not to build the multi-language, multi-backend task queue abstraction that’s been floating around my brain.
Over the last 12 months, among other things, I’ve built and launched Clubman. It’s a booking platform built specifically for ski clubs. These are membership organisations that operate one, sometimes up to 5 or so, buildings in a ski resort. They have a fixed number of members who pay an annual fee to be part of the club, then book nights in the lodge to go on their family skiing holiday. It’s a small niche that, if you take a minute to look at it, has some really interesting engineering challenges.
1. Spiky load
The way most clubs operate is to open up bookings for winter at a certain time and date. It’s then a land-rush for all of the members to try and get their preferred holiday dates before they get snapped up. In our opening round for our pilot client we processed 60 bookings in the first 11 seconds. For that brief period of time, Clubman processes more bookings than AirBnB. Doing that reliably takes some careful engineering work. The back end is written in Go with lots of attention paid to using the (PostgreSQL) database efficiently. I load test using seige and benchmark with Go’s native tooling. It’s hosted on Kubernetes (GKE) and I’m very excited to look harder at Knative once Cloud Run is available in more regions.
2. Client variability
Every club is different. Really, really different. They have all kinds of different rules about how many nights you’re allowed to book, how much things cost, whether you can bring guests and on and on. They have multiple rounds of bookings that then have different rules, multiple classes of membership with different rights in different seasons and it just keeps going.
The platforms that are already out there handle this with a consultancy model. If you want to use their platform you engage their developers to build you custom modules in their system that implement your club’s rules. I took a systems approach to the problem and implemented a Rules engine with Triggers and Actions. Basically a GUI-driven DSL that club administrators can use to configure arbitrary sets of by-laws and booking rounds. Striking the right balance between flexibility, usability and debuggability is hard work. It’s every bit as interesting a challenge as optimising a news feed.
3. Budget
This isn’t a billion dollar market. This will never be a billion dollar product. Brute forcing the solution space with a cast of thousands eating VC funded catered lunches is not an option. Engineering is about constraints and solving the technical challenges of a product while keeping costs within reason is both difficult and rewarding. Clubman uses a Test Driven Development approach to ensure we ship the right code. This means we don’t have a customer support team. Clubman uses plain old server-rendered HTML based on the Materialize component library with a little Javascript sprinkled around for interactivity. The fact that we don’t use a front-end JS framework like React or ship a SPA means that sometimes the UI/UX isn’t as smooth as it could be. The tradeoff is that we can ship new features fast and iterate quickly.
Notbad Software is a single shingle business. I work with some great specialists from time to time but I write every line of code, make every sales call and send every invoice. It keeps my overheads down and makes it possible to address markets like this. It also keeps me interested because I always have to be learning new things.
Think about what else is out there. Don’t look down on “small problems” or “insignificant markets”. They’re the things that make up the world.
And if your ski club needs a booking platform that doesn’t suck, check out Clubman.
Big thanks to Sam Gentle for his help on this post.
— David Banham, Notbad Software
