Some Form Elements
hs-form
form-columns-1
form-columns-2
hs-form is main form class.
form-columns-1 is class of wrapper with 1 column for inputs.
form-columns-2 is class of wrapper with 2 columns for inputs.
input and label
hs-input
Field Description / Help text
hs-field-desc
This is help text for the field
Field error message
hs-error-msgs inputs-list
hs-error-msg
  • Error message label
hs-error-msgs inputs-list is an HTML list element.
hs-error-msg is a text span inside HTML List Item element.
Text area Input
hs-input hs-fieldtype-textarea
hs-fieldtype-textarea is added as combo class.
Checkboxes
hs-form-booleancheckbox
hs-form-booleancheckbox-display
inputs-list
hs-input
Note: HubSpot uses basic HTML checkboxes, Webflow checkboxes work differently than the default HTML checkboxes, hence in order to style HubSpot checkboxes you need custom CSS.
you can use Webflow checkbox to style and then copy CSS from it.
Radio Buttons
inputs-list
hs-form-radio
hs-form-radio-display
inputs-list
hs-input
Success message
submitted-message
RecaptCHA
hs-recaptcha
Submit button
hs_submit
hs-button
Oops! Something went wrong while submitting the form.
All Articles
AI
No items found.

Fluid software: a hard core and a fluid shell

AI has made it trivially easy to produce code — but not to produce software an enterprise can rely on. Fluid software offers an architecture where AI accelerates building without compromising governance: a stable, vendor-managed core paired with an endlessly reconfigurable shell.

Written by Marius Tuft
CEO & Co-Founder
6 min read
Published on February 25, 2026

The marginal cost of producing code is collapsing. Using natural language to create software feels like magic: describe an app, the AI writes the code, you’re shipping in minutes. That changes things. But enterprises don’t run on demos. They run on solutions — and solutions need governance, reliability, and control.

So the question isn’t whether AI will transform how software gets built. It has and will continue to do so. The question is what architecture makes that transformation safe and sustainable for organizations that can’t afford to move fast and break things.

The enterprise dilemma: control vs convenience

Trade-offs have always defined software in the enterprise. In the on-prem era, you had control, but you also had everything else: upgrades, patching, infrastructure, security work, and large engineering teams that trapped companies in long-term complexity and cost. The emergence of SaaS flipped the script: vendors owned the stack and ensured updates and innovation, but customers often faced a lack of flexibility in return, along with bloated feature sets that meant paying for far more than they actually needed. Many enterprises began adapting the way they work to the software meant to support these processes. So, the critical question emerged: how do we let businesses move fast without losing operational integrity?

The original premise of low-/no-code platforms was to answer this question. Give control back to the business enabling rapid change and broad flexibility. Although much faster, quicker, and more affordable than in the coded world, the challenge remained that you still needed to build the software, requiring sufficient expertise, time, and effort.

Then AI code generation arrived, and a new paradigm along with it. Software workflows are being rethought, and both customers and vendors across all product categories are scrambling to understand what will happen in the short and long term.

Could the future of software be fluid?

Companies buy and use software to run their business in efficient, scalable, and standardized ways. So just because it’s become easy to create software doesn’t automatically mean it translates into value. Saanya Ojha argues that while AI lowers the cost of trying new things, it does not lower the cost of being wrong. Enterprises have an operational reality. You still need permissions and access control, audit trails and traceability, predictable behavior across users and time, data integrity and compliance support, reliability under real-world conditions, and leverage standardized institutional memory.

In my experience, enterprises value stability and predictability as much as they value innovation and change. Running a business is not a hackathon.

Gil Dibner’s piece, Could the future of software be fluid? offers a useful framing. Gil suggests that software shouldn’t be a “solid” (standard and rigid) or a “gas” (ephemeral and fragile), but something more like a liquid. Infinitely adaptable, yet contained. Flexible, yet dependable. Fluid.

