Where No-Code Platforms Stop: Rules-Based Pricing
No-code platforms are good at marketing sites and content-driven pages, and they make changes to layout and copy fast. The trouble starts when a client asks the site to calculate or decide something, for example a price that depends on options that affect each other, or a dashboard where only logged-in staff can see incoming requests.
Where content ends and logic begins
A rules-based price needs a data model and a backend, and binding CMS fields to a formula does not provide either. The pricing rules end up in one of two places: a database with a calculation layer, or someone’s head, retyped into every quote.
A CMS collection stores rows. It does not enforce that option A excludes option B, or that a surcharge applies past a threshold. Those are constraints, and constraints need a place to run. The usual place left for them is the browser, as scripts on the page, which means the number is produced on a machine the business does not control, by code any visitor can read and edit. That may be fine for a marketing figure, but a figure that goes onto a quote has to come from the server.
The dashboard has the same problem. “Only logged-in staff” means sessions and per-record access rights decided on the server before any data is sent. Hiding the page while the records are still served leaves the data reachable by anyone who asks for it directly.
What an option set requires
The configurator we built for aux-garagen.de has 41 options.
Any option set with rules between options brings the same requirements, whatever it sells:
an option model with dependencies and exclusions, so invalid combinations cannot be selected or submitted
server-side validation that repeats every rule the interface enforces, because a visitor can change what runs in the browser
versioned price rules, so a quote sent before the last rule change can still be explained today
currency and VAT handled as rules inside the calculation
document generation on the server from the stored configuration
the same configuration always produces the same number and the same document
The usual problem is two calculations of the same number: one on the page for display and another when the PDF is produced. They drift apart the first time a rule changes on one side only, and the customer sees different prices on the screen and in the attachment. So we calculate once, on the server, store the result with the configuration that produced it, and render the document from that record.
Versioning matters for the same reason. A quote reflects the rules as they stood on the day it was sent. If rules are edited in place, old quotes can no longer be explained from the archive. So we keep price rules in the database with a date on every change, and schema changes go through migrations.
What it costs
This has a cost, and we put it in writing before work starts. We build on our own stack: Next.js on the server, Spring Boot and PostgreSQL behind it, and our own CMS. A client who wants to drag a hero block somewhere new at midnight does not get that. They get a structured editor over sections defined up front, and no third-party plugins underneath the site.
A backend also has to be run: migrations are applied and the database is backed up, and someone has to own that. Rule sets also grow. Every “just add one more checkbox” either fits the option model or bends it, and a model that has been bent too often becomes hard to change.
Not every project earns this. If pricing is one number and a contact form, a no-code site is the right answer and we say so.
Working under the agency’s brand
This is usually the point where an agency that sold a client a website needs a backend developer. The agency keeps its relationship with the client; our part is the backend and configurator underneath their existing site, under their brand.
Scope is written down before anything is built. A fixed price only holds if each rule has an acceptance criterion: what goes in and what result counts as correct. A rules engine is scoped separately from the site, and anything found later is a change request.
You usually know you have reached this point when someone on the client’s team starts retyping the same prices into every quote.
How we scope and price this kind of work is on the services page.
