How to evaluate a white-label DXP: the questions that separate them

Most platform evaluations are run off a feature matrix, and a feature matrix is the document vendors are best at answering. Every row comes back a yes. The questions that actually separate one white-label platform from another are the ones with an uncomfortable answer, and an uncomfortable answer never fits in a row.

What follows is the list we would use ourselves if we were choosing a platform to deliver client work on for the next five years: ten questions, what a weak answer sounds like, and our own answer to each, labelled as ours. WebinOne is an AWS-native digital experience platform built by Upgrade Parade Corp, formerly Treepl CMS, delivered white-label by agencies and systems integrators — so we are not a neutral author, and the only test that matters for this list is whether it stays useful when you point it at us.

Whose cloud account does the platform actually run in?

Ask it as an account question, not a hosting question. "We run on AWS" names a supplier; it does not tell you who holds the account, the IAM boundary, the billing relationship with the cloud provider, or whether your own tooling can be pointed at any of it. Those four things decide what your practice can and cannot do on its own.

Ours, in one sentence: production sites run in the platform's own AWS account, operated by the platform team, and that is what every partner is delivering on today. A different arrangement is available by agreement — a custom licensing and setup quote, priced deal by deal — and it is a commercial conversation rather than a switch you can plan a bid around. If your practice holds its own cloud accounts and standardises on its own monitoring or infrastructure-as-code, establish that boundary in week one. It is a workable constraint and an expensive discovery. The full topology — what the platform team operates, what your practice operates, and where the line falls between them — is set out separately in what runs where, and whose account it runs in.

What exactly is white-labelled, and where does the vendor's name still appear?

"Fully white-label" is the least informative sentence in this category. Ask for the enumeration instead: the admin login screen, the admin interface itself, notification emails to your client, the support channel, the subdomain a staging site sits on, the invoice your client receives, and the documentation your client's team will read when they are trained. Different platforms stop at different points along that list, and the point where a platform stops is the point where your client learns the name of your supplier.

Ours is enumerated on the partner programme page rather than summarised: sites are white-labelled under the partner's brand, with granular white-labelling, branded subdomains, portal user management, direct billing available, and a customisable commission depending on partner level. Where our name still appears: the documentation, the public forum and the community are ours and are public, so a client who goes looking will find the platform. We would rather state that than let you find it after the training session.

What happens to your client's sites if the vendor stops trading?

Do not accept reassurance here, and do not accept company age as an answer. There are only three real forms an answer can take: an operative clause in the terms you are signing, a source-code escrow agreement with a named agent, or nothing. Ask which of the three it is, then read the actual text — this is the one question on the list where the answer is a document, not a conversation.

Ours is the first form, and here it is verbatim from our terms of service: "In case of an unlikely event of the Service being closed or discontinued for any reason, we commit to open-source the WebinOne platform to the level that every Reseller would be able to host their trial and live sites, WebinOne Portal, and SSO service without our support." It is Reseller-scoped, which is exactly the reader of this article. What it is not: there is no source-code escrow arrangement today, and the codebase is closed while the service is operating — so this clause is the continuity mechanism rather than an addition to one. Read it as what it is, take it to your own counsel, and hold every other vendor to producing something you can read the same way.

Which certifications does it hold, and which does it not?

The useful version of this question is the second half. "Enterprise-grade security" and "secure and compliant" are unfalsifiable and every platform in this category publishes them, including us. Named frameworks are falsifiable, which is why the informative answer is the list of the ones a platform does not have.

Ours: there is no FedRAMP authorisation and no CMMC certification. If a bid has either as a hard requirement, we are not the platform for that bid, and you should know that before you write the response rather than during it. Everything beyond that belongs in a security review with a specific control list in front of both parties, not in a marketing claim on either side.

Where does front-end work happen, and what ports out if you leave?

Two questions that vendors answer as one. Ask them separately, because "you own your templates" and "your templates run somewhere else" are entirely different statements, and only the first one is usually true. The follow-up that settles it: what specifically comes out in an export, item by item, and what does it run against once it is out?

