Malleable Software: 80% Foundation + 20% Code — A New Paradigm for Building Software in the AI Era

The No-Code Revolution Only Delivered Half Its Promise

In 2019, Michael Dubakov — Fibery's founder and a nearly 20-year veteran of the collaborative tools industry — made a bet: the no-code revolution was coming. Years later, looking back, that bet only half paid off. In August of this year, he published a post admitting he was half right — no-code didn't win the market. What actually came back was something nobody expected: code itself.

Large language models drove down the cost of writing code, and ironically, low-code and no-code vendors started scrambling to stuff code back into their own products. Dubakov named this trend "Malleable Software," and its core formula fits in a single line: 80% solid foundation + 20% custom code.

The formula sounds simple, but it reveals a deep shift in how software is built in the AI era. Whether you're taking freelance work, building internal tools, or choosing a tech stack, you'll eventually hit the same question — how do you find the right balance between flexibility and stability.

The concept of "Malleable Software" has roots in the software research community's long-standing exploration of "End-User Programming." The core idea is that software shouldn't be a closed black box — it should be like clay, shapeable by its users as needed. As early as 2019, the Ink & Switch research lab published a white paper titled Malleable Software in the Age of LLMs, exploring how ordinary users could modify software behavior without professional programming skills. Dubakov's "80% foundation + 20% custom code" formula is essentially a way to operationalize that idea into a concrete product architecture strategy: the platform handles the generic capabilities every team needs, while users (or AI-assisted generated code) handle the differentiated logic that only they can define. This is fundamentally at odds with the traditional SaaS competitive logic of "more features = better" — it acknowledges that no vendor can model a user's business for them, and treats customization as a first-class citizen in product design, not an afterthought plugin system.

A Fictional Mushroom Farm Reflects Every Small Team's Reality

To make the problem concrete, Dubakov invented a 10-person mushroom farm. They grow button mushrooms, and need to manage substrate batches, orders, and inventory — but there's no off-the-shelf industry software, so the team is making do with Google Sheets.

This farm is a mirror reflecting every small team's shared reality: real needs, limited budget, and processes that keep changing.

You might ask: AI is so capable now — why not just have Claude Code or Codex write the whole thing from scratch? For a solo project, that's fine — if it breaks, rewrite it. But the moment you add "collaboration" to the equation, the difficulty jumps immediately. You need to handle relational data storage, concurrent editing, notifications, change history, and permission systems. These are the real dirty, unglamorous jobs — they make up the bulk of any system, and there's nothing cool about them.

Five Paths, Each Missing Something

Dubakov lays out today's technical options as five paths, arranged by when they emerged. The irony is that not one of them is ideal.

Vibe-Coding in the Wild: Always Stuck at 80%

AI coding tools like Claude Code and Codex are genuinely exhilarating for the first 80% — prompt them and things move fast. But the remaining 20% will humble you: hosting is on you, login and authentication is on you, permissions and audit logs are still on you. None of it can be glossed over with a single prompt.

Fast enough to go to your head

Every developer has fallen into this trap: demo in an afternoon, ship in three months. Dubakov's take on this path is that models will eventually be strong enough to handle the dirty work — but that day is still far off.

"Demo in an afternoon, ship in three months" maps to a classic software engineering principle sometimes called the "Last 10% Rule" or the "Iceberg Problem." The visible functionality in a demo typically represents only about 20% of total system effort. The real time sinks are the parts users never see: authentication and authorization (OAuth, SSO, multi-tenant isolation), audit logs and compliance, data backup and recovery, error handling and monitoring, and cross-browser/device compatibility. AI code generation tools are already quite good at "writing code that runs," but the code they generate often lacks systematic handling of these cross-cutting concerns — each generation may implement authentication differently, leaving the project's security model fragmented and inconsistent. This is the core value of what Dubakov calls the "foundation": getting these boring-but-critical infrastructure pieces right once, so that all custom code running on top of them automatically benefits — without reinventing the wheel every time.

Vibecode Platforms: Magic Has Limits

Vibecode platforms like Lovable and v0 are a step up from going it alone — hosting, database, authentication, and deployment all come out of the box. For non-coders, it feels like magic. But magic has limits: once requirements go beyond what the generator is good at, you're stuck. These platforms offer a technical foundation — servers, raw database, authentication — but collaboration, comments, and change history are absent entirely.

Low-Code Platforms: App Foundation ≠ Work Foundation

Low-code tools like Retool and Softr have been selling the same thing for a decade. They excel at wrapping an admin UI around an existing database, but they offer an app foundation — and there's still a gap between that and a work foundation. Data often lives elsewhere, and the tool has no visibility into your team's actual work inside it.

Malleable Tools: Flexible, But Lacking Extension Points

Tools in the Notion/Fibery category look appealing — you model your own data, and the learning curve is gentle. The trouble comes when it's time to fit your specific workflow. They're flexible, but may not hold up under unusual requirements. Extension points are limited. Anyone who's wrestled with Jira's plugin ecosystem for custom logic knows exactly what that pain feels like.

But they may not hold up under your specific requirements

Specialized Tools: Flexibility and Specialization Are Enemies

Even niche markets have dedicated software — you can find a purpose-built tool for a mushroom farm if you look. If your workflow matches it perfectly, just buy it, no hesitation. But one step off alignment and you're forcing yourself to fit the tool instead of the other way around. These tools share an inescapable fate: the moment they become general and flexible, they're no longer specialized.

