Home/ Solutions/ IT strategy and process optimisation

Grow

Decide build, buy or run one workflow at a time.

IT strategy and process optimisation for companies whose systems grew one purchase at a time. We map how the work actually flows, then decide build, buy or run for each workflow rather than for the whole company.

What this covers

Decide build, buy or run one workflow at a time, end to end.

Process mapping with the people doing it

We record how a workflow actually runs: every step, handoff, approval and wait, including the spreadsheet nobody mentions and the person everything routes through. You cannot decide build or buy from an org chart.

Systems and licence audit

A list of every system you pay for, who really uses it, where two tools do the same job, and what each one costs you a year. Overlapping licences are usually the fastest money on the table.

Build, buy or run, workflow by workflow

Each workflow gets a verdict and the reasoning behind it. Buy where a product already fits without bending your process. Build where the work is specific to how you compete. Leave alone whatever is quietly working.

Integration and data flow design

Where data enters, where it gets retyped, and where two systems disagree about the same number. Most of what gets called a bad system is really data crossing a gap by hand every week.

Automation and AI where it earns its place

We put AI agents and copilots into production with guardrails, monitoring and a rollback path, and only on workflows where the volume and the rules justify it. A demo is not the same thing as a system that runs on Monday.

Roadmap, sequencing and costing

The order matters as much as the list. Dependencies land first, each phase carries its own price, and you can stop after any phase and still be left with something that works on its own.

How it runs

Plan. Build. Run.

01

A 30 minute call

You describe what is slow, expensive or fragile, and who it hurts. We say whether this is a fit and what the work would take. No slides, no charge for the call, and you leave knowing what the next step costs.

02

Map how the work actually flows

We sit with the people doing the job and write down the real steps: the handoffs, the waiting, the rekeying, the spreadsheet that quietly holds it together. Every core workflow gets recorded as it is, not as the handbook says.

03

Decide and cost each workflow

Workflow by workflow we mark it build, buy or run, with the alternatives and the reasoning written next to it. Every option carries an effort and a price, so you are comparing numbers instead of opinions.

04

Build it, then run it

You approve one phase at a time and we build to a fixed scope, timeline and price. When it is live it either moves onto the managed run retainer or is handed over documented to your team. You pick which before we start.

Why infoloop

We do not hand over and leave.

  • We can build what we recommendThe people writing the recommendation are the people who would implement it. That keeps the plan honest about effort, because nobody here is proposing work they will never have to do themselves.
  • Buy is a real option hereWe have three systems already built: garage management, attendance, and LMS and testing. Where one of them fits your workflow, configuring it beats building from scratch, and we will say so rather than quote the build.
  • We stay after it goes liveMost of what we build moves onto a managed retainer: monitoring, fixes with agreed response targets, security updates, improvements and a monthly report. The alternative is an agency that hands over and leaves.
  • Per workflow, not per companyOne verdict for a whole company is wrong somewhere. Deciding per workflow means you are not rebuilding the things that work in order to fix the two things that do not.
  • Fixed scope, timeline and priceYou get a number before the work starts, phase by phase. Open-ended day rates are how an optimisation project turns into the thing it was meant to fix.

What you get

Every engagement includes these, in writing, before work starts.

  • A current-state map of every core workflow, with handoffs, waiting time and manual steps marked
  • An inventory of systems and licences, with annual cost and actual usage against each one
  • A build, buy or run verdict per workflow, with the alternatives and the reasoning written down
  • An integration diagram showing where data enters, where it is retyped and where it disagrees
  • A sequenced roadmap with effort, dependencies and a fixed price for each phase
  • A risk list covering single points of failure, unsupported software and key-person dependencies

Who this is for

Three situations where this is the right call.

Systems added one at a time over ten years

Nothing was a mistake on the day it was bought. Together they now take three people to keep in step, and nobody can say which tool owns which number. You want the sprawl mapped before you spend anything else on it.

A platform replacement quote is on the table

Someone has proposed replacing most of what you run, the number is large, and you have no way to test whether that is even the right shape of answer. You want the decision broken down per workflow before you sign anything.

Headcount is going into admin, not output

Your team spends its days rekeying, chasing approvals and rebuilding the same report every month. Hiring another person would work, and it would also be the most expensive way available to fix it.

Proof

Software we built, and still run.

Questions

What buyers ask us first.

What does it cost, and how does an engagement run?
Every engagement starts with a 30 minute call. From that we scope the work and come back with a fixed scope, timeline and price, so you are not signing an open-ended day rate. The optimisation work itself is priced as one fixed piece: the mapping, the decisions and a costed roadmap. Anything we then build is quoted separately and phase by phase, so you can approve one workflow at a time. If you move onto the managed run retainer afterwards, that is a monthly fee sized to what we keep live.
Do we have to replace our existing systems?
No, and usually you should not. Replacement is the most expensive answer and the one most often chosen by default. For each workflow we look at whether the system is genuinely failing, or whether the pain is a missing integration, a manual step nobody owns, or a report someone rebuilds by hand every month. If the tool works and the process around it does not, we fix the process. We only recommend replacing something when the cost of keeping it is clearly higher than the cost of moving off it.
How do you decide build, buy or run for a given workflow?
Three questions per workflow. Is this how you compete, or is it plumbing that every company does much the same way? Does something off the shelf already fit without bending your process out of shape? And who keeps it working in two years time? Plumbing a product already handles should be bought. Work specific to how you win, or that no product fits without heavy compromise, is worth building. Anything already working and low risk should be left alone and simply run properly. The reasoning is written down so you can challenge it.
Is there a conflict of interest if you also build what you recommend?
It is a fair question, so we answer it in the open. Every decision is written down with the alternatives we considered and what doing nothing would cost you. That document is yours: you can hand it to your own team or to another supplier, and it is written to be usable without us in the room. In practice the cheapest recommendation is often to keep what you already have and fix the process around it. We would rather say that than sell a rebuild that quietly fails in its second year.
What happens after something goes live?
This is the part most engagements skip. Anything we build can move onto our managed run retainer: monitoring, fixes with agreed response targets, security updates, small improvements and a monthly report showing what changed and what it cost. You are not left with a system nobody owns the moment the project closes. If you would rather run it in house, we document it, hand over the code and the access, and walk your team through it. Either way that choice is made before we start, not after.
Who on our side needs to be involved, and how much of their time?
Two kinds of people. Someone senior enough to say yes to a change in how work gets done, usually an owner, an operations director or a finance lead. And the people who actually do the work each day, because the real process is never the one written in the handbook. We do the mapping in short sessions rather than long workshops, so a few hours from each person spread across the engagement is normally enough. We come to them, we take the notes, and we write up the map so nobody on your side has to produce documentation.

Bring us the workflow that costs you most. We will tell you build, buy or run.

Thirty minutes on a call is enough to know whether this is a fit. You will leave it with a view on your worst workflow and a clear sense of scope, timeline and price. Nothing to prepare beforehand.

Book a call Checklist