Borrowed Structure Is Not Neutral
Someone has prepared a demonstration for you.
The screens look familiar. There are records, statuses, a dashboard, some workflows. The presenter moves through it efficiently, anticipating your questions before you ask them. Toward the end, someone says the words: “this gets you seventy percent of the way there.” The timeline looks reasonable. The budget looks manageable. The remaining thirty percent sounds like configuration.
You approve the project.
Eighteen months later, you are in a different kind of meeting. The system is live, technically. But the data is unreliable, the users have workarounds, the reports don’t reflect how the business actually operates, and the team that built it has moved on. Someone is now explaining why extending the system to cover the next use case will require a significant re-architecture.
The thirty percent was never configuration. It was the part that mattered most — and it was built on top of a structure designed for someone else’s business.
This is the accelerator problem. Not that accelerators fail to deliver. They often deliver exactly what was demonstrated. The problem is what the demonstration could not show you: the assumptions underneath it, the decisions already made on your behalf, and the cost of discovering — too late — that borrowed structure is never neutral.
An accelerator is not a collection of reusable components. That is how it is sold, but it is not what it is.
An accelerator is someone else’s theory of your business.
It contains decisions — made before your project started, before anyone spoke to your users, before anyone understood your domain — about what your important business objects are, how work begins and ends, which roles matter, how relationships should be represented, and which variations are normal versus exceptional. Those decisions are embedded in the data model, the workflow model, the security model, the terminology, and the extension points. They are not visible in the demonstration. They become visible later, when your reality starts pulling against the structure underneath.
This is not unique to third-party accelerators built by vendors or consulting firms. First-party business applications carry the same risk. A CRM system, a case management product, a licensing platform, a service portal — any mature application that becomes the foundation for a broader solution is functioning as an accelerator. You are starting from someone else’s model and building toward your own. The question is whether you know that, and whether you have tested the model before you have built on top of it.
Most organizations have not. The demonstration does not invite that question. The timeline does not budget for it. And the people presenting the accelerator have strong incentives to characterize its assumptions as standard practice — which is sometimes true, and sometimes the most expensive sentence in the project.
Standard practice for whom? Designed around which business? Validated against what variation?
These are not hostile questions. They are the questions that determine whether the seventy percent you are inheriting is actually aligned with the structure of your work — or whether it is aligned with a generalized version of your industry that fits well enough in a demo and diverges steadily in production.
Every business application project requires discovery. That is not a methodology preference — it is the nature of the work. Someone has to understand the organization, the users, the outcomes, the operating model, the exceptions, the data, the decision points, and where the business is likely to go. That understanding is what separates a system that fits from a system that was delivered.
Accelerator projects do not eliminate that discovery. They add a second one.
The team now has to discover two things simultaneously: your business, and the accelerator’s. How it thinks. How it represents the domain. What it assumes. What it supports easily and what it resists. Where its model is flexible and where it is fixed. What happens when your reality does not fit neatly inside its structure.
Two discoveries. One budget. One timeline. One pool of attention.
This is where projects quietly go wrong — not in a single decision but in a slow drift of priorities. The accelerator’s discovery is concrete and immediate. There are configurations to understand, dependencies to map, extension points to find. It produces visible progress. The business discovery is harder and slower. It requires conversation, judgment, and tolerance for ambiguity. It does not always produce something you can put in a status report.
When those two discoveries compete, the accelerator’s tends to win. Not because anyone decided the business mattered less. Because learning how to configure a system feels like doing the work, and it is easier to measure.
The result is a team that becomes expert in the accelerator and approximately familiar with the business. They can explain every field, every workflow, every permission boundary in the inherited structure. They struggle to explain why the system was designed this way rather than another way, or whether it actually reflects how the organization operates.
That is not a skills failure. It is a structural one. The project was set up to answer the wrong question first.
Understanding how to configure an accelerator is not the same as understanding the business problem. Learning where a field lives is not the same as understanding what the organization needs to know. Mapping a process into a workflow engine is not the same as understanding the decisions that process is supposed to support.
By the time the gap becomes visible, the structure is built. Changing it is no longer a design decision. It is a re-architecture.
There is a version of this conversation that never happens in the demonstration room.
The platforms themselves are the accelerator.
Modern business application platforms did not leave the speed problem untouched. Most now include mature data services, forms, workflow, reporting, identity, security, integration, automation, and low-code development capabilities that would have taken years to build from scratch a generation ago. That is already a form of acceleration. In many cases, it is the most important one.
What is being sold on top of that — as an accelerator — is someone else’s configuration of those tools. Someone else’s data model. Someone else’s workflow assumptions. Someone else’s interpretation of what a case, a request, a customer, an approval, or a service looks like. Packaged, demonstrated, and positioned as a shortcut.
It is not a shortcut. It is a substitution.
Instead of doing the work of understanding your business and designing a structure that fits it, you are adopting a structure that was designed for a generalized version of your business and hoping the gaps are manageable. Sometimes they are. More often they are not — they are just discovered late, after the structure is load-bearing.
The consulting firms and vendors who build and sell accelerators are not acting in bad faith. They are responding to real market pressure. Clients want speed. Demonstrations that show something working are more compelling than conversations about data models. A pre-built solution is easier to sell than a promise to design the right one. The incentives are coherent. The outcome is predictable.
But the executive approving the project deserves to understand what is actually being offered. Not a faster path to the right solution. A faster path to a solution — one that may or may not reflect how your organization actually works, and that will cost considerably more to correct than it would have cost to design correctly from the start.
The platforms have already solved the speed problem. What remains is the comprehension problem. How quickly can a team genuinely understand your business, your domain, your variation, and your direction — and translate that understanding into a structure worth building on?
That is the work no accelerator can do for you. And it is the only work that determines whether the system you end up with is one you can understand, govern, extend, and own.
There is one genuinely interesting development in this conversation, and it does not come from the accelerator market.
AI is beginning to make the comprehension problem tractable in ways it was not before. Not by configuring faster, or generating more code, or producing more documentation — that path leads to the same place, faster. But by compressing the work of understanding. Helping teams summarize discovery, explore data models, surface assumptions, test structural decisions, and arrive at sound architecture before anything is built.
That is a different kind of acceleration. Not configuration before comprehension. Comprehension before configuration.
It is early. The tools and practices for doing this well are not yet mature. But the direction is right, and it is worth watching — because an accelerator that genuinely helps an organization understand its own domain before committing to a structure would be something the market has not yet produced.
What exists today is not that.
What exists today accelerates the part that was already fast enough and defers the part that determines whether the system is worth building. It front-loads visible progress and back-loads structural risk. It answers the timeline pressure without answering the design question.
Any vehicle with an accelerator and no brakes ends up in an accident.
You will be shown another demonstration. The screens will look familiar. Someone will say seventy percent. The timeline will look reasonable.
The questions worth asking are not about the features in the demonstration. They are about the structure underneath it. What decisions have already been made? What does this model assume about how our business works? Where does it fit our domain, and where does it impose a version of our domain that belongs to someone else? What will it cost to govern, extend, and explain this system in three years?
Those questions will slow the conversation down. That is the point.
The acceleration that matters is not getting to a first milestone faster. It is arriving at a structure your organization can understand, own, and build on — without spending the next several years discovering what you agreed to in the demonstration room.
Ask the questions before the structure is built. After, they become a different kind of conversation entirely.