The two quotes disagree because one of them thinks you're buying pages
The short answer
The line isn't budget or ambition. It's whether you're buying pages or an application. Pages that read the same for everyone belong on Webflow. Logged-in people, records that belong to one customer, calculations the system has to work out and store: that's a build. Plenty of businesses need both halves.
The custom build is the bigger number and it also sounds like the more serious answer, which is exactly the trap. Serious isn't a property of the platform. It's a property of what you're building, and the two documents in front of you are quietly answering different questions about that.
The line that decides it, and it isn't ambition
Three questions separate the two, and none of them is technical. Does anyone sign in? Does a record belong to one customer and not another? Does the system have to work something out and keep the answer? No to all three and you're buying pages, however sophisticated they look. Yes to any one and there's an application in your project, whether or not anybody quoted for one.
The middle case causes the arguments: a members' area. Webflow can gate content behind a sign-in, and where everyone with access sees the same hidden pages, that's a real answer. It stops being one the moment two logged-in people are supposed to see different things, because that's a record belonging to a person rather than a page belonging to a group.
Size isn't a signal either. Forty static pages is still a marketing site, and eight screens behind a login is still an application.
Brochure site
Nobody signs in. Every visitor sees the same thing.
Marketing site with a CMS
Editors publish weekly. Still the same pages for everyone.
Gated members area
One group sees pages the public can't. The edge, and where the workarounds start.
Per-customer records
Each account sees only its own data, and something calculates and stores it.
Pages
An application
- Pages
Brochure site
Nobody signs in. Every visitor sees the same thing.
Marketing site with a CMS
Editors publish weekly. Still the same pages for everyone.
Gated members area
One group sees pages the public can't. The edge, and where the workarounds start.
Per-customer records
Each account sees only its own data, and something calculates and stores it.
- An application
What a custom build commits you to after the invoice is paid
The quote covers building it. It rarely covers owning it, and owning it starts on launch day.
Four things move to your side of the line. Hosting, in an account somebody keeps paid and current. Deploys, meaning a way to get a change into production without taking the site down. Dependency updates, because a coded build sits on a stack whose parts stop being maintained on a published schedule. Node.js sets an end-of-life date for every major release, and the security patches stop when a version passes it. And a person who answers when something breaks on a Friday evening.
That last one quietly decides more of these than the feature list does. Webflow's bad day is that you can't do something you wanted. A custom build's bad day is that the site is down and the only person who understands it is on a plane. One is a support queue you can join. The other is an arrangement you made in advance or didn't.
None of this argues against building. It argues for asking what year two looks like before you compare year one.
What you actually get, and design freedom isn't it
What a custom build gives you that nothing else will is narrower than the pitch suggests, and more valuable.
An account model, with permissions that mean something. Data that belongs to one customer and not another. Server-side work: anything that has to hold a credential, talk to another system on a schedule, or run with no browser open. Behaviour rather than layout, so you can change what the software does and not only what it looks like. And a repository your company owns, which only holds if it was created inside your organisation rather than promised at handover.
Design freedom isn't on that list. Neither is loading quickly or ranking well. A proposal arguing for a build on those grounds is arguing about something that stopped separating the options years ago.
The two middle options nobody puts in a quote
The comparison arrives as a binary because each side is quoting the thing it sells. There are two shapes in between, and one is very often the right answer.
The first is a hosted CMS with a coded front end. Editors get an editing interface, developers get code, and the two meet at an API. It's a genuine middle on control and no middle at all on maintenance: you still deploy, you still update dependencies, and you now have two vendors. Choose it when non-technical people have to publish into something that behaves like an application.
The second is the split. A Webflow marketing site on your domain, and a separate application behind a sign-in link on a subdomain. The public pages stay with the person who writes them, the product stays in code, and either half can be changed or moved without touching the other. That's a bigger deal in year three than it sounds in week one.
It's almost never on the table for a reason that has nothing to do with you: it's two proposals and a harder conversation than one number. The costs are real. Two design systems that have to keep looking like the same company, a sign-in handoff to get right, and reporting that spans two properties. Our view at Rigoris: when a business needs both halves, the split deserves a hearing.
01
The marketing site
Public pages on Webflow. Your marketing lead publishes and changes them without a developer.
02
The sign-in link
One link in the navigation, pointing at a subdomain. To the visitor it reads as one company.
03
The application
Coded, deployed and hosted in accounts your company owns. Nothing public lives here.
04
That customer's records
Data belonging to one account and not another, which a site builder was never for.
The same criteria, three ways
This is the comparison your two documents are each half of. Read down the row that matters most to you rather than across the column you already like.
The split looks like more work here because it is more work at the start. What it buys is that the expensive half stays small.
| What decides it | Webflow | Coded build | The split |
|---|---|---|---|
| Publishing a new page | Your marketing lead, same afternoon, no deploy | A developer and a deploy, unless an editing layer was built in | Same afternoon on the site. App screens still need a deploy |
| Logged-in people, per-customer records | Gating, which shows a group the same hidden pages | Yes, and this is why the option exists | Yes, in the app. The site stays public |
| Who answers when it breaks | The platform's support, for the platform itself | Somebody who knows your codebase, if you arranged that | Both, so you need to know which half is down |
| Hosting, domains and deploys | Part of the plan you already pay for | Your accounts, your billing, your pipeline, and somebody owns them | Two of everything, but only the app half needs watching |
| Dependency and security updates | The platform's problem, not yours | Yours, as long as it runs. Versions reach a published end of life | Only on the app half, which is most of the point |
| Doing something the platform never anticipated | An embed or a workaround, each one code somebody now owns | Change the code. This is what you're buying | Workarounds on the site, code in the app, each where it belongs |
A test you can run this week
You don't need a technical opinion to settle this. You need three lists and one email, and everyone who can write them already works for you.
1. List everyone who signs in
Write down every kind of person who will log in: staff, customers, a contractor, an admin. Next to each, write what they see that the others can't. If that column is empty, nobody needs an account. Three rows in it and you're building an application.
2. List the records that belong to somebody
Mark everything the system holds that belongs to one customer rather than to your company. A booking, a claim, a document, a balance. Pages belong to everybody. Records belong to somebody, and a page with one customer's name on it is a record wearing a page's clothes.
3. List what gets worked out and kept
Write down every figure the system has to calculate rather than display: a quote, a score, a fee, a status that changes on its own. Then ask whether that answer has to still be there next week. Stored calculations are the signal people forget.
4. Send all three lists to both vendors
Ask both of them the same question in writing: which of these lines does your proposal cover, and where does the rest live. A proposal that changes shape once it sees your lists was quoted against a guess.
Worth knowing before you start
Before you read either price, ask both quotes the same question in writing: who signs in, and what does each of them see that the others don't. A quote with no answer hasn't been scoped against your product.
Ask the custom-build side what month fourteen looks like. Who applies dependency updates, whose name is on the hosting account, and what happens on a Friday evening. A proposal that stops at launch is missing a year of scope.
If you're building, get the code repository created inside your own company's organisation on day one and add the vendor to it. Starting that way costs nothing. Moving a repository and its history at handover is a negotiation at your weakest moment.
If a proposal offers a members' area on a site builder, ask exactly what one member sees that another doesn't. Gating hides pages from everyone outside a group, which isn't the same as data belonging to one customer.
Common questions
It can put content behind a sign-in, which works for a members' area where everyone with access reads the same thing. It isn't a place to keep records belonging to one customer and not another. If two signed-in people should see different data, you've described an application.
The launch number isn't the comparison. Look across three years and include who keeps it running, because a build moves hosting, deploys and dependency updates onto your side for good. For pages that usually makes the coded route the dearer one. For an application you're paying for something the alternative can't do at all.
Almost never. A product behind a sign-in link on a subdomain leaves the site alone. Rebuilding working marketing pages in code to keep everything in one place buys nothing, and it hands page edits back to a developer, which is the thing you were trying to stop.
Ask now, in writing, for both. On a build it comes down to the repository and the hosting accounts: if they were created in your company's organisation, any competent team can carry on. On Webflow, content exports and the workspace transfers, though a move elsewhere means the build gets rebuilt.
Different shapes rather than different numbers. A Webflow timeline is dominated by structure and content, and it settles once the content model does. A build's widens with the feature list, so ask not for a date but for what would move it. An estimate with no range and no named risks isn't really an estimate.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.