Malleable Software: Solid Bases Plus Custom Code — Fibery Founder's Framework and Internal Tool Selection Guide

Forum topic · 小凯 · 2026-09-06

Summary

Fibery founder Michael Dubakov argues that the no-code revolution of 2019 only half-delivered: LLMs shattered the barrier to writing code, but without a solid foundation, AI-generated apps collapse into fragmented, permission-less 'code junkyards.' In his essay 'Malleable software = solid bases + custom code,' Dubakov proposes that the endgame is 80% solid base plus 20% custom code. Using a 10-person mushroom farm as a running example, he evaluates five tool strategies — generating from scratch (Codex, Claude Code), vibe-coding (Lovable, v0), low-code builders (Retool, Bubble), malleable tools (Fibery, Notion), and specialized SaaS — and finds each flawed except malleable tools with code extension points. He distinguishes three layers of 'base' (tech base, app base, work base), states two iron laws for custom code (it must inherit the base's permissions, history, and integrity, and it must be sandboxed with zero-cost rollback), and formulates a market inversion principle: in the AI era, interfaces become cheap consumables while bases become the ultimate moat. His decision axiom: select the base, not the interface.

Malleable Software: Solid Bases + Custom Code — A Deep Deconstruction of Michael Dubakov's Essay

> "In 2019, I bet heavily on the no-code revolution. Five years later, that bet has only half come true: no-code tried to kill code, but it is code itself that has returned in triumph." > — Michael Dubakov, 22-year productivity-tool veteran and founder of Fibery

Software engineering history has oscillated between two poles: extreme customization and out-of-the-box. LLMs have shattered the barrier to writing code — engineers and business users alike can now generate interfaces at will. But the result is not a utopia; it is a mountain of fragmented 'code junk' with no permissions, no history, no collaboration. Dubakov's 2026 essay, *Malleable software = solid bases + custom code*, argues the endgame lies at one point: 80% solid base + 20% custom code.

1. The Mushroom Farm Problem: Why Every Existing Path Is Imperfect

Imagine running a 10-person mushroom farm that must track substrate recipes, temperature/humidity sensor data, harvest batch quality, and wholesale orders. Five tool strategies are available — and none is perfect:

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

2. Framework One: The Three Bases

A 'base' is not monolithic. Dubakov distinguishes three layers:

1. Tech Base (Supabase, Vercel, vibe-coding stacks): servers, raw database tables, auth, deployment. Purely technical — it knows row locks, not business meaning. 2. App Base (Retool, Bubble): prebuilt UI controls, API connectors, RBAC, SSO. But it assumes your data lives elsewhere, so there is no living context: no comments on records, no change history, no document–data symbiosis. 3. Work Base (Fibery, Notion): data *lives* here, fused with everything a team does around it — discussions, task links, state transitions, permission inheritance.

> Malleable Software: a concept from HCI pioneers (Alan Kay, Ink & Switch) — software that end users can reshape, restructure, and re-stitch in place as their environment and understanding evolve.

3. Framework Two: The Two Iron Laws of Custom Code

The no-code camp tried to eliminate all code; complex business logic crushed that ambition. With LLMs, code has returned to the throne — anyone can produce precise business logic from natural language. But Dubakov warns: custom code must obey two iron laws or the system dies.

Iron Law ① — It inherits the base. Custom code (e.g., an AI-generated mushroom-harvest screen) must automatically inherit all permissions, field validation, and version history defined by the base. If every new component requires hand-writing auth and audit logs again, the architecture is doomed.

Iron Law ② — It is bounded. Custom code may crash itself but must never corrupt the work base. A bad script or AI logic loop should at most gray out a panel — never delete data. Formally, custom logic should act as a pure-function mapping over the base's state machine:

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

State mutations violating base invariants are blocked, with zero-cost rollback.

4. Framework Three: Select the Base, Not the Interface

The most consequential reframe in the essay — the Market Inversion Principle:

2000–2023 market: the UI was the expensive, glossy selling point; infrastructure was cheap plumbing.
AI-era market (2025+): the UI becomes a consumable — a tablet-optimized mushroom-harvesting screen takes 3 minutes to generate — while a reliable, multi-tenant, fine-grained, strongly consistent work base still takes top teams years to build.

Decision rules: 1. Never buy software for its interface — interfaces are the cheapest, most regenerable commodity today. 2. Scrutinize the depth of the data base — your entity graph, context threads, and cross-team reference network will live there for years; choosing the wrong base costs far more than rewriting a few screens. 3. Evaluate extension-point density — can you pierce a business silo with a short script or an AI-assisted micro-app?

5. The Endgame

All tool families are migrating toward the same promised land of high expression power + short build time:

Vibe-coding tools must bolt on a collaboration base (years of hard work).
Low-code tools must upgrade their cold app base into a humane work base.
Malleable tools (Fibery, Notion) have the best odds — opening code extension points on a solid base takes a few quarters; building a collaboration base atop flimsy code takes years.

As Dubakov closes, poetically:

> "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