Technology advisory from the team that builds the platforms
Engineering AI audits and CMS modernisation assessments for product and engineering leaders. We advise because we build.
AI is already part of how your team works
But few leaders have a clear view of where it sits or what it’s costing them. That gap widens as delivery speeds up. And it tends to surface at the worst time, usually as a security or platform problem rather than an AI one.
We help you see it clearly and act on it, with the judgement of a team that has spent over 15 years building and running the platforms underneath it. We advise because we build.
Signs you’re deciding on incomplete information
These conversations usually start when a leader can feel a problem clearly but cannot yet name its cause.
AI is in daily use and nobody can describe how
Your team is using AI day to day, but no one can give you a straight answer on which tools, for what, or how safely.
The picture you would need to brief your leadership or board does not exist, and it gets harder to assemble the longer it is left.
The policy exists and the practice is invisible
You have an AI policy.
What you do not have is real visibility into whether anyone follows it, which means you are carrying the risk without being able to describe it. The first time that gets tested is usually the first time you find out.
You can’t tell whether it’s a tune-up or a bigger move
Your platform is starting to feel like the thing slowing you down, but the diagnosis is unclear.
Optimising what you have, replatforming and staying put all look defensible from the inside, and committing to the wrong one is expensive in both directions.
The problem is outside your team’s range
Your team is good at what it does, and this isn’t that.
Something has come up that needs depth nobody in house has at this scale, and your incumbent partner hasn’t done it before either.
You don’t need to replace anyone. You need one specific problem understood properly by someone who has seen it before.
The engagements we run
Strategic Advisory is where we help you work out what to do before you commit to building it.
Each engagement is fixed scope and ends with a recommendation you own, whether or not acting on it involves more work from us.
Engineering AI Audit
A clear, evidence-based view of how AI is genuinely being used across your team, what that exposes, and what to deal with first.
We look at how your engineers, product people and content teams actually work with AI day to day, rather than what the policy says, then map it against the risks that matter to the business: security, IP, and what happens when AI-assisted code reaches production.
You finish with a picture you can take to your own leadership or board, and a short list of what to fix first. No new tooling, and nothing your team has to implement before we can start.
CMS Modernisation Assessment
An honest assessment of whether your platform is fit for where you are heading, with every realistic option on the table.
Sometimes the right answer is a migration. Other times it is targeted work on what you already have, or staying put and spending the budget elsewhere. We tell you which, and why, with the reasoning shown so your team can argue with it rather than take it on faith.
This is the same diagnostic we run before a build, available on its own, which means the recommendation is not shaped by wanting the build that follows.
How we do it
Advisory uses the first two stages of the same framework we run every build through, compressed into weeks rather than months. It stops at the point where you have a recommendation. What you do with it, and who does it, is your call.
1. Diagnose
Look at how things actually work
We start with how your team actually operates rather than how the policy or the architecture diagram says it does.
Depending on the engagement that means interviews with engineers, product people and content teams, reviewing the codebase and platform, and looking at what reaches production and how.
We are looking for evidence rather than confirmation of what you already suspect.
Includes
- Stakeholder interviews
- Codebase and platform review
- Tooling and workflow audit
- Risk mapping
What we need from you
Time with the people doing the work, not only the people managing it. Usually four to six conversations.
2. Design
Set out the options, and show the reasoning
You get a clear written recommendation with the reasoning behind it, in a form you can take to your own leadership or board.
That means the findings, what they mean for the business, the realistic options with their trade-offs stated, and a prioritised view of what to do first.
The reasoning is shown so your team can argue with it rather than take it on faith.
Includes
- Written recommendation and reasoning
- Realistic options with trade-offs
- Prioritised actions
- Indicative cost and effort per option
- Presentation to your leadership where useful
What we need from you
One session to walk through the draft before it is final, so the recommendation lands in language your organisation actually uses.
3. Build and Evolve
Only if you decide it is worth doing
The engagement ends at the recommendation.
Sometimes the right answer involves more work from us, and Build and Evolve are where that would run.
Other times it points you somewhere else, or tells you to do nothing for now. Where the work surfaces bigger questions about how product and engineering decide and ship together, we will tell you if that is the right next step.
What we need from you
Nothing. There is no obligation to act on the recommendation, and no follow-on engagement built into the scope.
Why The Code Company
Enterprise WordPress only
We do not split focus across ten platforms. Everything we do is enterprise WordPress, and we are the only WordPress VIP Premier Agency Partner with a majority-Australian team. That depth shows up when the work gets technically complicated, which is usually the point where generalist agencies start to buckle.
Senior engineers, start to finish
The engineers who scope your work are the ones who do it. No juniors learning on your time, no handover to a delivery team you have never met, and no account manager relaying technical questions in both directions. You talk to the people making the decisions.
You own what we build
We write clean, documented code with minimal dependencies, so your own developers can maintain and extend the platform without calling us every time something changes. Clients who stay with us do so because they choose to, not because the codebase forces them to.
Work out what to do before you commit to building it
Both engagements are fixed scope and fixed fee, quoted before you commit, and end with a recommendation you own.
Frequently asked questions
We build and run the platforms we advise on, so the recommendation comes from people who’ve done the work rather than modelled it. A large consultancy can tell you what good looks like in theory. We can tell you what will actually happen when it hits your codebase, your team and your deadlines, because we’ve been on the other side of that handover ourselves. The advice is shaped by delivery rather than separated from it.
A clear written recommendation with the reasoning behind it, in a form you can take to your own leadership or board. That means the findings, what they mean for the business, the realistic options with their trade-offs and indicative costs, and a prioritised view of what to do first. The reasoning is shown so your team can argue with it rather than take it on faith. It’s built to be used and shared, not filed away.
They answer different questions. A Technical Audit assesses a platform you’re keeping, and tells you what’s wrong with it and what fixing it involves. A CMS Modernisation Assessment asks whether it’s the right platform at all, and puts every realistic option on the table with the trade-offs and indicative costs of each, including staying where you are. If you already know you’re keeping the platform, start with the audit. If that’s the actual question, start here.
No. Each engagement is a fixed-scope piece of work that ends with a recommendation you own and can act on however you choose. Sometimes the right answer involves more work from us. Other times it points you somewhere else, or tells you to do nothing for now. There’s no follow-on engagement built into the scope, and the recommendation stands on its own either way.
Most run a few weeks rather than a few months, because the work is focused on a specific question rather than open-ended. The timeline is set during scoping, before you commit, so you know the shape of the engagement up front. What determines it is usually how many teams we need to talk to rather than the size of the platform.
Both engagements are fixed scope and fixed fee, quoted before you commit, because the value of an honest assessment disappears if the meter is running. The fee depends on the size of the organisation and how many teams we need to talk to, which is what determines the work. We’ll tell you at the scoping stage if we think the engagement won’t tell you enough to justify it, which happens more often than you might expect.
If AI is already part of how your team works, or your platform is starting to feel like it’s holding you back, you’re not too early. These engagements are most useful when you can feel a problem but haven’t yet pinned down its real cause or what to do about it. If you already know exactly what you need built, a build or migration engagement is likely the better starting point.
Both, and they’re separate decisions. An advisory engagement ends with a recommendation you own. If acting on it is work we’re suited to, we can scope that as a build, migration or support engagement, and we’ll say so plainly. If it isn’t, we’ll tell you what to look for in whoever does it. The recommendation doesn’t assume we’re the ones delivering it.
Insights
Building software is cheap now. Owning it isn’t.
AI collapsed the cost of writing code, not the cost of carrying it. The real build vs buy decision is which layers you can afford to own.