Malleable Software

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation.

But, at the same time, there are two issues:

- Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty intensive and expensive. And the resulting project is not always to be guaranteed to be correct. Software development is a discovery process. The expensive part is way more in the discovery than in the writing the code.

- The best software around is the one that's opinionated. It doesn't fit all the use cases, but it presents you a way to operate that's consistent and forces you to think and operate in certain way. It guides you how to work and, once going downstream, they are a joy to work with. This requires a consistent product view and enforcing, knowing when to say "no" and what use cases not to cover, as they'll be detrimental from the experience. It's very difficult to create software like that, and trying to fit your use case I'll guarantee it won't happen.

These two things tension any creation of software, and I don't think they'll go away just because we have a magical tool that can code fast.

I disagree with a lot of the assertions the article makes.

IME: LLMs don't "thrive" in messy open-ended spaces. They handle spaces like that better than traditional code, and traditional code handles structured spaces a lot better, but LLMs still do perform better in structured spaces than unstructured ones. Giving them lists of tools, schemas for data, consistent examples, etc always produces better results than not doing this.

The correlate thesis you have to make is: Do humans work better in unstructured spaces. This can be true for highly creative and individual work, but generally (and especially in the enterprise SaaS world) the opposite is true. The Structure is how you keep the users of the product aligned on one pattern of usage. E.g. giving people the ability to just create whatever ticket fields they want in Linear ends up being useless because you'll end up with 10 fields that do similar things; the friction structure introduces is necessary because while it can cost a few seconds up-front as users learn how things are done, it saves time down the line as your organizational tools (filtering, dashboards, reports, etc) are aligned on the structure.

Its also 100% the case that oftentimes companies buy SaaS tools not to solve their problems, but to help them better structure the problems they have so they're even solvable at all. Think about Sentry: The end-goal of Sentry is to solve issues in web applications, for sure. But that's not why people buy it. I could do that without Sentry; but Sentry adds structure to the errors, it adds deterministic workflows to the errors, and it provides excellent SDKs to report them. Sentry's value isn't actually in the end-goal; its value is in the structure it adds every step before the end-goal. Accelerating the inputs by adding formality to them ends up accelerating the end-goal.

For six years I worked in a SaaS startup that built an applicant tracking system (a tool to manage recruitment efforts in big/mid-sized companies) tailored for the local market of the country we lived in. My experience tells me that our main value was in forcing them to rethink their recruitment processes, not adapting to their existing ones that were usually all over the place.

As much as I want to believe the opposite to be true as a “power user”, good tools often force you to adopt better practices, not the other way around.

A lot of people been saying this lately, that LLMs are going to make SaaS obsolete because you will be able to build the alternative yourself without the need to pay.

But (and I'll copy & paste a comment I wrote a few days ago) I disagree. This existed way before LLM. Open source alternatives to most products are already available. And install them and deploy them is much easier than do it with LLMs, and you get updates, etc.

People don't want the responsability to keep them updated, secured, deployed, etc. Paying a small amount will always be more convenient than to maintain it yourself. The issue was never coding it.

For myself yes. I just have claude code running and it's replacing everything i'm doing company and personal wise with custom stuff. However, most people, like my colleagues/employees, want rigidity and do not want to learn new stuff generally. They want to focus on completing their tasks and don't want to have a quicksand saas underneath them. If it helps completing tasks faster then maybe.

Also training new people is annoying when things change too often; people can already use Jira/Linear/Monday/whatever , they don't want some completely flexible thing that is malleable.

Also, people are not all perfectionists with long term goals and visions. People who 'change' some part of their work flow that helps them NOW; they won't care about speed, scaling, deployment etc, so they will do something to make their work easier and then leave it there and possibly ignore it forever to rot. Which might have all kinds of fun implications.

I guess when we have AGI with a few 10 million+ context window for cheap, it will be different but the current llms would just leave a massive amount of rot all over the place, quickly forgotten and not usable by anyone but the original creator.

Inflexibility is the quality I desire more and more as I get older. I don't want to force my software to do dumb shit, I want my software to force me into avoiding dumb shit. This is how you keep a system understandable. That quality is far more precious than the ability to connect complicated enterprise spaghetti machines into each other.

Malleable and opinionated aren't mutually exclusive. The best products that solve non-core business processes should be opinionated, that's their value prop.

But yeah, the demand for webhooks, integration options, embedding's will win IMO. I imagine more demand for API-first products.

Is this just low code all over again, except this time with some nondeterminism thrown in?

I've been in SaaS for about 17 years, and a pattern I've seen is that for companies customers actually love, customization shows up as a milestone. It helps them find their own way of doing things, but eventually they settle into that way.

When it resonates with customers, it feels great.

Customizable SaaS is really just a side effect of the deeper need for control, because with control you can execute better. And when that lines up with capital, market fit, and a clear purpose, it creates more than efficiency, it creates meaning.

The companies that never settle, always chasing new patterns, usually end up with customers who don't enjoy them and employees who don't enjoy the software either.

I'm not sure about software that sells itself on providing a mirror for people to reflect on the structure they use for organization, but I do believe eventually the tools that are going to win are those that do text interface.

Even a visual tool like blender should expose their full GUI as a text API. It needs a bit of adapting, specifically for domain-specific structs (which should be retrievable via calls like 'select-bb' or 'select-coordinates'), but after that's done it's a game changer.

That class of software has a lot of proprietary GUI's that look slick and people are familiar with, but who cares about familiar in a world where the other software lets me point my LLM at its help file and build me whatever gui/tui/script/voice integration I can think of.

I think most of the SaaS stuff that benefits from being malleable already is malleable - just slowly malleable. I can configure a Trello or GitHub Actions in whatever way I want. Meanwhile I really want my email, messenger, or banking apps to be exactly the same every time I use them. I'm not clear how adding a non-deterministic UI or business logic layer is going to fundamentally disrupt or improve experiences like Jira or Visual Studio.

Maybe we're in some kind of local-optimal, where all project management software has coalesced around a few user journeys, and there's some better approach out there to be discovered.. But I don't see why an accounting software company, games studio, or vehicle manufacturer, would dedicate even 1% of its resources into crafting a malleable bespoke project management software toolkit.

It goes against the concept of comparative advantage, and I can't think of any successful enterprise that's bet against comparative advantage and won.

Previous discussion regarding malleable software: https://news.ycombinator.com/item?id=44237881