[cyco130]

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.

[lioeters]

> good tools often force you to adopt better practices

Just wanted to highlight this excellent statement. It's like having a strict type system that enforces certain rules are always met. It provides consistency and predictability.

> rethink their recruitment processes

This context is relevant to the kind of software system that was needed. To improve their processes, it was necessary to impose an explicit top-down order to the existing mess.

Malleable software, on the other hand, feels more suited for personal computing, greenfield projects, or small teams with members working independently as well as collaboratively. Particularly in the early stages of product R&D, strict rules can be a source of friction in the creative process.

Strict better practices and well-designed tools are discovered and developed through open and flexible explorations, as a kind of distillation of knowledge and experience.

[sarchertech]

I worked for a company that provided a mobile friendly job application form that integrated with major applicant tracking systems (back when they didn’t provide mobile friendly forms).

Our biggest value was getting customers to remove all the extra questions on their applications that had built up over years of management changes that no one had any idea why they were even asking.

[tablet]

The problem here is in definition. Context is quite diverse and better practice for team A is an absolute disaster for team B.

[cyco130]

Absolutely. When we started growing (I was employee #3, we were about 20 people when I left), we didn't use our own product for our own needs. It wasn't designed for a tiny startup, it would be like building a sand castle with a bulldozer.

But we started as a "boutique" company that implemented everything requested by our then small number of clients (mainly out of desperation, we were self-funded and we didn't have much leeway, we needed those clients). It was as flexible as it gets before the LLM times.

But after a while, you start noticing patterns, an understanding of what works and what doesn't in a given context. Our later customers rarely requested a feature that we didn't already have or we didn't have a better alternative of. It's not like we had a one-size-fits-all solution that we forced on everyone. We offered a few alternative ways of working that fit different contexts (hiring an airline pilot is a very different context than hiring a flight attendant). And in time, this know-how started to become our most important value proposition.

At some point we even started joking about leaving the software business and offering recruitment consulting services instead.

[cyco130]

In fewer words: It was already a fairly flexible and customizable tool. But then came a time when a client requested faster horses we could show them our car instead and they recognized the value. (And occasionally, when _they_ requested a car instead of our faster horses, _we_ recognized the value and implemented it).

[flappyeagle]

They should use different tools then.

Malleable software enables infinite variations of tools when the correct number is in the single digits.