Malleable Software = Solid Bases + Custom Code: A Deep Dive into Fibery Founder's Essay and Internal Tool Selection Guide

Forum topic · 小凯 · 2026-09-06

Summary

Fibery founder Michael Dubakov's long-form essay argues that the no-code revolution only half-delivered: code is returning as king, but in a new form. He defines the ideal endgame of malleable software as 80% solid base plus 20% custom code. Using a 10-person mushroom farm as a running example, the piece evaluates five tooling paths—generating apps from scratch with AI coding agents, vibe-coding platforms, low-code builders (Retool, Bubble), malleable tools (Fibery, Notion), and vertical SaaS—and shows none is perfect alone. Dubakov distinguishes three layers of 'base': tech base (hosting, auth, databases), app base (UI components, RBAC, connectors), and work base (data, collaboration, history, context). Custom code must follow two iron rules: it must inherit the base's permissions, validation, and history automatically, and it must be strictly sandboxed so failures never corrupt core data with instant rollback. His selection axiom: choose the base, not the interface—UI is now a cheap consumable while reliable, multi-tenant work bases remain scarce, multi-year assets. This article deconstructs the essay's frameworks and offers a practical decision guide for internal tooling in the LLM era.

> "In 2019, I bet big on the no-code revolution. Five years later, that bet only half came true: no-code tried to kill code, but what returned in triumph was code itself." > — Michael Dubakov, 22-year veteran of productivity tools and founder of Fibery

Throughout software engineering history, people have swung between two poles: extreme customization and out-of-the-box convenience. With LLMs shattering the barrier to writing code, engineers and business users can suddenly generate interfaces at will. Yet the result is not a software utopia—it is mountains of fragmented, uncollaborative code with no permissions or history. In his August 2026 essay *Malleable software = solid bases + custom code*, Dubakov draws on two decades of experience to identify the endgame: the golden ratio of malleable software is exactly 80% solid base + 20% custom code.

1. The Mushroom Farm Dilemma: Why Every Existing Path Falls Short

Imagine running a 10-person mushroom farm that must track substrate recipes, temperature/humidity sensor data, harvest batch quality, and wholesale customer orders. You face five options—none of them perfect:

> Expression Power: the degree to which a tool can be "bent" to fit your unique business intent.

2. Framework One: The Three Bases

Dubakov splits the notion of "base" into three distinct layers:

1. Tech Base (Vibe-coding, Supabase, Vercel): cloud servers, raw database tables, auth, automated deploys. It solves "how does the machine run"—but has zero business semantics. It knows row locks, not what a concurrent edit means to the business. 2. App Base (Retool, Bubble): preset UI controls, API connectors, RBAC, SSO. It assumes your data lives elsewhere; fields are cold rows with no collaborative lifecycle—no discussion threads beside records, no change lineage. 3. Work Base (Fibery, Notion): the ultimate base of malleable tools. Data *lives* here, natively fused with everything the team does around it: discussions, task links, state transitions, inherited permissions.

> Malleable Software: a concept from HCI pioneers (Alan Kay, Ink & Switch) — systems that end users have full autonomy to reshape, restructure, and recombine in place as their environment and understanding evolve.

3. Framework Two: Two Iron Rules for Custom Code

The no-code camp's hubris was trying to eliminate all code. But assembling a complex approval tree via drag-and-drop imposes more mental load than writing three lines of Python or JavaScript. The LLM explosion of late 2025 brought code back—anyone can describe logic in natural language and get it in seconds.

Yet Dubakov warns: allowing custom code is not a panacea. It must obey two iron rules, or the system dies:

Rule 1 — Code must inherit the base. A custom "quick harvest logging screen" generated by AI must automatically inherit all permission rules, field validation, and version history defined by the base. If every new component requires hand-written auth and audit logs, the architecture is doomed.
Rule 2 — Code must be strictly bounded. Custom code may crash itself, but it must never dirty or destroy the underlying work base. A bad script or AI-generated infinite loop should at worst gray out one panel—not delete your database. Formally, custom logic should act as a pure-function mapping on base state, with any mutation violating base invariants blocked and instantly rollbackable:

S_{t+1} = \text{BaseCommit}\Big(S_t, \; \text{Sandbox}\big(f_{\text{custom}}(S_t)\big)\Big)

4. Framework Three: The First Axiom — Select the Base, Not the Interface

The most consequential reframe for technical decision-makers:

Productivity market 2000–2023: the UI was the expensive selling point; the base was cheap plumbing.
AI-era market (2025+): the UI is a consumable—generated in minutes, discarded freely. The base is the ultimate asset—years of polish, extremely hard to migrate.

> Market Inversion Principle: generating a tablet-optimized mushroom harvesting UI takes 3 minutes; building a reliable, multi-tenant work base with fine-grained permissions and strong consistency still takes a top team years.

Decision rules: 1. Never buy software because the UI looks good — interfaces are the cheapest, most regenerable consumable today. 2. Scrutinize the depth of the data base — your team's entity graphs, context threads, and cross-team reference networks for the next 3–5 years will sediment there. A wrong base choice costs a hundred times more than rewriting a few interfaces. 3. Check the density of extension points — can the base be pierced precisely by a short snippet of code or an AI-assisted micro-app whenever a business edge case appears?

5. The Endgame: Different Roads to the Same Emerald City

The productivity landscape is migrating toward high expression power + extremely short build time. The holy grail sits at 80% base + 20% code:

Vibe-coding tools must frantically build collaboration bases (which takes years—very hard);
Traditional low-code tools must upgrade cold app bases into warm work bases;
Malleable tools (Fibery, Notion-class) have the best odds — because opening code extension points on a solid base takes a few quarters, while building a collaboration base atop flimsy code takes years.

As Dubakov poetically concludes: "See you in 2030. Then we'll check whether that 10-person mushroom farm has finally thrown away their Google Sheets."

References

1. Dubakov, M. (2026-08-18). *Malleable software = solid bases + custom code*. Edge of Chaos. https://mdubakov.me/malleable-software-solid-bases-custom-code 2. Dubakov, M. (2019). *The No-Code Revolution: Why Now?*. Fibery Blog. https://fibery.com/blog/gems/no-code-revolution-why-now/ 3. Ink & Switch (2019). *Malleable software: Capstone essay*. https://www.inkandswitch.com/essay/malleable-software/ 4. Litt, G. (2023). *Malleable software in the age of LLMs*. https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html