Surely building software can’t be as hard as it used to be?
I have a day job that I go to four days a week: I keep Fridays for doing other things. My day job is a great job at a great company — it’s New Zealand’s biggest software success story — and (most of the time) I love it. But, with over 4,000 people in the organisation, I’m a long way from the short feedback cycles and satisfaction that comes from being hands-on with smaller and less mature businesses. On Fridays I advise a couple of early stage software companies, I act as a sounding board for a friend developing a coaching business, and I work on my own solo side projects.
I chose technology as a career because I’ve always loved the creative process of selecting, plumbing together, configuring, and writing components to solve a problem. Even though I’ve moved through leadership roles with no hands-on tech in the last ten years (aside from what I did the first year of co-founding a software startup — but that’s a different story) I have avoided becoming “post technical” by continuing to build things myself to solve problems outside work. I keep a running list of ideas (some tiny, some so big that I wouldn’t dream of tackling them unless I feel like founding an actual startup some time) that I pick from when I feel like it’s time to try something new. I read each Thoughtworks Tech Radar that comes out, and if I see some technology that interests me, I’ll try to use it on my next project.
Recently, I’ve become interested in the idea of “micro SaaS”. The term was coined by the self-styled king of Micro SaaS, Tyler Tringas. As he puts it:
…you likely know that SaaS is Software as a Service, the defining feature of which is that customers pay a recurring subscription fee for access to a hosted version of your app… And “micro” just means small. A SaaS business targeting a niche market, run by one person or a very small team, with small costs, a narrow focus, a small but dedicated user base and no outside funding. Hence, micro-SaaS.
The “micro” bit is a perfect description of what I like to do as a solo side project, and the “SaaS” bit is intriguing because it’s all about monetisation! I’ve often wondered whether it’s possible to create a portfolio of tiny, but useful side projects, that could sustain themselves as not-for-profit businesses, or even combine to create an income stream.
Getting a product to market is a whole science of its own: finding a market, building enough to fit it, finding a channel or two, making sure people in that market know about the product and the price is right, then actually collecting the money — these are hard things, and what I spend much of my day job worrying about. I’m not going to talk about them here though. My discovery process is solving my own problems, and if it turns out not many others have that problem, then that’s OK by me. Here, I am going to focus on enabling myself to be productive solving problems I want to solve with technology.
Choosing a technology stack for a tiny SaaS software product with “small” costs and no funding, with no more than a day a week available for working on them means that there are a number of problems to overcome:
- I only want to pay for what I use
- I don’t have a lot of time available for learning or building
- I don’t have time for maintenance activities
- I’m not a good UI designer or front end engineer
So how hard was it?
Back in the early 2000s, I cut my teeth as a developer with boilerplate-heavy Java frameworks, when web apps were viewed with some skepticism and before continuous integration and continuous delivery was a thing. I was accustomed to burning many hours tweaking XML files, restarting server processes, beavering away with an open source library only to hit insurmountable limitations and moving onto another one, and creating complex layers of object-orientation with “AbstractFactoryProviderFactory” and the like. I would spend hours on forums doing battle on whether Spring concerns should be in annotations or abstracted into XML files, and whether Java’s non-reified generics really solved type extensibility problems. I spent whole weekends messing around with Linux network configurations and build chains to achieve seemingly trivial outcomes, and struggled with terrible virtual private sharing providers as a way of running cheap hosting. This is 2021 though… surely we’re past all of that? Surely?
Admittedly we are past a lot of all that. I discovered Node JS and Express back in 2014 and abandoned all that strong typing and polymorphism. Creating an HTTP endpoint with a few lines of code and no heavyweight server to run it was transformational for small projects. Using a few lines of Express middleware to deal with cross-cutting concerns was a game-changer. The crazy proliferation of front end frameworks was very painful, but React has more-or-less won and there are a number of mature, reliable design systems available. The promises I was made when the first AWS evangelist visited New Zealand around 2007 have been realised, and I can now host systems in the cloud at what would have been unthinkably low costs then. When smartphones and then app stores surged into the mainstream, there was at last a way to deliver small applications to end users without having to build all of the infrastructure required to distribute and monetise “apps”. More recently, the rise of “serverless” computing brought an even greater promise to controls those “small costs” needed by micro-SaaS.
In the course of solving interesting problems with technology, I’ve been assembling a kit-set of sorts that lets me take an idea to a working piece of software as quickly and effortlessly as possible. That kit-set comprises platforms, frameworks, and tools that enable solutions to a set of architectural patterns that I find occur across my projects. My kit-set needs to address each of those problems I mentioned earlier…
I only want to pay for what I use
Even better than a few dollars a month is no dollars a month. My favourite version of this is sometimes called “scale-to-zero”. With scale-to-zero, if there is no usage of my application, then I don’t pay anything. When I’m using the big cloud platforms, this only seems fair. After all, the marginal cost for a platform vendor when I only deploy test versions and try them myself isn’t even worth raising and invoice for. If I happen to product the next Is the Ship Still Stuck then they get to scale their billing to cover their costs and make a tidy profit along the way.
I don’t have a lot of time available for learning or building
Learning curves can be brutal. We’ve all had those amazing experiences when we try something new and it just works. Unfortunately, those experiences are rare. I only have a few hours a week on my hands, so I can’t pick up stacks and tools that are going to take hours and hours to get my head around — especially if it’s going to involve swathes of trial and error thanks to poor or missing documentation. There’s a trade-off here — I’m willing to spend some time learning something if it’s going to save a lot of time building, but if there’s lots of learning and no time gained in the long run, it’s not going to fly.
“What about ‘low code, no code’?”, I hear you say. There can still be a learning curve on LCNC solutions, and there is also a heavy trade-off in terms of flexibility and control. It is something I will investigate when I get to mobile apps.
I don’t have time for maintenance activities
Patching servers is not fun. Remembering to patch servers is not fun. Setting up a server in the cloud is great fun, but then the fun ends.
Scale-to-zero is important, but just as important is scale-up. I don’t want to have to manually intervene to add capacity if I find myself with lots of concurrent users.
I’m not a good UI designer or front end engineer
I can cobble together what I think is a reasonable user experience, then I show my wife or someone else with UX talent and they tell me everything that is wrong with it, and so I go another round. Eventually I get to something I am not ashamed of and which does the job. Design systems are my friend — I wouldn’t dream of messing with SVGs or hand-cranking a new look and feel.
So… what’s in your toolbox, Gareth?
It’s a long story, so I’m going to tell it in pieces. I’ll post one article about my successful, or not so successful (yet) search for the right kit for each of the architectural patterns I like to build with. Along the way, I’ll explain a bit more about the problems I was solving and why these patterns are important, and hopefully provide enough information that you can try the approaches yourself. After all, surely building software can’t be as hard as it used to be?
