Malleable Software: Tailored Enterprise Tools Instead of SaaS Sprawl

In most marketing and technology organisations the toolbox looks the same: a dozen SaaS subscriptions, each for one area, and between them spreadsheets, exports and weekly manual work closing the gaps. Every individual tool makes sense. The sum often does not.

The reason is structural: standard software has to serve many audiences and therefore grows wide. A single team usually uses a small fraction of it — and permanently works around the rest.

---

1) Why the Buy-or-Build Calculation Shifted

Building used to be expensive, buying predictable. That logic held as long as development time was the limiting factor. When creation gets cheaper the comparison changes: it is no longer "own system versus platform" but "small, fitting tool versus permanent workaround around someone else's product".

There is a term for this approach: malleable software — software users reshape with agents to fit their actual needs. What matters is not size but lifespan: these tools are allowed to be short-lived because rebuilding them is cheap.

---

2) Where In-House Tools Clearly Fit Better

In our experience the viable cases almost always sit in the same four areas:

• Consolidating views. Briefings, approval status, asset links and campaign numbers from three systems in one read-only interface. Replaces the manually maintained weekly sheet.
• Review steps. Brand wording, claims, mandatory disclosures, format and length rules — as an automated check before approval.
• Handovers. The path from production to publication: naming, metadata, storage location, versioning. A classic home for silent errors.
• Reporting cuts. Not another dashboard, but exactly the view that supports a decision.

What in-house tools should not replace: systems with high requirements for auditability, payment processing, identity management or regulated retention. There, buying is the right decision.

---

3) The Condition: Rules Before Speed

Without a framework, malleable software produces exactly the problem you wanted to solve — just without a licence agreement. Four decisions suffice:

1. An owner per tool. By name. Whoever builds owns operation, updates and shutdown.
2. Least-privilege data access. Read-only where read-only suffices. Separate credentials instead of shared admin rights.
3. Inventory. A list with purpose, data categories, credentials and expiry date. Without that list a deletion request cannot be answered.
4. Expiry date. Every tool has a date at which it is reviewed or switched off. That is the most effective protection against sprawl.

These four points cost less time than a single procurement round — and they are the difference between internal tooling and shadow IT.

---

4) What Changes Economically

Three effects are reliably observable, independent of industry figures:

• Less manual work at interfaces. Recurring upkeep of overviews and handovers partly disappears entirely.
• Shorter paths to a decision. A view showing exactly the needed figures replaces alignment rounds.
• Less licence pressure. Not every gap forces another subscription — though savings only count once contracts are actually cancelled.

Against that stands an often underestimated item: operations. More tools mean more credentials, more dependencies, more updates. That is the Jevons paradox in miniature — cheaper creation produces more software, not less.

---

5) An Approach for the First Three Tools

1. Collect bottlenecks. Note ten recurring manual steps that cost time or create errors. Roughly estimate monthly effort.
2. Pick three. Criteria: read access suffices, clear owner, measurable time effect, no personal-data edge cases.
3. Build small, use early. One function, one audience, real data. No expansion before the first week of use.
4. Decide after four weeks. Keep, rebuild or switch off — based on measured time saved, not on effort already invested.

---

Conclusion

Malleable software is not an alternative to SaaS but the answer to the gap between standard product and your own process. The gain comes not from the number of tools built but from clear ownership, bounded permissions and the willingness to switch tools off again.

Further reading: why clarity about the goal matters more than implementation speed is covered in The New Bottleneck in IT Organisations.