Let’s start with the part most consultancies leave out.
If you have a functioning in-house OutSystems team, you are already in the better position. Your developers know the domain. They know which integrations are fragile and why. They know that the reason a module is structured the way it is has nothing to do with architecture and everything to do with a decision someone made in 2019 under deadline pressure. That context takes years to build and cannot be bought.
Most of the time, the right answer is to leave your team alone and let them work.
But there are specific conditions where an in-house team, however good, is structurally unable to solve its own problem. Not because of skill. Because of position. Here are the five we see most often, and what to do about each.
1. One person holds the architecture in their head
This is the most common one and the least discussed, because naming it feels like an accusation.
Every mature OutSystems estate has someone who knows how it all fits together. They know the dependency graph, they know which module you must not touch on a Friday, they know why the domain boundaries are drawn where they are. Nobody wrote it down because writing it down was never the priority. Shipping was.
The risk is not that this person is bad at their job. The risk is that they are excellent at it, and the estate has organised itself around that excellence.
You find out how exposed you are on the day they resign. We have watched platform teams lose seven-year developers and discover in the following month that a meaningful share of their architectural reasoning walked out with them. The remaining team can keep the lights on. What they cannot do is make confident structural decisions, because the reasoning behind the existing structure is now unavailable to them. We have written before about what a real platform handover requires, this condition is what it looks like when the handover never happened.
An outside architect is useful here for one narrow reason: they have no choice but to reconstruct the model from the artefacts. Whatever cannot be reconstructed is the gap, and the gap is your actual risk register. That exercise is difficult for insiders because insiders already know the answer and cannot un-know it.
The deliverable to ask for: a written architecture model built from the estate itself, plus an explicit list of what could not be derived without asking a human. The second list is the one that matters.
2. You have more squads than standards
OutSystems scales well technically. It scales badly politically.
Three squads building on one platform will produce three interpretations of what a service module is for. Each interpretation is defensible. Each was reached by competent people solving a real problem. And each one, compounded over two or three years, produces an estate where the same concept is implemented four ways and no one implementation can be called wrong.
Internal governance efforts usually stall here, not for technical reasons but for organisational ones. Asking Squad A to adopt Squad B’s pattern is asking a team to absorb rework on someone else’s authority. It rarely survives contact with a delivery deadline.
An outsider does not fix the politics. What they can do is make the comparison neutral. A pattern audit that comes from outside the org chart is a document, not a territorial claim, and teams argue with it differently.
The deliverable to ask for: a pattern inventory showing where implementations diverge, ranked by the cost of leaving each divergence in place. Not a style guide. Nobody reads style guides.
3. A one-time specialised project with no second occurrence
O11 to ODC is the obvious current example, but the category is broader: a data platform migration, a tenancy model change, a major integration replatform.
These share a shape. They are large, they are specialised, they happen once, and the skill required to do them well has no reuse value afterwards. Your team can absolutely learn it. The question is whether you want them spending six months learning something they will never apply again, while the roadmap that justifies their headcount sits still.
This is not a capability gap. It is an opportunity cost decision, and it should be argued on those terms rather than dressed up as an expertise problem.
The deliverable to ask for: a migration plan with the sequencing decisions made and justified, and enough detail that your team executes it. If the proposal is that the outside party executes the whole thing, ask why. On a migration, the team who runs the estate afterwards should have their hands on it.
4. Nobody in-house can say the uncomfortable thing
Some conclusions are structurally unavailable to employees.
That the integration layer built two years ago was the wrong call. That the roadmap assumes a throughput the current architecture cannot deliver. That a project everyone has publicly committed to should be stopped. These are all sayable in principle and mostly unsayable in practice, because the person who says them has to keep working there afterwards.
This is the most underrated reason to bring someone in, and the one that gets the least honest framing when it happens. The value is not superior insight. Your team probably already knows. The value is that an external party can put it in a document with their name on it and then leave.
The deliverable to ask for: a written assessment with an actual recommendation in it, including the option to do nothing. If the assessment always concludes that more work is needed, you have bought a sales document.
5. You are hiring against a gap you have not defined
An open OutSystems req that has been unfilled for four months is usually not a market problem. It is a specification problem.
The role was written from the shape of the last person who left, not from what the estate now needs. The salary band was set against a different market. The seniority is aimed at a level that does not exist in sufficient supply. Meanwhile the work the req was supposed to cover is being absorbed by the existing team as unplanned load, which is the thing that eventually produces condition one.
Before you spend another quarter recruiting, it is worth having someone define the gap independently of the job description. Sometimes the answer is that the req is correct and the market is genuinely tight. Sometimes the answer is that you need one senior for six months, not one mid-level forever.
The deliverable to ask for: a scoped statement of the work, separated from the question of who employs the person doing it.
What this should not look like
If you do decide to bring someone in, the failure mode is well documented. You raise a request, a supplier sends CVs, you interview two of them, one starts in three weeks, and the outcome depends on which body you drew. The engagement is measured in headcount and duration rather than in anything delivered. Six months later the contract renews because stopping it would be disruptive.
That model exists because it is easy to procure, not because it works.
The alternative is narrower and less comfortable to buy: a defined question, a senior who has run estates at scale, a fixed piece of work, and a document at the end that your team owns. It is a smaller engagement. It is also the one that leaves capability behind instead of taking it away.
Where we sit
Hezico is two senior OutSystems architects. That is a deliberate constraint, and it means we are not the right call for everything on this list. We cannot staff a forty-developer migration programme and we will say so on the first call.
What we do is the assessment work: architecture models, pattern audits, ODC migration planning, and the second-opinion engagements where somebody needs to write down the thing that is difficult to say internally. Our team runs New Zealand’s largest OutSystems platform, powering companies like McDonald’s NZ, across a live estate serving 10,000+ daily users. Most of what is in this post came from operating that estate rather than from reviewing other people’s.
If one of the five conditions above describes where you are, the useful next step is a conversation about which one, not a proposal.