Nobody can say what is wrong
It is slower and more expensive than it was, and every explanation on offer is a hypothesis nobody has measured.
TECHNOLOGY CONSULTING
Work out what is wrong.
Then fix the right thing.
We are a technology consultancy. Most engagements start by establishing what is actually causing the problem — which is often not what it was assumed to be — and end with your team able to run what we built without us.
Four questions, two minutes, no email address. You get a written starting point either way.
WHY TEAMS CALL US
The hard part is rarely the building. It is knowing which thing to build.
Most engagements start in one of three places, and none of them is a failure of the team that got there.
The team is at capacity
You know roughly what needs doing. There is nobody free to do it, and hiring for it would take two quarters.
The stakes make it hard to start
The system cannot go down, the data is regulated, or the deadline is external — so the safe move keeps being to wait.
HOW WE WORK
Measure first. Scope small. Hand it back.
None of this is novel, and that is rather the point: the projects that go wrong usually skipped the first step and found out the cost in month four.
- 01Measure what is actually happening before anyone proposes a plan.
- 02Scope the smallest change that solves the real problem.
- 03Build it in slices that each work, and that each roll back.
- 04Work in your repo, with your engineers, not in a room next door.
- 05Hand it over so your team can take the next change alone.
FOUR STARTING POINTS
Where engagements usually begin.
Pick whichever is closest. They overlap more than they look — a cost problem and a reliability problem are frequently the same problem.
START 01 / DIAGNOSE
Something is wrong
The system is slow, expensive or fragile, and nobody can tell you why.
Before anyone proposes a rebuild, it is worth knowing what is actually causing the pain. Usually it is two or three things, and usually they are not the ones being blamed.
- Architecture and infrastructure review
- Where the money and the latency actually go
- Failure patterns and what keeps causing them
- A ranked list of fixes with effort against impact
START 02 / BUILD
Build something new
You need software that does not exist yet, and no team free to build it.
Getting a first version in front of real users quickly, built so the second version does not mean starting again.
- Scoping down to a version worth shipping
- Architecture decisions you can live with
- Delivery alongside your own engineers
- Handover that does not depend on us staying
START 03 / CLARIFY
Make sense of the data
Two reports disagree, and the argument about which is right keeps winning.
Getting to numbers people stop arguing about, then deciding whether anything more sophisticated is actually worth building.
- Where your numbers come from and why they differ
- A warehouse and modelling layer that fits your size
- Metrics defined once, used everywhere
- An honest read on which AI ideas are worth it
START 04 / PROVE
Pass the audit
A customer, an investor or a regulator wants evidence, and soon.
Closing the gap between how you actually operate and what an auditor needs to see, without turning the company into a paperwork exercise.
- Gap assessment against the standard you need
- Fixing the findings that matter first
- Controls that fit how your team already works
- Evidence collection that keeps running after we go
A USEFUL FIRST MOVE
Something you could do this week, without hiring anybody.
Pick the statement closest to your situation. The suggestion is what we would tell you on a first call.
SUGGESTED NEXT STEP
Start by measuring, not rebuilding
Turn on cost attribution and tracing and give it a week. The cause is usually two or three specific things, and they are usually not the ones being blamed in the meeting.
An orientation tool, not an assessment. It applies a short set of fixed rules to what you selected — nothing more.
THE ENGAGEMENT
Assess, scope, deliver, hand over.
Four stages. The first is short and paid, and it ends in a document you own whether or not you go further.
- 01
Assess
A short, paid piece of work that establishes what is actually happening, before anybody commits to a plan.
- 02
Scope
The smallest change that solves the real problem, written down with what it costs and what it does not include.
- 03
Deliver
Built in increments you can see, alongside your engineers rather than in a room they have no access to.
- 04
Hand over
Documentation, a walkthrough, and a team that can run it without us. We would rather be re-hired than depended on.
ENGAGEMENT CANVAS
What a plan looks like once it has been broken down.
An illustrative engagement, chosen because it is common. Each step is reversible on its own, which is what keeps a bad week from becoming a bad quarter.
ILLUSTRATIVE SCENARIO
Getting a nine-year-old monolith onto managed infrastructure
An illustrative engagement, not a client case study. Real ones diverge by the second week.
- 1
Find out what the system actually does
COVEREDIncluding the three cron jobs nobody has owned since the person who wrote them left.
- 2
Measure where cost and latency really go
COVEREDIt is rarely the part everyone complains about. Usually it is one query and one oversized instance.
- 3
Decide what moves, what gets rewritten, what dies
YOU ARE HEREMost of it moves as-is. Rewriting during a migration is how migrations fail.
- 4
Move the least risky service first
Proves the pipeline, the monitoring and the rollback while the stakes are still low.
- EITHERLift and shift first, optimise after
- EITHERRe-platform the service while it moves
- 5
Migrate the rest in slices
Each slice reversible on its own, so a bad week never becomes a bad quarter.
- 6
Hand over the runbook and the on-call
The engagement ends when your team can do the next one without us.
WHAT SHAPES THE WORK
The right answer depends on things a reference architecture cannot know.
These go into the plan at the start rather than being discovered in week six, where they stop being inputs and become overruns.
The stack you already have
We work with what is there. Recommending a rewrite to something we prefer is not advice, it is a preference.
What has to keep running
Most of this work happens on systems that cannot go down. That constrains the plan more than any technical choice.
Who is on your team
The right architecture for ten engineers is the wrong one for two. Capacity is a design input, not a detail.
Budget and deadline
Both are real. A plan that only works if neither moves is not a plan worth having.
Compliance and risk
Regulated data, audit deadlines and contractual obligations change what is possible, so they go in at the start.
What happens after we leave
Everything is built to be operated by your team. If it needs us to keep running, we built it wrong.
ENGAGEMENT MODELS
Different shapes, depending on what you need.
Most clients start with an assessment and then pick one of the others. Some only ever want the assessment, which is a legitimate outcome.
Start with an assessment
Clear Pathways publishes no client names, logos, case studies or results. Where relevant experience exists, ask and you will get a straight answer directly.
- Assessment
- Two to four weeks, fixed price, ending in a written findings document you own whether or not you hire us again.
- Project delivery
- A defined piece of work with a scope, a price and an end date, delivered in increments you can see.
- Embedded engineers
- Our people inside your team, in your standups and your repo, for a fixed period.
- Fractional architecture
- A few days a month of senior technical judgement for teams too small to justify hiring it.
- Audit readiness
- Gap assessment through to evidence collection, aimed at a specific standard and a specific date.
- Handover and training
- Documentation, pairing and walkthroughs so the thing we built stops being ours.
WRITING
What we think, before you have to pay to find out.
Practical pieces on the decisions that tend to go wrong, including the ones where our advice is to do less.
CLOUD AND INFRASTRUCTURE
Cloud migration without a big bang
The cutover weekend is the most dangerous way to migrate. Slices are slower on paper and faster in practice.
SOFTWARE DELIVERY
When to rewrite, and when not to
Rewrites are chosen for how the code feels to work in, and justified afterwards with business reasons.
DATA AND AI
What data platform do you actually need?
Most teams buy a platform sized for a company ten times larger, then struggle to staff it.
DATA AND AI
AI features that survive contact with users
The demo is the easy part. Everything that makes an AI feature usable happens around the model.
QUESTIONS
The things people ask on a first call.
Including what we will not promise. The full list covers more.
What does Clear Pathways actually do?
Technology consulting across four areas: cloud and infrastructure, data and AI, custom software, and security and compliance. In practice most engagements start with working out what is really causing the problem, because that is frequently not what it was assumed to be.
How does an engagement usually start?
With a short, paid assessment — typically two to four weeks — ending in a written document covering what we found and what we would do about it. You own that document whether or not you hire us for the work it recommends.
Do you work with small companies or only large ones?
Both. The work differs more than the size suggests: smaller teams usually need judgement and capacity, larger ones usually need someone without a stake in the existing internal argument.
Will you tell us not to do something?
Regularly. A good share of assessments conclude that the proposed project is not the right one, or that the problem is a configuration change rather than a quarter of engineering. That is a more useful outcome than a confirmed scope.
Who owns the code and the documents?
You do, from the first commit, in your repository and your accounts. Nothing we build lives somewhere you cannot reach, and nothing requires us to keep it running.
What happens when the engagement ends?
Handover is part of the scope rather than a courtesy at the end: documentation, a walkthrough, and your team making changes unaided before we leave. We would rather be re-hired for the next thing than depended on for this one.
You do not have to figure it all out today.
Start with where you are. Explore what is possible. Choose one step you can take next.