The cost of software feels like it’s collapsing toward zero – and I’m really curious how that’s changing our sense of what software we keep in-house.
We know that coding with LLM assistance is changing the craft of software. We’ve all seen discussions about tasks that have gotten much easier (decompiling and recompiling old software), and stories from software developers who miss the joy of small revelations in code, the pleasure of making bits flow smoothly. I wrote recently about how it’s changed my prototyping practice.
For me, the biggest impact has been that I’ve been building a lot of one-off scripts and small bits of software for tasks I would have carried out by hand two years ago. I’m using that experience to reflect on how software is changing.
A great example is a small photo book creator tool I put together. I was simply scratching my own itch: I wanted to print a photo book to memorialize some incredible trips, and I didn’t like the state of the art. I vibe-coded an app that took a YAML file as input and generated a photo book as a PDF I could upload to a printer.
It took me perhaps an hour to get a first version working and the photo book in rough shape. The AI didn’t touch the photos themselves – it was still my job to choose which photos went on which pages.
I’ve put together a number of lightweight tools in the last year or so. Three of the bigger ones:
- Money Flows: I don’t quite trust third-party bank ledger tools, and they often miss concepts that were important to me. Rather than ask “how do I squeeze my data into their model,” I instead created a tool that worked with my data, my way.
- Investment Rebalances: Once every few months, I rebalance my investment accounts. By parsing my broker’s outputs, my rebalance calculator saves a few minutes of fussing with spreadsheets and copying numbers.
- Academic Paper Reader: I was feeling behind on a few conferences, and so wrote a little app that let me swipe papers that I wanted to read, dynamically reweighting as I went along: Tinder for academia. I took the results and made another tool that clustered them for quicker reading. We had some lovely reading dates.
I’m also building bigger things: my Torahmap project looks more like actual software design, and so several of these principles don’t apply to it.
Design Principles for Bespoke Software
Based on these experiences, I’ve recorded a set of design principles, perhaps reflecting some of my AI and LLM biases:
- Be the expert. I know what the photo book should look like; I know how the rebalance should act. These apps are automating routines I already have. I don’t have to accommodate other people’s special cases. The vast majority of software complexity is in trying to support compatibility and generalization, or alternate uses; I am largely immune to all of that.
- Keep AIs out of the loop. None of the apps use AI internally; the scripts could have been written a decade ago.
- Fill the low-stakes niches. I’m not having the AI implement anything where it would be disastrous to make a mistake. I can scan most outputs to validate them – “is the photo in the right place?”, “is the paper sorted correctly?” If they fail, they’re easy to fix – and just as easy to throw away, or restart from scratch.
- Design to be thrown away. While some of these apps run repeatedly, others are designed to be thrown away once they’ve fulfilled their purpose. When I do a task a second time, I fork it and start modifying.
- Stick with single-player. The system doesn’t need to accommodate collaborative features. The data can live on my local hard drive, or be gated behind inexpensive web services like Cloudflare.
- Grow only when needed. For each of these tools, I got a minimum viable version into place very quickly, and iterated as I discovered missing pieces. The first edition of the photo book gained a preview mode; the second edition gained the ability to caption the images.
My tools were easy because they were single-user, low-stakes and throwaway.
Most of what companies buy is the opposite.
The Build-vs-Buy Dilemma
This has made me wonder how the software market will change. What enterprise software is worth buying when you can build so much of it just for you?
Lots of these design principles don’t apply to the software we buy today. We used to talk about build-vs-buy as applying to the cost of rewriting or recreating the software. Now we care about different expenses.
The rough categories of software you pay for:
- Multi-user effects: Multi-user communications tools are hard for a variety of reasons. It’s technically complex to build a robust collaborative editor. The network value of using familiar tools wins over getting everyone to adopt something new. Moreover, it takes careful design to build a tool that will adapt to many different workflows. (The CSCW research community has been talking about this for literal decades.) Tools like Figma and Slack wind up being in fairly good positions here.
- Embedded Expertise (and Regulations): Tax preparation software comes with the expertise about how taxes work. Banking software comes with a host of regulations and certifications about how to properly report information. This is no longer an issue of software: this is a question of whether we want to keep that expertise in-house and jump through those regulatory hoops. Tools like Gusto are in a secure position.
- Business Critical: Anything that is necessary to day-to-day execution of the company will come with implicit or explicit service-level expectations. That, in turn, means an operations team: when you pay for software, one of the things you pay for is the technical support that will keep the service up. A great example are authentication systems like Okta: when it’s down, nobody can log into anything.
The build-vs-buy line is moving: I expect to see fewer people buying software that is designed for a single user, or for low-stakes tasks. It might make perfect sense to dump some large, complex tools and replace them with smaller utility tools – and I expect that a team of engineers working side-by-side might discover that they’ve built increasingly-different stacks for themselves.
At the same time, the line hasn’t moved for software that is collaborative, regulated or business-critical. I expect this to lead to some fascinating shake-ups in the next few years.
