Article
Nobody evaluates year five
Platform decisions get made on a feature comparison and a first-year price, then lived with for a decade. The two costs that compound — capability you never switch on, and an upgrade that becomes an annual project — are in neither column.
On this page
Every platform evaluation I have sat in has produced the same artifact: a spreadsheet with products across the top, requirements down the side, and a great many ticks.
It is a reasonable way to decide. It is also why the two largest costs in the decision never get compared. Neither of them is a requirement, and neither of them arrives in year one.
The first is that you are licensing a whole product and using a corner of it. The second is that somebody has to keep it current, forever.
You pay for the product, you use a corner of it
Enterprise content platforms are priced against their full capability: personalization engines, commerce modules, multi-site trees, campaign tooling, a marketplace of extensions. That capability is real, and some organizations genuinely need all of it.
An association usually needs a shorter list. Publish and edit pages. Manage images and documents. Run an events calendar. Put a members-only area behind a login. Let staff who are not developers change things without filing a ticket.
When that is the list, the feature comparison is actively misleading. The product with the most ticks wins a contest that was scored on capability nobody is going to open. And the license does not discount the parts you leave shut.
The product with the most ticks wins a contest scored on capability nobody is going to open.
The upgrade is the cost nobody models
A major platform version arrives on a yearly or near-yearly cadence, and each one has to be taken. Falling behind eventually ends support, and an unsupported CMS facing the public is a security position rather than a technology one.
Taking it is a project. Customizations written against the previous API get revisited. Integrations get retested. There is a window where the site is being watched rather than used. And at the end of it, the organization has exactly the capability it had at the start.
That is worth saying plainly. An upgrade usually delivers nothing a member, a visitor or a staff member can see. What it delivers is permission to keep receiving support. It is a cost of ownership that is structurally invisible at purchase, because at purchase it is still four years away.
A third option, and who ends up owning it
Build or buy is usually posed as two choices. There is a third, and it is the one we took: build a product once, keep it current, and start every client from it.
Lighthouse is our own content and CRM platform. ASP.NET with an Azure SQL back end, running either on a client's own server or in their cloud tenancy. A new engagement does not begin at a blank page — it begins at the Lighthouse base template, which is then built out around how that particular organization works.
What the client ends up with does everything you would expect of any CMS: add pages, edit content, swap images, manage media, run the parts of the site their own team owns. What it does not contain is a second half they are not using.
And then they own it. The product is licensed to the client outright — a one-time build cost rather than a recurring license, and if they want a different firm to take it on next year, they can hand it over and we help them do it. No seat count, no renewal, no version they are being carried toward.
That inverts the usual arrangement, in which the supplier's hold on the client is the software. We would rather the reason to keep working with us was that the work is good. It is a harder thing to rely on and a better one.
Why the architecture is the commercial argument, not a detail
Lighthouse is decoupled. The interface, the middle layer and the database meet at API boundaries rather than inside one monolith. That reads like an implementation note and it is actually the whole case.
It means the front end can be redesigned or rebuilt without touching the back end, and the back end can move forward without forcing a front-end migration. We keep the base template current with each technology release, so when a client wants that work applied it lands against seams that were designed to be crossed. An upgrade becomes something you schedule rather than something you survive.
Where this is the wrong answer
Two limits, stated honestly, because a page that only lists advantages is an advertisement.
Owning it means owning it. Outright ownership answers the lock-in question, and it hands you a responsibility in the same motion. A product you own is a product somebody has to keep current — us, your own team, or whoever you choose next. What makes that a real option rather than a theoretical one is that nothing underneath is exotic: ASP.NET, SQL Server or Azure SQL, REST APIs, on infrastructure you control, with the data in a standard relational database any competent team can read. That is deliberate. Software nobody else could pick up is only nominally yours.
A large commercial platform buys you an ecosystem. A marketplace of extensions, a labor market of people who already know it, and a vendor whose roadmap is not your problem. If the thing you need already exists as a plugin, buying it is the cheaper answer and we will say so.
The case for owning the base is strongest where requirements are specific, usage of a large platform would be narrow, and the organization expects to live with the result for a decade. Associations and nonprofits are the clearest example, which is why most of ours are running on it.
Three questions worth asking in any platform evaluation
What share of this product's feature set will we have switched on a year from now?
If the honest answer is a third, you are paying for the other two.
Who runs the upgrades, how often, and what do they cost in people and downtime?
Ask about the last three upgrades, not the brochure.
If we and the supplier part company, what do we actually hold?
The data, the source, a contract, or a conversation. Get the answer in writing, from us as readily as from anyone else.
The point
A platform decision is made on features and a first-year price, then lived with for a decade. The two costs that compound — capability you never switch on, and an upgrade that becomes an annual project — are in neither column of the comparison that decided it.
Owning the base is not automatically the right answer. It is a third option, and it changes which of those costs you are signing up for.
Filed under
Written by
Lead Engineer, Modern Signal
Modern Signal's engineering practice, working on the Lighthouse platform and the client systems built on it.
Related
Want a second opinion on your own estate?
Tell us what it looks like today and we will tell you what we would look at first.