When a custom app is cheaper than a product, when it is not, and why the decision is made by architects who never see the price. Three knowledge checks along the way, and 3 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 3 times in the session the frame splits and a senior licensing analyst gives the view from inside real ServiceNow negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twenty one, module five opens, and we move from the products to the platform underneath them. Today is build versus buy, and I want to set it up honestly, because this is the session where a licensing course has to talk about a decision that is not a licensing decision. Build versus buy gets settled in a design review. Architects, developers, a product owner, sometimes a vendor management person if you are lucky and usually not. They weigh fit, effort, elegance, maintainability, and they are all legitimate criteria and they are all the right things to weigh. The licence is not in the room. And the outcome of that meeting commits you to a cost structure for years, in one direction or the other, decided entirely by people who have never seen the order form. So today is about getting four questions into that meeting. Three checks, homework, let's go.
Five objectives. First, frame the decision as a commercial choice rather than an architectural preference, which is not a criticism of architects, it is a statement about who is in the room. Second, cost a build honestly, which means App Engine licences plus tables against your allowance plus the people, and then the maintenance nobody budgets past year one. Third, cost a buy honestly, the product line on its own unit, its tier ladder, and the platform seats sitting underneath it, which module four spent five sessions on. Fourth, spot the hybrid trap, the custom app that reaches into process data and ends up costing you both, which is the boundary we drew back in session thirteen. And fifth, govern the portfolio, treating custom applications as a managed set with owners and retirement dates rather than as a collection that only grows.
Four framings. Two meters, because a build consumes App Engine users and your custom table allowance while a buy consumes a product's own unit, and those two things are never directly comparable without somebody doing work to make them comparable. Fifteen to forty percent, custom table growth across a single term as teams shipped applications against a fixed allowance, and the point about that number is that build decisions accumulate and nobody ever counts them together. Both, which is what a custom app that reads or writes process data costs you, App Engine plus process licensing, and it is the single most expensive outcome available to you. And year two, which is when a build's real cost shows up, because the licence is visible at year one and the maintenance and the tables and the person who owns it are not. The note underneath matters. Nobody in that design review is doing anything wrong. The commercial consequence simply is not in the room, and that is the same structural gap as every other session in this course.
Guest analyst clip. I got invited to a design review once, which almost never happens, and it was genuinely instructive. The question on the table was whether to build a custom application for a fairly specialised approvals workflow or to extend a product they already owned. And the discussion was good. Really good. People argued about data models, about upgrade impact, about who would maintain it, about whether the product's shape would fight them in eighteen months. Everything you would want. It went about ninety minutes and it was heading firmly toward build, and I would say the technical argument for build was the stronger one. Then somebody asked me why I was there, and I said I had one question, which was what the two options cost over three years. And the room went quiet, not because anybody had missed something obvious, but because nobody had ever been asked that question in a design review before. They did not have the number. It was not in anybody's job to have it. They ended up building it, by the way, and I think that was the right call. But they built it knowing what it cost, with a named owner and a review date, which is a very different thing from building it because building felt natural. My advice is not that architects should think about licensing. My advice is that somebody who does should be in the room for ninety minutes, once, at the point where the decision is still open.
Somebody who does think about licensing should be in the room while the decision is still open. And notice the outcome there, because they still built it. This session is not an argument against building. It is an argument against building by default, which is a different thing and a much more common one. So, the three cases.
Four rows, three of which are real outcomes and one of which is an accident. Build on App Engine is genuinely right when you have a workflow that is specific to your organisation, running on its own data, with no product that fits it, and the failure mode is building because building is culturally easy and then maintaining it forever with nobody named. Buy the product is right when the workflow is common and a product already models it, because you would be rebuilding that shape yourself anyway, and the failure mode there is module four's failure mode, buying at the tier and scope of maximum ambition. Neither is right more often than anybody considers, when the requirement is real but small and a form, a report, or a process change actually serves it, and its failure mode is simply that it rarely gets considered at all, because a platform makes building feel like the default answer to everything. And then the fourth row. Both, accidentally, which is right never, and which happens when a custom app touches process data and you pay App Engine and process licensing for the same workflow. That is not a strategy. It is what happens when the session thirteen boundary gets crossed without anybody noticing, and it is worth naming precisely so that you can avoid it deliberately.
So what does a build actually cost, five lines. The App Engine licences, Creators and Builders to develop it and Users to consume it, on the typing we did in session thirteen where almost everybody belongs in the cheap tier and frequently is not put there. The table allowance, because every table the app creates draws against a fixed contractual number, and that draw is free at build time and priced at renewal, which is the worst possible timing for finding out. The people in year one, which is the visible cost, usually the only one in the business case, and in fairness usually the accurate one. The people every year after, maintenance, platform upgrades, and the moment the person who understood it leaves, and this is where builds quietly beat their estimates. And the retirement that never happens, because custom applications outlive their sponsors and their tables outlive them again, which is exactly why session thirteen's register exists. Four of those five lines are recurring and one of them is the one that gets counted.
Knowledge check one. A team proposes building a custom app instead of buying a module, citing a lower first year cost. What is missing from that comparison? A, nothing, first year cost is the fair comparison. B, the table allowance draw, ongoing maintenance, and retirement that never happens. C, only the App Engine licence cost. D, the product's discount, which would close the gap. Pause here, and ask yourself which costs appear after the business case is approved.
The answer is B. First year build costs are usually accurate and usually incomplete, which is a distinction worth holding on to, because the team proposing this is not being optimistic or evasive. The licence is visible. The allowance draw is invisible until renewal. And the maintenance is a recurring commitment that nobody attaches a number to because nobody is asked for one. Answer C names only the cost the team already counted, so it adds nothing. Answer D is a completely fair point about the buy side, and it does not fix the build estimate, it just moves the other number. The rule is straightforward. Compare both options across the same term, three years minimum, or you are comparing a full price against a partial one and the partial one wins every time regardless of which option is actually cheaper.
Now the buy side, and it deserves the same honesty. The product line on its own unit, fulfillers or employees or devices or fulfilled users depending entirely on which family it belongs to, and module four was five sessions on exactly that question. The tier you get quoted, which will be the tier of maximum ambition unless you apply the buyer test on measured use. The platform seats underneath it, because the people operating that product still need platform licences, and that layer turned out to be the largest one in session eighteen. The uplift, compounding, because every product line uplifts annually, which makes a buy a growing commitment while a build's licence cost is comparatively flat. And then the fifth point, which I want to give proper weight to. You get the roadmap. Product improvements arrive without your effort, which is a genuine advantage that a build never has, and which almost never appears in the comparison because it is hard to put a number on. That does not make it worth zero.
Knowledge check two. Over a three year term, which cost line most often decides build versus buy in the estates we review? A, the first year licence difference. B, the maintenance and ownership cost of the build, plus the uplift on the buy. C, implementation services on the buy side. D, the training cost for end users. Pause here, and ask which lines keep running after year one.
The answer is B, and notice that both halves of it are recurring and both are usually missing from the comparison. The build's ownership cost is real effort that nobody budgets past year one, and the buy's uplift compounds on a base that is itself growing. Answer A is the number the business case gets built on and it is the least decisive line over a full term, which is an uncomfortable thing to say about the number everybody uses. Answer C is a genuine one off cost and it rarely flips the decision by itself. Answer D is real and small. The rule to take away is compare recurring against recurring over the same horizon, and if the comparison you are looking at does not do that, then it is decorative rather than analytical, however carefully it was assembled.
Now the hybrid, which is the outcome that pays twice. A custom app that reads or writes ITSM, HRSD, or CSM data has crossed into process licensing, so you are carrying App Engine and the process product for the same workflow. Four cards. How it happens, which is that the build gets scoped as standalone and then a perfectly sensible integration gets added later because the data is right there, and no decision is ever revisited. Why it is worst, because you pay App Engine for the build, process licensing for the crossing, and you still own the maintenance that a product would have carried for you. The design question, which is whether this app needs live process data or a copy, a summary, or a link, and about half the time the requirement survives without crossing at all. And the honest reckoning, the fourth card, which is the useful one. If the app genuinely needs process data continuously, that is strong evidence that the product was the right answer all along. An app that keeps reaching into process data is telling you something about the requirement, and it is worth listening before the third integration.
Guest analyst clip. The most expensive custom application I have ever looked at was not expensive because it was badly built. It was well built. It started as a standalone tool for a specialised operational process, entirely reasonable, no product fitted it, App Engine was exactly the right home. Then over about two years it grew three integrations into the process estate. It read incident records to show context. It wrote a task back when something needed action. It pulled from the HR data for approvals routing. Each of those three was a small, sensible, well argued change, requested by users who wanted the tool to be more useful, approved by people who were right that it would be. And at the end of it, the organisation was paying App Engine licensing for the application, process licensing triggered by the crossings, and carrying the full maintenance burden of a bespoke system. All three costs, none of the roadmap. What I said to them, and I will say it here, is that the third integration was the signal. One integration is an app that touches the process estate. Three is an app that lives in it. And if it lives in it, the honest question is not how to license it more cleverly, it is whether the product you were avoiding was the right answer two years ago and is still the right answer now.
One integration is an app that touches the process estate, three is an app that lives in it. And notice again that nobody made a bad decision, they made three good small ones without anybody looking at the shape they added up to. Which is precisely the argument for treating custom applications as a portfolio.
Five rules for governing the portfolio, and none of them are difficult. Every app has an owner, a named person rather than a team that has since reorganised, and ownership is what makes retirement possible later. Every app has a review date, annual, asking one question, is this still used and by whom, and the usage data answers it in minutes. Every app has its tables counted against the allowance, from the register we built in session thirteen, so the portfolio's licensing cost is visible as one number rather than as forty invisible ones. Every app has a boundary test recorded, does it touch process data, decided deliberately at build and rechecked whenever an integration gets added, which is the control that would have caught the story you just heard. And retirement is a funded activity, because switching an app off takes real effort that nobody is rewarded for, which is exactly why it does not happen unless somebody schedules it and pays for it.
Knowledge check three. Your estate has forty custom apps. Nobody can name an owner for twelve of them. What is the licensing consequence? A, none, unowned apps still work fine. B, their tables draw on the allowance permanently, because unowned apps are never retired. C, they should be deleted immediately. D, only a security consequence, not a licensing one. Pause here, and ask what actually happens to an application nobody owns.
The answer is B. An app without an owner has nobody who can authorise switching it off, so it consumes allowance indefinitely regardless of whether anybody uses it, and that is how a third of custom tables end up belonging to applications that nobody in the building can identify. Answer C is right about the direction and wrong about the method, and I want to be clear about that because it is tempting. Deleting applications you cannot identify is how you break a process that somebody depends on quietly, usually a finance process, usually at quarter end. Assign owners first. Then let the owners retire what is dead, which they will, because owners of dead applications are generally quite happy to stop owning them.
So here is the framework, four questions, asked before the design review ends. One, does a product model this, because if a product already models the workflow then building it means rebuilding a shape that somebody else maintains, and that is sometimes still the right call but it should be a deliberate one. Two, does it touch process data, and if yes then price the crossing now rather than discovering it later, and if the answer is yes and permanent then the product was probably the answer. Three, what is the three year cost of each option, licences plus tables plus maintenance on one side against product line plus tier plus platform seats plus uplift on the other, recurring against recurring. And four, who owns it in year three, and the answer has to be a name, because if nobody can be named then the build is already carrying its most expensive future cost before a line of code exists. None of those four questions needs a licensing expert in the room. They need somebody to ask four questions while the decision is still open.
Guest analyst clip. Of those four questions, the one I would fight for if I could only have one is the last one. Who owns this in year three. And the reason is that it is the only question in the set that a design review cannot answer with an opinion. The first three questions produce debate, and debate is fine, people argue about whether a product really models the workflow and whether the cost model is fair and reasonable people land differently. The ownership question produces either a name or a silence. There is nothing in between. And the silence is enormously informative, because what it tells you is that everybody in the room is thinking about building the thing and nobody in the room is thinking about the seven years after it is built. I have started asking it in places that have nothing to do with ServiceNow, by the way, because it works on any build decision anywhere. Put it on the design review template. It costs nothing, it takes ten seconds, and my honest experience is that about one time in four the room changes its mind, not because somebody argued them out of it, but because the question made visible a cost that everybody had been carefully not looking at.
The ownership question produces either a name or a silence, and there is nothing in between. Put it on your design review template this week. Session twenty two continues module five with Integration Hub and transaction based licensing, where the meter counts machine activity rather than people, and nobody is watching it at all.
Three sentences. The decision is made in design reviews by people weighing fit and effort, all legitimate criteria, none of which is the licence, so the commercial consequence gets decided by people who never see it. A build costs App Engine licences plus table allowance plus maintenance that nobody budgets past year one, while a buy costs a product line on its own unit plus a tier plus platform seats plus a compounding uplift, and the honest comparison is recurring against recurring over three years. And the worst outcome is the accidental hybrid, where a custom app reaches into process data and you pay both, and an app that keeps reaching is telling you the product was the right answer.
Homework, about an hour, five items. Count the portfolio, how many custom applications your estate runs and how many of them have a named owner today, and the gap between those two numbers is your first finding. Find the hybrids, which custom apps read or write ITSM, HRSD, or CSM data, because each one is a crossing that should have been priced. Cost one build over three years, pick your largest custom application, licences plus tables plus the effort to maintain it, and compare it against what a product would have cost, and do it properly because the exercise teaches you more than the answer does. List the unowned, apps with no owner along with their table counts, and that list is simultaneously your retirement backlog and your allowance recovery. And add the fourth question, which means getting who owns this in year three onto your design review template. It costs nothing and it changes decisions.
Five guides. App Engine licensing explained is the build side priced properly, the tier, the user typing, the table allowance, and the boundary rules that create the hybrid, and it is the one to read first if you hold App Engine today. The ServiceNow products list for 2026 is the buy side of this decision, what the catalog already models, which is worth checking before anybody builds it again. The license rightsizing playbook applies the portfolio review discipline to custom applications as well as to users and products. Avoiding true up surprises covers how custom tables consume entitlement quietly, which is the build cost that only ever surfaces at a renewal. And the 2026 pricing tiers pillar gives you the packaging context for the buy side, including what is now bundled and therefore not worth building around. Next time, Integration Hub, robotic process automation, and transaction based licensing, which is where the meters stop counting people entirely. See you there.