Where WebinOne is the wrong choice

Every platform is wrong for somebody, and an evaluation goes faster when it finds that out early. This page is our own answer to the question that normally gets asked of third parties because the vendor never answers it: where does WebinOne not fit, and who should choose something else.

Most of what follows is already stated in writing elsewhere on this site. Collecting it in one place is the point — a limit buried in paragraph nine of a technical article is not much use to somebody deciding whether to spend two weeks on an assessment. If one of these describes your client, the useful outcome of reading it is that you stop here rather than in week three of a pursuit.

It is a DXP, not a general-purpose application platform

WebinOne holds content, ecommerce, customer records, forms and member accounts, with a headless API over the same data. What it does not do is run your bespoke business logic. Custom back-end services, heavy data processing, and anything that is really an application with a website attached, sit alongside the platform — built by your team, talking to it over the API — rather than inside it.

This is the boundary that decides most bad fits, and it is worth testing against the actual work rather than against the brief. If the requirement list is mostly content, commerce, customer data and integration, the platform is doing the job it was built for; the fuller description of that job is in what WebinOne is, written for integrators. If the requirement list is mostly workflow, calculation, or a domain model with nothing to do with publishing, then what the project needs is an application framework and a team to run it, with a DXP underneath at most.

Ecommerce past the transactional core is a project, not a setting

The commerce in the platform is transactional commerce: catalogue, cart, checkout, orders and customers, with the customer record shared with the CRM side rather than synced to it. Push a requirement list past that — multi-vendor marketplace behaviour, very large catalogues with complex variant logic, deep two-way ERP or PIM integration — and you are no longer configuring the product. You are commissioning work on it.

That work exists and it is a normal thing to buy: there is a development team that extends the commerce layer to fit a specific project, and it happens regularly rather than exceptionally. The condition is the part that belongs on this page. It is scoped, quoted project work with a delivery date attached, not a capability you can switch on during a trial — so an evaluation that reads "extensible" as "already there" will price the build wrong and discover the difference after signature. The test is where commerce sits in the project: if it is a component, the platform covers it; if the commerce requirement is the project, either budget platform work as an explicit line item or use a dedicated commerce platform and integrate.

The build happens in our object model, and the API extends on our schedule

There are two supported ways to build a front end here, and they are not equivalent in how much of your own stack survives. The first is the platform's own template layer and object model — the path most partners take, and the one the documentation, the tooling and support are built around. Your team learns our model. The second is the headless API: your own front end, your own hosting, the platform as the content and commerce back end. Both are real delivery models rather than a preferred one and a workaround.

What decides between them for an integrator is API coverage against the specific build, and coverage moves. The API is extended when a delivery needs something it does not yet expose, and that is routine — but it is scoped project work on a schedule agreed with us, not something your engineers can add for themselves. If your practice's operating assumption is that engineering unblocks itself without a vendor in the loop, that is a genuine friction with this platform rather than a detail, and it is much cheaper to find against one real integration during an assessment than in sprint two of a delivery.

If your firm's product is running infrastructure, this is a trade

In the standard arrangement the platform team operates the infrastructure — the servers, the patching, the scaling, the monitoring. That single fact lands in two opposite ways, and which one applies to you depends on what your firm actually sells. If your firm needs the platform run but does not sell running it, the operations layer is resold rather than self-delivered: it reaches your client under your brand and on your invoice, without a rota, a runbook or a hire behind it. That is the standard arrangement rather than a concession. If your differentiation is your operations practice — your own runbooks, your own monitoring, managed services as the billable product — the same fact removes a revenue line, and with it the thing you compete on.

Neither of those is a defect and both are predictable, but they are opposite outcomes and the second one is easy to discover late. The question worth settling before an assessment rather than after it is what your firm sells on top of the platform, and whether that thing survives the platform doing the operations. If the ops contract is the product, this is the wrong layer to build it on.

It runs in our AWS account, not in yours

Production sites run in the platform's own AWS account, operated by the platform team. For an AWS-native integrator this is the sentence on the page with the most consequences, so it is worth spelling out what follows from it: your practice does not hold the account, does not own the IAM boundary, and cannot point the tooling it already runs — monitoring, cost allocation, landing-zone standards, its own security baseline — at the infrastructure a client's site sits on. If your delivery model assumes everything a client runs lives inside an account your team administers, the platform as deployed today does not match that model.

