A few months ago, I wrote about how AI is disrupting the build-vs-buy equation in SaaS. I argued that the real value of SaaS over most DIY software is knowing what good looks like. But a few recent events have made me realize that knowing in and of itself is not enough.
“Good” changes. Users evolve, surrounding systems shift, and expectations rise. And the rate of change somehow continues to increase, making us feel the technological jerk of products in our daily life. Building something valuable requires knowing what good looks like today. Maintaining (or even increasing) that value requires caring enough to keep learning what good will look like tomorrow.
In a conversation with Betty Junod on my podcast Third Loop, we discussed the idea of an application with an Ideal Customer Profile, or ICP, of one. Betty’s point was that the cost reduction that comes from an agent building your app makes it reasonable to build an app that only you will use. This is liberating for people who have an idea or need, but previously lacked the coding skill or resources to make a computer do things they considered useful.
If you are the ideal customer, you know what good looks like and understand the constraints because you are the only user. But what happens when you’re building for more than just one customer? The challenge is the same whether you are building an app to store your recipes or a service to monitor VM utilization. As the number of users increases, answering what good looks like becomes more challenging. Humans have the amazing ability to solve the same challenge with incredible variety. Your definition of good may vary slightly from your next user’s. As the number of users grows to hundreds or thousands, the variations—and resulting complexity—can multiply rapidly.*
*Yes, humans can use em dashes appropriately.
Choose Your Own Adventure
In the old world, this is where DIY often broke down. You’d add personalization or customization, but it had a cost, both in the building as well as maintaining the increasing complexity of a system. For many SaaS companies, this led to narrowly scoping the ICP and then expanding features over time to meet the needs of more people.
This approach was sustainable for the SaaS provider, but meant that users had to conform to the provider’s view of the workflow. It also meant that providers built new features against rigid, explicit user stories and happy-path workflows.
In this new world of free code, what if we could let the user build the experience they wanted? Give the user access to the agents that build the features. This starts to change the way we think about designing products. We may need to think more about designing primitives and building blocks and not just a single fixed user path.
Of course, as we look to acknowledge that each user is a snowflake we quickly realize that different users care about different things. A default setting for one user may be appreciated, while for another it is a deal-breaker that ruins their experience. Some users want a product to make all the choices for them, while others wish they could have control down to the bit level for every interaction.
Put another way, sometimes you want to buy a pre-made sandwich, and sometimes you want to bake your own bread from the wheat you harvested and milled yourself. And most people, most of the time, are somewhere in between. We are finally at a point where we can build for—and with—users across this spectrum.
So, as we build our choose-your-own-adventure platforms, selecting good defaults and caring about what good looks like over time is what keeps a growing user base happy. It’s great to have a computer make all the choices for you when they are the choices that you want. But building a system that makes all the right choices remains aspirational. For now, we can try to build systems that adapt to our personal “right” choices faster than we have in the past.
Ever-Changing “Good”
Another critical aspect of this is that “good” can change over time. In 1440, when Gutenberg made the first printing press, his list of requirements was a bit different from the last laser printer I purchased from Costco. The rate of change that is acceptable to the user is also a factor. If your ICP is slower to adapt to change, either by comfort or regulation, you need to plan accordingly.
How do you ensure that your product or service continues to be good? How do you monitor for drift—either in your product quality or in your ICP needs? Product quality isn’t just your uptime. Users rarely use products in a vacuum, especially SaaS. Other services provide input and users need the output to feed into other places. And the needs of these inputs and outputs are changing faster today than ever before.
At the end of the day, knowing what good looks like is a point-in-time judgment, while caring about what good looks like is an ongoing task. You have to spend effort observing and processing usage patterns and feedback. Even as we build a platform that can be augmented and updated by our users, we still have to observe and listen to both new and existing users and incorporate learnings into our design and build process. This means your product is never “done” or “finished.” It also means that, as a builder, you may have to let go of the idea that your product will be used the way you intended.
Free, Like Puppies
Puppies are not free. Food, toys, vet visits, and time all add up, regardless of the initial cost. This has long been a comparison used for open source software. And it needs to be acknowledged that unrestricted customization can have the same risk.
In this new era of “I can build anything,” this often means you first have to make a choice, “do I care enough about what good looks like for this product to own the maintenance and upkeep?” This isn’t just about upgrading, patching, CVEs, and performance (although that is a big part of it). Handing users the controls to change your product also runs the risk that they’ll make changes they regret. Or, when the choice is good for the user, it may restrict your optionality in the future if desired core product changes break their customization.
Different types of people have different tolerances for build-vs-buy. There are people like Josh, who look at the world and say, "I could build that myself," and then do. Or people like my brother who will pay for other people to build everything. And then some who tinker in between. Either way, someone still has to feed the puppy.