This framing describes the product we’ve always been building at Appfarm. And with the launch of Appfarm AI last year, AI capabilities are integrated directly into the existing visual development framework, enabling a new form of effortless building using a natural language interface. We’re making enterprise software fluid. Effortlessly adaptable but still always consistent.

Fluid software’s two layers: a hard core and a fluid shell

Gil’s thesis maps perfectly to how we think about enterprise-grade visual development. Fluid software requires a separation between:

The hard core (immutable primitives): A vendor-controlled foundation of trusted building blocks: security, logic primitives, governance, reliability mechanisms, infrastructure, and constraints. This is encoded knowledge about how enterprise applications should be built. It’s stable and managed.

The fluid shell (declarative configuration): The layer where AI agents and humans work together to configure the building blocks: UI, workflows, data models, roles, and logic composition, but never rewrite the foundation. This is endlessly reconfigurable.

Agents can move fast but are confined in the fluid shell, while the core stays safe and enterprise-grade. The principle is simple: users and AI should build applications by configuring metadata, not by producing code that becomes a long-term maintenance burden. Metadata is inspectable, maintainable, and governable. It’s the contract and orchestration layer between humans, AI, and runtime. And the reason this matters in the AI era is the architecture behind it.

Our hard core is the platform that continuously runs, maintains, scales, and upgrades customer applications, without customers having to manage their stack. This is where enterprise operational requirements live:

  • infrastructure, security, compliance, lifecycle management
  • deployment, hosting, monitoring, logging
  • version control patterns, rollback, SLA expectations

This “platform owns the complexity” idea is a big part of how we keep the total cost of ownership predictable and avoid technical debt dynamics for our customers.

On top of that, we have our fluid shell, the configuration studio Appfarm Create. Here, users have full flexibility to visually model UI, logic, data, workflows, and integrations. Appfarm AI is the agent that helps the user generate these components, but always with the capability to see, verify, and modify directly, rather than generating code that becomes challenging to understand and maintain.

The result is conversational speed with transparency and control — a combination that makes fluid software viable in enterprise settings.

“No code” is not the point. “No maintenance” is the point.

Most enterprises were never constrained by the cost of writing code. They were constrained by the cost of maintaining it. The point of the separation between the hard core and the fluid shell is to simplify the parts of software creation that have the highest potential to create long-term drag:

  • fragile custom code that breaks at upgrade time
  • hand-stitched infrastructure decisions per application
  • procurement and lifecycle management across dozens of tools
  • rework caused by changing requirements and legacy constraints

In this model, a few important things happen:

  1. Implementation timelines compress dramatically: because software is assembled from primitives and configured visually (and now conversationally), time-to-value moves from months to weeks to days, without sacrificing governance.
  2. The enterprise regains control without rebuilding everything: instead of waiting for vendor roadmaps or writing brittle custom extensions, enterprises can adapt their software as the business changes.
  3. AI becomes a safe accelerator: AI’s role shifts from “writing production code” to “helping configure production-grade software.” That’s a big difference.

What we’re building

In a previous post, I argued that the models are good enough — that what’s missing is the context and infrastructure to make AI useful inside specific organizations. Fluid software is how we think about delivering that infrastructure.

The hard core gives enterprises the governance, security, and reliability they need. The fluid shell gives them the speed and adaptability that AI now makes possible. And the separation between the two is what keeps the whole thing sustainable — no technical debt spiral, no maintenance burden that grows with every change.

At Appfarm, this is the product we’re building. A platform where AI helps you build and adapt enterprise software at conversational speed, while the platform itself ensures that what gets built is production-grade, governable, and maintainable. Not AI that writes code you have to worry about. AI that configures software you can trust.

That’s what fluid software means in practice.

More reading

There are no items matching your filters. Please try another filter to view results.

We have a lot of helpful resources. Try another filter or reset the filters to find the resource for you.

See all articles

Digital transformation without disruption

Book demo