A different arrangement is a commercial conversation rather than a product setting. A custom licensing and setup deal can be quoted, and asking for one is reasonable — but it is agreed deal by deal, and it is not a switch that gets flipped during an evaluation. The practical advice is the same in both directions: if account topology is a hard requirement, from your side or your client's, put it in the first commercial conversation and get it priced, rather than assuming either that the default is the only possibility or that a non-default arrangement is already sitting there available.

Above one server, load balancing runs through Cloudflare — and the account is yours

A dedicated deployment of two or more servers is load-balanced through a Cloudflare integration, and the Cloudflare account has to be one you hold. A single dedicated server does not require it; from a load-balanced pair upward it does. That is stated on our own dedicated servers page, and it is a considerably cheaper thing to read before a first deployment than to find during one.

Two things follow for an integrator, and only the second one is a cost. The compute and data layer runs on AWS; the traffic-distribution layer in front of it does not, so an architecture that has to be AWS end to end — because a client's standards say so, or because your own practice is deliberately single-vendor — does not describe this platform above a single server. And the dependency is a prerequisite you supply rather than a component we provision: an account, its billing, and somebody in your team who administers it. Neither is difficult to satisfy. Both belong in the first deployment plan rather than in the first incident.

If procurement requires FedRAMP or CMMC, we do not clear that bar today

There is real public-sector work on the platform — a South Australian government body and US government clients run production sites on it — and there are data residency options for compliance requirements, which is what makes that work possible. Be precise about what it is: production government work on AWS, not a federal authorization. There is no FedRAMP authorization, and we are not CMMC-certified.

If your client's procurement names either as a requirement, we do not qualify, and no amount of assessment changes that. The distinction is worth holding onto because the two get conflated constantly in vendor conversations — "we host government clients" and "we are authorized" are different sentences, and only one of them survives a procurement review.

If your client's procurement requires source-code escrow

There is no source-code escrow arrangement today. If a client's contract template names escrow as a condition of signature, that is a live gap rather than a formality, and the place to raise it is the technical assessment, so it is addressed before anything reaches a signature page rather than discovered there.

The related fact is that the codebase is closed. We do not present that as a security feature, because it is not one — the honest reason is that every extension is built and maintained in-house, which is the real contrast with an estate assembled from third-party plugins. That is a trade with a cost on both sides, and it should be evaluated as one rather than sold as a benefit.

If the risk register needs a contractual continuity guarantee

There is no committed wind-down notice period you can write into a client's risk register today. A vendor that gets vague at this question has earned the lock-in objection, so to be plain: the guarantee does not exist, and what stands in its place is design rather than assurance.

What that means concretely is that the exit is engineered instead of promised. Content, structured data and media are reachable through an authenticated API, so a scheduled export can keep a current copy sitting with the client continuously rather than being requested during a crisis; and a front end your team builds against the headless API survives a change of back end, which bounds an exit to replacing one component. Whether that is sufficient is a judgement about your client's risk appetite rather than something this page can settle. The long version, written as a checklist to use against any vendor including this one, is in what an integrator needs from a platform before migrating a client off a legacy DXP.

Template ownership is narrower than it sounds

Templates and front-end markup are yours as files. Be precise about what that is worth: they are written against this platform's object model, so they port as reference rather than as runnable code. Ownership is not portability, and any vendor — this one included — that lets those two words blur together during an evaluation is doing you a disservice.

If genuine portability is a hard client requirement, template ownership is not the answer to it. The decoupled path is: your own front end, built by your team against the headless API, which is the part of the stack that actually moves.

A licensed, partner-hosted deployment is under evaluation — do not design around it

Some partners need the platform running inside infrastructure they control, usually because a client's own policy requires it rather than because they want the work. That option is under evaluation. There is no date on it, and a client's architecture should not be designed around it arriving. If it is a hard requirement rather than a preference, treat it as unavailable today and decide on that basis.

How to use this page in an evaluation

Take these to a technical assessment as questions rather than as settled outcomes, and make them answer against your actual estate. Each one changes shape when it meets a specific client: a compliance gap that disqualifies one pursuit is irrelevant to the next, and an exit-risk position a private client accepts in an afternoon takes a regulated one three months. Discussing them against a real portfolio is a different conversation from reading them on a page, and it is the conversation the assessment exists for.

One thing is worth saying about the list rather than the items on it: it is not complete. It is the set that can be stated precisely today. If a limit that matters to your client is not on it, ask directly rather than inferring from the silence — the questions a platform cannot answer yet are worth knowing about too, and they are considerably cheaper to surface during an assessment than during a delivery.