No-code vs bespoke: sort every asset by how often it changes

A unit went to reserved on a Monday. The sales page still showed it as available on Thursday, because the only way to flip that tag was an email to the agency that built the site, and the agency had a queue. Three buyers filled out the lead form for a home that was already gone. The problem was not that the site was custom. The problem was that a thing changing every week had been built the same way as a thing that changes once.

Template versus custom is the wrong axis

Search how to build a development microsite and you get the same fork every time. A template you can edit yourself but never quite bend to the project, or a custom build that looks exactly right and then locks every change behind a developer. Pick one, live with the tradeoff. For a team selling an off-plan project across the months it takes to sell out, that axis measures the wrong thing.

The axis that predicts your pain is frequency. Some assets on a property page get set once and left alone for the life of the campaign. Others you touch every sales week. Sort by that first and the template-or-custom question mostly answers itself. Sort by looks or by budget instead, and the Thursday-availability gap is what you buy. In eight years of shipping these for developers, the accounts that stayed calm through pre-sale were the ones that drew this line before the build, not the ones with the prettiest render.

Sort each asset by how often it changes

Before anyone quotes a timeline, run one pass over the page. For each asset, ask how many times you will edit it during pre-sale. Not whether it could be custom, not what it costs to build. Just the change rate.

Two buckets fall out. Set-once assets get commissioned once and left alone, so their edit latency almost never bites, and they can be as bespoke as the budget allows. Weekly assets, the price, the availability flag, the reopened form, have to sit somewhere the operator reaches without a ticket, or every edit inherits someone else's calendar. That single cut decides more about the selling months ahead than the choice of vendor does. The grid below runs the usual work through it.

The weekly layer runs on data binding, not goodwill

Here is where the sort earns its keep, and where most "you can edit it yourself" promises quietly fail. My blunt view after watching dozens of these launches: a no-code editor that only exposes editable fields is worse than a developer queue, because it hands the operator the illusion of control while leaving stale copies scattered across six pages. What makes the weekly bucket actually work is data binding.

In Vinode's Back Panel, listings bind to live project data. Flip a unit to reserved in one place and every listing that references it updates with it, because there is one source behind them all. Change the price list, and the pre-sales site is the price list. Nobody synchronises anything by hand, and the "flip a sold tag in minutes" claim stops being a sales promise and becomes a property of the system. That is the two-week build path working as intended: fast to stand up, then yours to run. The same binding drives live unit availability and filtering on the buyer's side, from the same data.

Set-once still has an owner

The weekly layer is the operator's, but the bespoke bucket does not run itself either. Someone still owns the set-once assets forever: the 3D, the interactions, the design. When those need a change, it is a developer's calendar again, whether that developer sits at the agency or on your payroll. That ownership question, and the three-year dollar model that prices it out, is the neighbouring post's whole subject: the true cost of ownership. It belongs there, not here, so this piece stays out of dollar figures and keeps to the frequency line.

Even Vinode sent one asset to bespoke

The sort cuts both ways, and Vinode's own brochure site is the clearest example. Vinode sells a no-code editor. To run its own marketing site, Vinode is moving off a no-code website builder, Webflow, to a bespoke, code-owned build.

The reason is one asset the frequency sort pushed the other way. A conversion marketing site wanted server-side analytics events, A/B tests decided before the HTML is sent so there is no flicker, and conversion tracking owned in code rather than bolted on through a builder's surface. Tracking is set-once plumbing that has to reach deeper than any drag-and-drop tool exposes. So for that one job the sort said bespoke, and the site became code we own and can instrument. The lesson we took from making the call ourselves: no-code is the wrong home for an asset the moment your edits go deeper than the surface the tool chose to expose, and a conversion site's tracking almost always does.

Where the sort breaks down

The frequency line is clean until two things blur it, and pretending otherwise would sell you the method short.

First, a weekly asset can outgrow the no-code layer. You can only edit what the tool chooses to expose, so a non-standard interaction on a listing pushes that asset off the no-code track and back into a build, even though it changes often. When that happens, frequency loses to capability, and you accept the ticket for that one asset.

Second, the sort assumes the weekly layer is genuinely reachable. A no-code editor with per-seat pricing, hard vendor lock-in, or a shallow field set can carry the label without the reach. If the operator still routes deeper changes back through the vendor, the asset was never really in the weekly bucket. Test the layer against the actual edits before you trust the sort, not against the demo.

Run the frequency test on the vendor, live

One test exposes all of this before you sign. Name the four or five edits you make in a normal sales week: a price, an availability flag, a floor number, a swapped render, a reopened form. Every one of those is a weekly asset by definition, so every one has to happen without a ticket.

Don't judge the vendor on how good the first render looks; that is a set-once asset, and it flatters everyone. Sit them at a live page, make them do all five weekly edits while you watch, and count how many landed without touching a developer. That count, not the render, tells you whether the frequency sort actually holds in their tool.