# Liquid Software: When Software Can Change Its Shape > Liquid software is complete, working source code designed to be understood, owned, and reshaped with the help of AI coding agents. Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-07-27 | Topics: [Business](https://flaviocopes.com/tags/business/) | Canonical: https://flaviocopes.com/liquid-software/ I was thinking about how to offer the prototypes on [prototyped.dev](https://prototyped.dev). My first idea was to make each prototype available in many different stacks. Astro. Next.js. Django. Laravel. Go. Rails. This seemed useful. A Laravel developer could buy the Laravel version. A Rails team could pick the Rails version. Everyone would get the product in the shape they already wanted. Then I realized I might be carrying an old assumption into a new world. I was assuming every possible form of the product had to be manufactured in advance. But what if someone buys a complete, well-documented Astro prototype? Perhaps they do not need me to maintain five more editions. They can ask an AI coding agent to adapt the product to Laravel, Django, Rails, or the stack their company already uses. The Astro version does not have to be the final destination. It can be the clearest working expression of the product. This led me to the idea of **liquid software**. A liquid takes the shape of its container. Software can start doing the same. The container might be your business, your workflow, your preferred stack, your infrastructure, or your personal taste. The software arrives in one working shape. Then you make it yours. ## What liquid software means **Liquid software is software intentionally designed to be understood, owned, and reshaped.** It is not just code generated by AI. It is a complete product that already works. You receive the source code, run it, inspect it, and change it. The original implementation is a starting point rather than its permanent form. A liquid software product has a few important properties: - you receive the complete source code - the project works before customization begins - its structure is understandable - its behavior is documented - an AI coding agent can navigate and modify it - you can change workflows, data models, integrations, and appearance - you may be able to move it to another stack - you are not permanently dependent on the original creator That last point matters. If the creator disappears, the product does not disappear with them. You can keep using it. You can hire someone else to maintain it. You can ask an agent to explain it. You can move it away from a service you no longer want. The owner has real control. “Liquid” does not mean disposable. It does not mean unstable code that changes every day. It means adaptable. A house can be solid without every room being fixed forever. In the same way, software can be reliable while still being designed for change. ## Software was always editable, so what changed? Source code has always been editable. Open source is not new. Templates are not new. Boilerplates and source-code licenses are not new either. If you bought a PHP script in 2008, you could open the files and change them. Technically, nothing stopped you. But owning the source did not mean you could realistically change it. You still needed the right programming experience. You needed time to understand how the project worked. You needed to learn the framework, find the important files, trace the data, and avoid breaking behavior you did not know existed. The code was editable in theory. It often stayed fixed in practice. AI coding agents reduce that distance. You can describe a desired outcome in plain language. The agent can inspect the repository, identify the relevant files, propose a plan, make the changes, and run the tests. You can ask questions such as: - where does the approval workflow live? - what would break if we changed the account model? - which parts depend on Supabase? - how is an expense total calculated? - what must change to support multiple organizations? This makes the codebase easier to approach. It also makes a rewrite or port more realistic when the product is small and clear. An agent can use the working implementation as a reference while rebuilding the same behavior in another language or framework. This is not free. It is not automatic either. Agents make mistakes. Some changes still require an experienced developer. A port still needs testing, review, deployment work, and maintenance. What is changing is the cost and accessibility of change. More people can participate. Experienced developers can move faster. Less experienced developers can start from a working system instead of a blank directory. That is a practical change, not a theoretical one. ## Fixed products and liquid starting points Most software is sold in a fixed shape. The buttons might move. You might change a few settings. But the product remains the product its creator decided to build. Liquid software belongs beside several existing models, but it is not quite the same as any of them. ### SaaS With SaaS, you rent access to a product. You can use the features the company provides. You can usually configure parts of it. You might connect it to other services through an API. But you do not own the product. You cannot rewrite its central workflow because your company works differently. If the provider changes the price, removes a feature, or closes, you must react. The advantage is convenience. Someone else operates the software for you. The boundary is control. ### Templates A template gives you a visual or structural starting point. It might provide a landing page, a dashboard layout, or a collection of components. You still have to turn that structure into your product. Templates save design and setup time. They usually do not contain the complete behavior of a working business application. ### Boilerplates A boilerplate gives you common infrastructure. Authentication, payments, email, database setup, and deployment might already be connected. This can save weeks at the start of a project. But a boilerplate is not the product. You still have to decide what the product does and build its workflows. ### Open source Open source gives you code and a license that grants specific permissions. Some open source projects are complete products. Others are libraries, frameworks, or infrastructure. Their design goals usually serve a community rather than one buyer's adaptation needs. Open source can be liquid. But open source and liquid software describe different things. Open source describes permissions and a development model. Liquid describes how easily a working product can move beyond its original form. ### No-code No-code products let you customize software inside boundaries chosen by the platform. This is powerful when your needs fit those boundaries. You can change fields, screens, automations, and integrations without working directly with source code. But the platform decides what can change. You are customizing the system, not taking ownership of it. ### Liquid software Liquid software gives you a working product intended to move beyond its original boundaries. It is useful on day one. It is not presented as finished forever. Its source code is part product, part raw material, and part executable specification. You can run it to see exactly what it does. You can read it to understand how it does it. Then you can transform it while preserving the parts that already work. ## A concrete example Imagine I sell an expense-splitting prototype built with Astro, HTMX, and Supabase. It already has users, groups, expenses, participants, balances, and a settlement flow. You can create a group, add an expense, split it between people, and see who owes whom. This is a working product. But your company does not need exactly that product. You need every expense above 500 euros to be approved by a manager. You need organization accounts. You already run your own PostgreSQL database and use the company's authentication system. You also want the interface translated into Italian and adapted to your brand. You could ask an agent to make those changes one at a time: - add an expense approval workflow - add organizations and organization members - replace Supabase services with the company's PostgreSQL setup - connect the existing authentication system - translate the interface - apply the company's design system Later, the company might decide the application must live inside its existing Laravel platform. At that point, the team can port the product to Laravel and Livewire. That is a much bigger change. But the agent and the developers are not guessing what to build. They have a working application in front of them. The prototype contains thousands of small decisions. It defines what happens when three people split an expense unevenly. It shows how balances are rounded. It decides who can edit an expense. It handles the empty state before a group has any activity. It has names for the main concepts and relationships between its data. Many of those decisions are easy to overlook in a written specification. The product makes them concrete. This is the difference between modifying a working product and asking an agent to invent one from an empty directory. Starting from nothing sounds flexible. It also means every decision is still open. The agent must decide the data model, page structure, error states, naming, permissions, and workflow. If your prompt does not mention a detail, the agent must infer it. A working prototype gives the agent something to preserve, test, and transform. You are not asking, “Can you invent an expense product?” You are asking, “Can you keep this behavior, change these rules, and fit the result into our environment?” That is a much stronger starting point. ## The stack becomes less permanent Developers often describe products by their stack. It is a Rails app. A Laravel app. A Next.js app. This makes sense because the stack affects almost every technical decision. It shapes how we build, deploy, test, hire, and maintain the product. But the framework might become less connected to the identity of the product. The expense-splitting product is not Astro. Its identity lives in its workflows, rules, data, interface, and the problem it solves. Astro is the first way those decisions were implemented. This does not mean stacks no longer matter. They still affect performance, deployment, maintainability, security, and available libraries. They affect how easily a company can hire people. They determine how well the product fits existing systems. A careless port can make a product slower, less secure, and harder to maintain. The narrower argument is more useful: > The first stack no longer has to be the final stack. A company that uses Django might still buy an Astro prototype. The company is buying solved product decisions and a working reference. Its developers can use the original implementation to understand the behavior, then move that behavior into Django. The value is not trapped inside the original framework. This changes how I think about choosing a canonical version too. The best first stack might be the one that expresses the product most clearly. It should make the main behavior easy to see, run, and test. It does not have to predict every future owner's infrastructure. ## What makes software genuinely liquid? Not every repository becomes liquid because an AI agent can open it. A tangled codebase is still tangled. Missing documentation is still missing. Hidden behavior remains dangerous even when an agent writes the changes. Software must be prepared for adaptation. ### Clear architecture The main parts of the product should have clear roles. Authentication should not be mixed into expense calculations. Database code should not be scattered through every interface component. A developer or agent should be able to find where a behavior lives. Small, understandable modules help. This does not require a complicated architecture. In fact, extra layers can make a small product harder to understand. The goal is clarity. ### Documented behavior and decisions Setup instructions are not enough. The documentation should explain what the product does and why important decisions were made. Why are balances rounded in a certain way? Why can only the creator edit an expense? Why does deleting a group keep an audit record? Without those answers, an agent might “clean up” behavior that exists for a good reason. Documentation should serve humans and coding agents. Both need a map of the project, its commands, its boundaries, and its important rules. ### Explicit data models The important entities and their relationships should be easy to find. For the expense product, that might include users, organizations, groups, memberships, expenses, shares, approvals, and settlements. An explicit data model makes changes easier to reason about. It also makes a port safer because the new implementation can preserve the same meaning. ### Reproducible setup The owner must be able to run the product. Dependencies should install cleanly. Database migrations should work from a known state. Required environment variables should be listed. Sample data should be available when it helps explain the product. If only the original creator can start the project, the source code is not real ownership. ### Clean service boundaries External services should have clear boundaries. If the product uses Supabase, Stripe, Resend, or an analytics service, those connections should not leak into every part of the codebase. This makes a service replaceable. The same rule applies to infrastructure. Code that depends on one hosting provider should be isolated and documented. ### No hidden secrets or private data A source-code product must not contain private keys, production credentials, customer data, or dependencies on the creator's private accounts. The buyer should know exactly which services they must configure. This sounds basic. It becomes essential when code is meant to leave its original environment. ### A clear license Technical access is not enough. The owner needs clear legal permission to use and modify the code. The license should explain what can be changed, reused, deployed, and redistributed. Without that, the product might be editable but not safely usable. ### Tests and a behavior contract The code can change shape only if we know what must remain true. I call this the **behavior contract**. A behavior contract describes the promises the product must keep while its implementation changes. For the expense product, the contract might say: - every share must belong to one expense and one participant - all shares must add up to the expense total - only organization members can view its expenses - approved expenses cannot be edited without returning to review - settlements reduce balances without changing old expenses Some of this belongs in documentation. The most important parts also belong in automated tests. Tests and documentation are the banks of the river. The code can flow, but it still needs boundaries. Without a behavior contract, a successful port might mean only that the new application starts. That is not enough. It must still be the same product where sameness matters. ## Where liquid software becomes difficult The expense prototype is a friendly example. It is small enough to understand. Its workflows can be described. Its important behavior can be tested. The idea gets harder as the system grows. ### Large and tightly coupled systems A large application might have millions of lines of code, many services, and years of accumulated decisions. Changing one workflow can affect billing, permissions, reporting, support tools, and data exports. An agent can help navigate the system. It cannot make the coupling disappear. ### Data migrations Changing code is often easier than changing live data. A new account model might require moving millions of records while the old application keeps running. A mistake can lose information or connect it to the wrong user. The working prototype tells us the desired behavior. It does not remove the operational risk. ### Security-sensitive software Authentication, payments, encryption, and permissions need careful review. An agent can produce code that looks correct while missing a subtle attack. It can copy an outdated pattern or misunderstand the security model of the target framework. Confident output is not proof of safe output. ### Regulated industries Healthcare, finance, and other regulated fields have requirements beyond whether the product works. The transformed software may need audits, records, approvals, and evidence that it follows specific rules. Changing the stack can also change the evidence required. ### Infrastructure-specific behavior Some applications depend deeply on their environment. They might rely on a provider's queues, edge runtime, storage model, identity system, or network setup. Moving them means replacing more than a few API calls. The infrastructure is part of the product's behavior. ### Performance requirements Two implementations can produce the same screen and behave very differently under load. A port must preserve more than visible features. It may need to preserve response times, concurrency behavior, memory limits, and database performance. Those requirements need their own tests and measurements. ### Undocumented business rules The most dangerous rule is the one nobody remembers until it breaks. Perhaps refunds created before a certain date follow a different process. Perhaps one customer has a special permission. Perhaps a report depends on a strange field that looks unused. An agent cannot preserve a rule it cannot see. ### Frameworks are not interchangeable Laravel and Rails might solve similar problems, but they do not solve them in identical ways. Their authentication systems, background jobs, database tools, deployment models, and conventions differ. A mechanical translation can produce code that technically works but feels wrong in the target framework. A good port should look like it belongs there. ### The change must be maintained The initial transformation is only the beginning. Someone must review future updates, apply security patches, operate the product, and understand the new architecture. If an agent ports the code into a stack nobody on the team understands, ownership has not improved much. Ownership brings responsibility. Liquid software does not remove engineering. It changes who can participate and where the work begins. ## What this changes for software creators The idea changes how I think about building source-code products. I might not need to create the same product six times. Maintaining an Astro, Next.js, Django, Laravel, Go, and Rails edition sounds generous. It also divides attention across six codebases. Every bug fix must be repeated. Every feature can behave differently. Documentation drifts. One edition gets better while another becomes old. Instead, a creator can build one excellent canonical version. The saved time can go into the things that make adaptation possible: - clearer code - better documentation - stronger tests - migration instructions - architectural explanations - behavior contracts - examples of successful adaptations This does not mean one edition will always be enough. Sometimes the target stacks are different enough to justify official versions. Sometimes buyers need a supported implementation in a specific language. Sometimes a port is too important to leave as an exercise. But six editions should be a deliberate choice, not the default assumption. The creator is no longer selling an attachment to a framework. The creator is selling a solved problem and a strong starting point. This is how I am starting to see [prototyped.dev](https://prototyped.dev). The prototypes are complete products sold as source code. A buyer can run them, understand them, and customize them with an AI coding agent. The useful part is not only the code. It is the collection of product decisions already made and expressed in working software. My job is to make those decisions clear enough that the next owner can safely change them. ## How easily can this software become mine? Liquid software is still a direction, not a mature category. We do not yet have settled expectations for how these products should be documented, tested, licensed, supported, or delivered. But I think the question we ask about software is starting to expand. We will still ask: > What features does this software have? We may also ask: > How easily can this software become mine? Not just mine because I downloaded a ZIP file. Mine because I can understand it. Mine because I can change its rules. Mine because it can fit my company, my infrastructure, and the way I want to work. The most valuable software might not be the product that serves everyone unchanged. It might be the product that gives each owner a strong, working form, and then allows itself to change.