The Foundation Isn't One Thing

Many people assume the future belongs to whichever tool has the best generation capabilities — whoever can generate a full app from a prompt most impressively wins. Dubakov's conclusion is the opposite: what wins the market is 80% solid foundation + 20% custom code.

Interfaces will be generated — a new one in minutes, getting cheaper all the time. But the foundation — storage, full-history tracking, and all that boring "plumbing" — still takes years to build right.

The key point is that "foundation" today is not a single thing:

The only foundation you had in the hacker era

Technical foundation (provided by Vibecode platforms): servers, raw database, authentication
App foundation (provided by low-code platforms): UI components, connectors, access control
Work foundation (provided by malleable tools): data lives inside the platform itself, with collaboration, history, and permissions all built in

In the early hacker era, the only foundation you had was a compiler and an operating system — everything else had to be built from scratch. Today there are higher-level abstractions, and the real question becomes: at which layer of abstraction should you stop?

Specialized tools are the hardest foundation — so rigid they can't be changed. Codex has almost no foundation — maximum expressiveness, write anything. Both extremes fail. The sweet spot is in the middle: the foundation handles everything that's the same across all teams; custom code handles everything unique to you.

Dubakov's three-layer classification of "foundation" maps to the classic software architecture discussion of levels of abstraction. The technical foundation corresponds to the infrastructure layer (IaaS/PaaS), solving the problem of "getting code to run." The app foundation corresponds to the framework and component layer, solving "getting the UI to assemble." The work foundation is closer to the Domain-Driven Design (DDD) concepts of "ubiquitous language" and "domain model" — solving "getting business data under unified management." The critical distinction between all three is data ownership: in the technical and app foundations, business data typically lives in the user's own database, and the tool merely provides connectivity. In the work foundation, the data itself is part of the platform, which is why collaboration, version history, and permissions can be uniformly enforced by the platform. This is why the choice of foundation is so consequential — where you choose to build determines who "hosts" your data going forward, and how painful migration will be two years down the line.

Two Hard Requirements for the 20% Custom Code

That 20% custom code is small in volume but enormous in significance. It includes your proprietary interfaces (like a harvest screen on a workshop tablet), your business rules (like substrate batch quality scoring), and your external connections (wholesale customer APIs, humidity sensors). This piece is your company itself — no vendor can model it for you.

But for custom code to work, two conditions must hold:

It inherits the foundation: permissions, history, and data integrity automatically apply to custom code. If every generated app comes with its own authentication and audit system, the whole thing falls apart.
It has boundaries: custom code can break itself, but it must never corrupt the foundation. A bad app should be a headache — not a data-loss incident. Problems should be recoverable with a single rollback.

Capable of covering 90% of your workflows

The Most Valuable Principle: Choose the Foundation, Not the Interface

Dubakov offers the single most valuable principle in the entire piece: choose the foundation, not the interface.

Data, history, and permissions accumulate over time. Two years in, if you want to switch foundations, the migration cost will be staggering. Meanwhile, interfaces are becoming cheap and replaceable — AI can generate a new one in minutes. Think about your frontend framework: did you lose sleep when it cycled out every three years? Now try touching the data in your production database.

In the past, vendors sold interfaces, and the foundation was boring plumbing hidden underneath. Now it's completely reversed: interfaces get generated in minutes; foundations take years to build. Whoever has a solid foundation holds the compounding advantage.

This holds equally true for developers: your accumulated domain models and data assets are worth more than any interface you've ever written.

This principle has a well-known cautionary tale in the database world. Many early teams deeply coupled their business logic into a SaaS tool's proprietary data model — think early Salesforce's object model, or Notion's block structure. Years later, when their needs outgrew the platform, they discovered the data export formats were incomplete, relational links were lost in migration, and historical records couldn't be carried over. This is the hardest form of vendor lock-in to escape — not because of contracts, but because the data has been "digested" by the platform's proprietary structure. The argument that "interfaces are replaceable" has strong historical support: from desktop GUI to Web, from Web to mobile, from mobile to today's AI conversational interfaces — every shift in interaction paradigm has rapidly devalued old interfaces, while the underlying data assets and business rules survived. So the most important question when evaluating a tool isn't "is the interface good?" — it's "what format is my data stored in, where does it live, and can I take it with me intact?"

Making It Practical: How Do You Choose?

Dubakov offers scenario-based guidance:

Working solo: Play with Vibecode platforms freely — enjoy yourself
A purpose-built tool covers 90% of your workflow: Just buy it
A team with evolving processes (like that mushroom farm): Start with a malleable tool — the foundation is already there, and the missing 20% gets a little better to vibe-generate every month

He built out the mushroom farm management workspace in Fibery's Custom Apps in about an hour. There's obvious self-promotion baked in, but the logic holds internally.

He closes with two bets on the market, with a 2030 verification date:

"Solid foundation + custom code" will win the productivity market
Malleable tools have the best shot at getting there first — because adding extension points is measured in quarters, but building a foundation takes years

Conclusion: AI Didn't Kill Code

AI didn't kill code — it put code back at center stage, just in a different role. When making technology choices, keep three questions in mind:

Who owns the foundation?
Can custom code inherit from the foundation?
Can the data be migrated two years from now?

In an era where generative AI is making interfaces cheap, the real moat has circled back to the "boring but hard" groundwork. That may be the most practical reminder there is for founders and engineers alike.