The worst Extend app is the one Workday delivers next year
The worst outcome available in Workday Extend is a custom app that duplicates something the vendor later ships. You carry the build cost and the regression testing forever, you get none of the improvements the delivered feature picks up, and removing your version turns into its own small project that nobody funds. Most Extend portfolios I have reviewed hold at least one, still running, still owned by somebody who inherited it.
The tension behind that outcome does not resolve itself. A delivered product has gaps, the gaps hurt named people in named meetings, and a platform that lets you close them is sitting right there in the tenant. Workday's feature releases arrive twice a year, so a gap that hurts this month has a real chance of closing inside a year, which is roughly the time it takes a custom app to acquire its first set of dependencies.
The capability question gets settled in the first ten minutes, because Extend can usually build what people ask for. If you are still establishing what Workday Extend actually is, start there. The hour that follows should go on timing, the part teams skip and then pay for.
The honest tests for waiting
Start with how common the gap is. A need that hundreds of customers describe in the same words, at the same stage of the same process, is a need somebody at the vendor has heard repeatedly. A need shaped by your works council agreement, your acquisition history or one region's payroll calendar is a need that will stay yours. Common gaps get delivered eventually. Specific gaps do not, and community upvoting does not change that.
Then ask what the vendor has signalled. Release previews, community sessions and roadmap decks each tell you something, and none tells you enough to plan against alone. A roadmap is an intention rather than a commitment, and intentions move when priorities move. Write down what you heard and the date, then make a plan that still works if the signal is wrong. Tracking the cadence and what actually lands in each release teaches you more about delivery odds than any slide will.
The third test asks whether the pain is tolerable for a year, and people answer it with feeling. Answer it with numbers instead. Hours per month on the workaround, multiplied by the number of people doing it, multiplied by twelve. The error rate on the manual step, and the count of service desk tickets the gap produced last quarter. A small number says wait, even when the loudest person in the room wants a build slot.
The tests that justify building now
Build when the process reflects something genuinely distinctive about how your organisation runs. No vendor will ever deliver the approval chain your union agreement created, or the way your business reassigns cost centres after every reorganisation. Distinctive means the part that would be wrong if a competitor copied it, a much narrower set than most sponsors claim.
Build when the cost of waiting is measurable and large, and treat measurable as the harder half of that test. A finance lead who can show that a manual reconciliation consumes four days of a senior analyst's month has made the case. A director who reports that the current process is painful has not, and the right response to that sponsor is a request for the number, not a place in the backlog.
Build when the capability changes what your organisation can offer rather than how comfortable the work feels. An app that gets contractors productive in two days instead of eleven is worth owning, because a delivered equivalent arriving next year still leaves you a year of advantage. An app that removes three clicks from a page people open weekly is a convenience, and conveniences wait. The boundary argument about where an Extend app should stop sits directly underneath this test.
Build something you have already agreed to throw away
The option most reviews never put on the table is the deliberately minimal build. You accept that Workday will probably deliver this capability, you build the smallest thing that relieves the pain, and you size it so that deleting it costs less than keeping it. No extra fields, no reporting layer, no integration, and no scope added by the second stakeholder who hears about it in the corridor.
That sizing decision carries the whole strategy. A minimal app is one somebody can remove in an afternoon because nothing else depends on it. The moment a second app reads its data, a report cites its fields, or a business process routes through it, removal stops being an afternoon and becomes a project with a change board slot. Keep the stopgap isolated deliberately, even where wiring it into everything else would be easy.
This approach only works if somebody records the intention, in the place your team genuinely reads rather than in a chat thread. Write down that the app exists because the capability has not been delivered yet, what would count as the delivered equivalent, and who is expected to retire it. An undocumented stopgap becomes permanent by default. The organisations that suffer are the ones holding temporary things nobody remembers were temporary, and the intake conversation before a first custom app is the natural home for that record.
Somebody has to be watching for the delivered version
If you build while waiting, somebody has to read release notes with your app specifically in mind. Not reading them in general, which every team claims to do. Reading them against a named list of custom apps, every release, asking for each one whether the delivered equivalent has arrived and covers enough of the requirement to matter.
Somebody also has to be willing to remove the custom version once it does arrive, and that is the harder half. The person who built the app is usually the person who would have to retire it, and the app still functions perfectly well. Removing something that functions needs a decision taken in advance by somebody senior enough that the builder's attachment does not decide it. Name that person while everyone is still enthusiastic, because nobody volunteers for the job a year later.
Without those two names, build while waiting fails every time, and it fails quietly. The custom app keeps running, the delivered feature ships unused, and two years on a new architect finds both and has to work out which one the payroll numbers came from. Put the app on a retirement list the day it goes live, because a modernisation programme needs a retirement list and not only a build list, and give that list a standing review date.
The sentence to get in writing before you approve a build
Before approving any Extend build, ask the sponsor to state in writing what happens to the app if Workday delivers the same capability within the next two releases. Three answers are acceptable. We remove it, and this named person does the removal. We keep it because our version does something the delivered one will not, and here is what that something is. We may well be wrong, and we have sized the build so deleting it is cheap.
An answer that names no person is not an answer. An answer that says the team will deal with it when the time comes means the app will still be running in five years, duplicating something the vendor supports, showing up only as a regression pass nobody can explain. Whichever of the three you get, the lifecycle practices for Extend apps determine whether the survivors stay healthy after the decision.
Take the Extend proposals sitting in your backlog right now and write that sentence against each one before the next governance meeting. Send the ones with a named remover to build. Send the ones without back to the sponsor with the number you want them to produce, and say plainly that the build waits until the number exists.
