Malleable Software = Solid Bases + Custom Code
- title
- Malleable Software = Solid Bases + Custom Code
- type
- summary
- summary
- Dubakov's map of the AI-era productivity-tools market β the sweet spot is an 80% solid base (storage, permissions, history) plus a vibe-coded 20% of custom code
- tags
- ai, no-code, product, software-economics
- created
- 2026-09-14
- updated
- 2026-09-14
Michael Dubakov, who joined the productivity-tools market in 2004 and founded Fibery, writes a periodic "visionary" piece when the market shifts; this August 2026 one argues the shift is that AI inverts how software gets built malleable-software-solid-bases. He is selling a product in exactly the category he says wins, so the essay is a bet with his own company's positioning underneath it, and he says as much.
The problem AI creates
AI lowered the barrier so anyone can build small apps to solve personal problems. The trouble starts when you add collaboration. Alone it is fine to break things until the app works; on a team you need data storage with relations, concurrent editing, notifications, change history and permissions. So the question is where the hot spot of malleable software sits: start from scratch in Codex every time, or have a solid base you tailor with custom code.
He runs a mushroom-farm-with-ten-employees example through five options, and the point is that none is ideal. Build from scratch (Claude Code, Codex, "from 2024") means you own hosting, auth, permissions and database β the first 80% is easy, the last 20% is hard. Vibe-code (Lovable, v0, "from 2023") hands you a hosted app, database, auth and deploy and looks finished sooner, but you get stuck when you outgrow what the generator does well. Low-code app builders (Retool, Softr, "from 2017") have sold "solid base + custom code" for a decade but give you an app base, not a work base β your data is assumed to live elsewhere. Malleable tools (Notion, Fibery, "from 2013") get you far fast but often lack the extension points to fit your exact process. And a specialized tool (from 1999) is as solid as it gets but cannot be customized, which is the whole reason it doesn't fit many cases.
The thesis
The ideal is a solid base covering the 80% that is identical for every team β databases, permissions, history, collaboration, notifications β with custom code covering the 20% that makes yours different. Vendors are all heading there from different corners: vibe-code and low-code tools are adding solid bases, and malleable tools should add extension points.
The bases differ in kind. Vibe-coding platforms give a tech base (servers, raw database, auth); low-code platforms give an app base (UI components, connectors, access control); malleable tools give a work base, where the data itself lives together with everything a team needs around it. His rule for drawing the line: the solid base should cover what is identical for every team, and custom code covers what makes yours different β the unique interfaces, the business logic, the connections to a client's API or a humidity sensor.
Custom code only works under two conditions. It must inherit the base, so permissions, history and data integrity apply to it automatically β if every generated app needs its own auth, storage and audit trail, you are doomed. And it must be bounded, able to break itself but not corrupt the base, with easy rollback, so a bad app is an inconvenience rather than a data-loss incident. Historically custom extensions were hard (he points at the Jira plugin ecosystem); with LLMs they can be easy, which is what makes the model newly viable.
His closing principle: select your base, not the interfaces. Data, history and permissions accumulate and are hard to re-pick in two years, while the UI is becoming the cheap and replaceable part β interfaces are generated in minutes while a base still takes years to build. His bets are that solid-bases-plus-custom-code wins the productivity market, and that malleable tools reach it first because extension points take quarters to add while a solid base takes years.
How it sits in the vault
Dubakov is arguing the same shift the vault covers from the coding side, one layer up at the product-market level, and his P.S. points at the research lineage β Ink & Switch's Malleable Software essay and Geoffrey Litt's end-user-programming-in-the-age-of-LLMs piece β that the vault does not yet have pages for.
His "the code was the hard part, now it's free, so the value moved to fit" is the buyer-facing version of service-with-a-software, where a designer cancels his SaaS subscriptions because building overfit private tools became faster than configuring someone else's, and of disposable-code, where cheap code shifts which projects are worth attempting. His "select your base, not the interfaces" is the productivity-market instance of no-silver-bullet: the durable difficulty is in the data model and its guarantees, not in the UI that Brooks would call accidental. The essay is also a market-side complement to owning-ai-written-code and refactoring-that-never-happens β where those warn that vibe-coding the whole thing leaves you owning code you don't understand, Dubakov's answer is to vibe-code only the bounded 20% on top of a base whose permissions, history and rollback you did not have to build or understand.
The caveat is vendor bias: the whole framing lands on "start in a malleable tool today", and Fibery is his malleable tool, cited by name as the worked example. The market map is useful; the conclusion is also a sales pitch.