Choosing between a ServiceNow app and a standalone product

A request arrives: "we need a system for X." If you already own ServiceNow, there is a strong pull toward building it as a scoped application. Sometimes that is right. Often it is right for the wrong reasons — because the licence is already paid for, not because the platform fits.

Here is how we actually decide.

Build it on ServiceNow when the work is workflow

ServiceNow is exceptional at a specific shape of problem: a record moves through states, different people act on it at different stages, and the organisation needs an auditable history of who did what.

Signals that point to a scoped app:

• The primary users are already licensed ServiceNow users
• The process is approval-heavy or has real compliance requirements
• It needs to read or write CMDB, HR, or existing ITSM data
• Reporting must sit alongside your other platform reporting
• The workflow will keep changing, and you want that change to be configuration rather than a deploy

That last one is underrated. Platform workflow changes ship faster than code changes, and by people who are not engineers.

Build standalone when the work is product

The pull toward the platform gets weak fast in certain conditions:

• Users are external — customers, suppliers, the public. Licensing external users is usually the end of the conversation.
• The interface is the point. Consumer-grade interaction, offline behaviour, device hardware, push notifications, sub-second response.
• It needs to be on an app store.
• The data model is genuinely nothing like a task record.
• You expect high-volume anonymous traffic.

If three of those are true, forcing it onto the platform produces something that fights the platform for its entire life.

The two failure modes

Over-platforming. A customer-facing portal built as a scoped app because the licence existed. It works, but every UI change is a fight, external user licensing costs more than the build did, and the mobile experience is a compromise nobody defends.

Under-platforming. A standalone approvals tool built because the team wanted a modern stack. Six months later it is reimplementing notifications, audit history, role-based access, and an approval engine — all of which the platform already had, tested, and compliant.

Both mistakes cost roughly the same. They just fail at different times: the first hurts immediately and constantly, the second hurts once the novelty of greenfield wears off.

The middle answer is common

The framing "platform or product" is often false. A frequent shape:

• Workflow, records, approvals, audit live on ServiceNow
• The interface external users touch is a separate web or mobile app
• They talk over a documented API boundary

You get the platform's workflow engine and compliance story, and a front end that is not constrained by portal widgets. The cost is an integration to own, which is real but bounded.

Questions that settle it quickly

When it is genuinely unclear, these usually decide it:

1. Who logs in, and are they licensed? External users at any scale push standalone hard.
2. If the process changes next quarter, who changes it? If the answer is a business analyst, that argues for the platform.
3. What happens to this data in an audit? If someone will ask "who approved this and when", the platform has already solved it.
4. Would you still build it here if the licence were free? This one strips out sunk-cost reasoning better than any other question.

If the honest answer to the last one is no, you have your answer — and the licence you have already paid for is not a reason to build the wrong thing.

What we do about it

We run all three practices, which means we have no structural incentive to push you toward one. The scoping conversation is genuinely about fit, and sometimes the honest recommendation is a smaller project than the one you asked about, or one built somewhere other than where you assumed.