English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Code Strikes Back: Fibery Founder's Second Bet, from No-Code to Malleable Software

Forum topic · QianXun · 2026-09-06

Summary

In 2019, Fibery founder Michael Dubakov predicted the no-code revolution would sweep away third-wave collaboration software. In an August 2026 essay, he grades his own bet as having "aged so-so": no-code survived, but code itself came back in an unexpected way, driven by LLMs. His new thesis, "Malleable software = solid bases + custom code," is illustrated through a 10-person mushroom farm. The analysis lays out five routes to building internal tools — from-scratch AI generation (Claude Code), vibe-coding platforms (Lovable, v0), low-code (Retool), malleable tools (Notion, Fibery), and vertical SaaS (Kinoko) — and argues each is missing a piece. He distinguishes three foundation layers: technical base (hosting, auth, storage), application base (components, access control, automation), and work base (domain model, collaboration, history, permissions), with only malleable tools offering the last. Custom code should cover the team-specific 20%, but only if it inherits base capabilities and stays sandboxed. His selection principle: choose the base, not the UI, since interfaces are becoming the cheapest, most replaceable part.

Code Strikes Back: Fibery Founder's Second Bet, and a Mushroom Farm

In September 2019, Fibery founder Michael Dubakov published "No-code Revolution. Why Now?", betting that a fourth wave of "create your own software" tools (Airtable, Coda, Notion, Retool, Fibery) would wash away many third-wave collaboration vendors within a decade.

Seven years later, in an August 2026 long-form essay — "Malleable software = solid bases + custom code" — he delivers his verdict: the bet aged so-so. No-code did grow up, and Notion and Airtable became mainstream, but third-wave vendors were not washed away (JIRA is still there). What truly surprised him: "code came back in a way I didn't foresee." LLMs are making every no-code and low-code tool increasingly dependent on code — a development he calls ironic.

On Hacker News, the top comment asked why anyone should trust someone who was so wrong before. A highly upvoted reply: nobody predicted AI. The new essay itself begins by admitting the miss before making a second bet.

A Mushroom Farm, Five Forks in the Road

The entire argument is anchored by a 10-person mushroom farm growing white button mushrooms. Its software needs: full lifecycle tracking of growing blocks (pasteurization, inoculation, colonization, fruiting), temperature/humidity/CO2 histories per growing room, harvest records, wholesale orders, and permissions/audit trails. It probably uses Google Sheets — and the intuition that the market is too small for dedicated software is wrong: two vendors already exist. Kinoko (North Carolina, USA) offers block tracking, sensor histories, QR labels, and mobile scanning from $99.99 to $399.99/month. Switzerland's MycoSense goes heavier with a "Harvest Manager ERP," co-developed with growers in Switzerland, the Netherlands, Germany, Canada, and the US, with offline mobile inspection.

The essay sorts all options since 2019 into five routes, each missing a piece:

| Route | Examples | Missing | |---|---|---| | From-scratch generation (2024) | Claude Code, Codex | First 80% smooth, last 20% painful: hosting, auth, permissions, databases all on you | | Vibe-code platforms (2023) | Lovable, v0 | Faster out of the box, but stuck once you exceed the generator's domain | | Low-code (2017) | Retool, Softr | Application base only — no work base: data lives elsewhere, no collaboration, comments, or change history | | Malleable tools (2013) | Notion, Fibery | Many built-ins, quick start; insufficient extension points to fit your exact workflow | | Vertical software (1999) | Kinoko | Perfect out of the box, but locked down; once it becomes flexible, it stops being vertical |

Three Bases: The Hardest Part

Using a factory-building analogy:

> Technical base: utilities brought to the land — power, water, roads: hosting, auth, raw storage. Good land; you build everything yourself. Vibe-code platforms offer this. > > Application base: a prefabricated factory — components, access control, automation pipelines installed. But one detail: your goods sit in someone else's warehouse. Low-code assumes data lives elsewhere. Retool, Softr are here. > > Work base: factory, warehouse, access control, and inventory ledger in one building — the data itself lives here, with collaboration, history, and permissions growing around it. Notion, Fibery offer this.

A capability matrix (★ defines the category, ✓ covered, ◐ partial, ✗ absent):

| Capability | Gen-from-scratch | Vibe-code | Low-code | Malleable | Vertical | |---|---|---|---|---|---| | Expressiveness (custom UI & logic) | ★ unlimited | ✓ high | ✓ within slots | ◐ | ✗ | | Technical base | ✗ | ★ | ✓ | ✓ | ✓ | | Application base | ✗ | ✗ | ★ | ✓ | ◐ fixed | | Work base (domain model, collaboration, history, permissions) | ✗ | ✗ | ✗ | ★ | ✓ |

Low-code's entire "work base" row is empty — explaining why it has never become a team's workspace. Vertical software cannot express custom needs. Malleable tools' weakness is expressiveness.

The 20% of Custom Code, and Its Two Conditions

The base covers what every team shares. The remaining 20% — your harvest screen, batch quality rules, wholesale API, humidity sensors — is custom code's job:

> "This 20% is small, but it *is* your company; no vendor will ever model it exactly right."

A footnote-grade data point from the HN thread: the author of open-source file manager Filestash split his product into 80% core + 20% plugins, and the plugins' total code grew to 10x the core — "unsurprisingly, everyone's 20% is different."

Custom code stands only under two conditions:

1. It inherits the base — permissions, history, and data integrity apply automatically. His blunt phrasing: if every generated app needs its own auth, storage, and audit logs, you're doomed. 2. It is bounded — custom code can break itself, but must not corrupt the base; rollback must be easy. A bad app should be an inconvenience, not a data-loss incident.

Full disclosure: the author runs a malleable-tool company, and his second bet is on himself — not a refutation, but worth keeping on the table.

The Market Inverting, and One Selection Principle

The essay's underlying claim: the productivity tools market is inverting. For twenty years vendors sold interfaces while bases (storage, permissions, history) were plumbing no one paid for. Now interfaces can be generated in minutes while solid bases still take years. New bet: solid bases + custom code win the productivity tools market, and malleable tools are likeliest to get there first, because extension points take quarters to add while solid bases take years. He promises readers a check-in in 2030, to see whether the mushroom farm has finally escaped spreadsheets.

The takeaway principle, in his words: choose the base, not the UI. Data, history, and permissions accumulate year over year and are hard to migrate after two years; UI is becoming the cheapest, most replaceable part.

Practical guidance in three lines: for one person, vibe-code it and have fun; if a vertical tool covers 90% of your workflow, just buy it; for a team with evolving processes — like the mushroom farm — start with a malleable tool, and the missing 20% becomes more vibe-codeable every month. His own demo: a mushroom-farm management workspace built in Fibery in roughly an hour, including a few custom apps.

---

Sources:

Tags

#malleable-software#no-code#low-code#vibe-coding#internal-tools#fibery#productivity-software#ai

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/178634560