Ours: front-end work happens in our object model and template layer by default, and the headless API is the other supported delivery path, extended when a project needs something it does not yet cover — as scoped work on our schedule, not as something your engineers unblock at midnight. Templates and markup are yours as files. Written against our object model, they port as reference rather than as runnable code, and that distinction is the whole of the honest answer. Do not accept the phrase "full export" from any vendor, ourselves included; ask for the inventory.

Where can a client's data sit, and who decides?

For anything public-sector, healthcare or EU-facing, this stops being an infrastructure detail and becomes a qualification criterion. Ask where the footprint is today, what the mechanism is for a requirement outside it, and — the part usually left vague — who decides which location a given client lands in, and at what point in the process.

Ours: on AWS, across six AWS regions, with data residency options for compliance requirements. Which location a specific client's site runs in is confirmed in the technical assessment rather than chosen from a dropdown. If a requirement falls outside the current footprint, an additional AWS region can be stood up on request; our own account of the effort is hours of provisioning work rather than a procurement cycle, which is our figure and not an audited one, so ask for it against your specific case. What that reliably tells you is the shape of the answer: for us, "can you run this client in region X" is a scoping question rather than a roadmap question.

Can your client see their own consumption, or only you?

An unusual question that separates platforms sharply, because the answer is a pricing decision as much as a feature. A platform that hides infrastructure consumption from the tenant leaves you defending an invoice with numbers your client cannot verify. A platform that surfaces it hands you a client who can see for themselves why the next configuration costs what it costs.

Ours: live AWS charts, pulled from AWS and rendered inside the site's own admin panel, visible to the site owner and not only to you. The dedicated hosting page has the full inventory around it — base servers sized in cores and RAM, a dedicated IP, an optional dedicated RDS instance, and extra servers scheduled by the hour from a calendar in the site admin for a known traffic peak. One item on that page is worth reading before you architect anything: load balancing across a configuration of two or more servers runs through a Cloudflare integration, and the partner is required to hold the Cloudflare account. The rest of that inventory, and what a dedicated deployment does and does not include, is in our architecture page for integrators.

When a vendor says "no limits", what is the delivery mechanism?

Every platform in this category says some version of it. The question that turns the phrase into information: which of three mechanisms is it? A configuration surface you operate yourself, a third-party plugin ecosystem you inherit and maintain, or the vendor's own team doing scoped work. Each carries a different cost, a different lead time and a different failure mode, and a vendor that will not name which one it is has told you something too.

Ours is the third. Platform functionality, including ecommerce, is extended as scoped and quoted project work by our in-house delivery team. That means a defined deliverable with a date and a price rather than a toggle, and it means there is no marketplace of third-party extensions for you to inherit and no plugin conflict for you to debug at 2am. Both halves of that are true, and which half matters more depends entirely on whether your practice would rather own the fix or own the timeline.

What does it cost you to actually test the platform?

Every question above can be answered on a call, and a call is worth less than one real workload. So ask what standing up a genuine build costs in time, in procurement, and in commitment — and treat a long answer as a finding rather than an inconvenience.

Ours: a partner or partner agency account and a chosen configuration. Dedicated provisioning is stated at one business day, with no sales or technical interview to get started. Take one real client, put a real build on it, and you will settle more of this list in a week than in a quarter of evaluation calls.

Which questions should you drop from a comparison?

Feature counts and API counts, first. A count tells you nothing about whether the one capability you need exists, and it is the number most easily inflated on any vendor's own site. Ask any platform — us included — to evidence a figure you intend to rely on, and treat a number without a stated method as a number without a source.

Apply the same rule to us and you get a working example. Our own published migration figure is more than 3,000 sites moved onto the platform; that number reached us through our cloud marketplace listing rather than through a stated sample, so it is exactly the claim to ask us to evidence on a call. The migration path itself is documented, named client deployments are collected on our enterprise page, and our own delivery team is described on its own page. The last thing to drop is the third-party comparison page ranking on a platform's name: it is written by neither the vendor nor a user of the product, and it exists because nobody answered the question first. That is the case for asking these ten questions directly, of every platform, including this one. The two most uncomfortable answers we have are already published — what an integrator should require from a platform before migrating a client off a legacy DXP, and where WebinOne is the wrong choice — and the briefing for systems integrators covers what the platform is before any of this becomes relevant.