You're hiring an AI automation engineer.
Good. You should.
The question is what they build in the first ninety days, and whether it still works a year from now.
Most people in our position would tell you not to hire, and to use them instead. We won't. If automation matters to your business, you need someone inside who owns it. That is the right call.
It rarely breaks on launch day.
MIT studied enterprise AI projects in 2025 and found that around 95% of the pilots looked at never showed a measurable return. The cause was not the models. It was integration.
From "The GenAI Divide: State of AI in Business 2025", by the NANDA group at MIT. Worth reading yourself.
The thing got built, it worked in the demo, and it never became part of how the business actually runs. That is the part people underestimate. The build is the easy half.
Nobody owns it after launch
The person who built it moves on. Your team is left working out how it runs, where the credentials live and how to fix it. The workflow sits broken because it was never anybody's job.
Nobody agreed what working means
Without a number set before the build, there is no way to tell whether it saved time, reduced errors or changed anything. So it gets judged on feelings.
It fails quietly
A step stops returning data and nothing tells anyone. The system keeps running, and the first person to notice is a customer three weeks later.
A broken process got automated
Unnecessary steps, unclear ownership, messy data. Automating that does not fix it. It makes the same mistakes faster and makes them harder to see.
The running costs were never budgeted
Model usage, API calls, hosting and somebody's time every month. None of this is a surprise if you plan for it. All of it hurts if you don't.
None of this is about whether the engineer is good. It is about what gets decided before anyone starts building.
Seven things we settle before anyone builds anything.
This is the part that gets skipped. It isn't difficult work and it isn't expensive. It just has to happen first, because every one of these is painful to change once a system is live.
Where the data lives
What the system needs, where it comes from, what leaves your network and who is allowed to see it.
What happens when a step fails
Retry, stop, send it to a person or hold it for review. Decided on purpose, not left to chance.
Who owns it after launch
A named person, not a team in general. Responsible for updates, credentials and documentation.
Where a human has to approve
The decisions the system is never allowed to make on its own, and who handles the exceptions.
How you find out it broke
Logs, alerts and checks that reach the right person. A system nobody is watching is a system nobody is running.
What success is, in numbers
Measured before we start and again when we're done, so the result is a fact and not an opinion.
What happens when tools change
Models get retired and APIs change. The system should survive that without a rebuild.
Any engineer worth hiring can build the workflow. The difference shows up in month eight.
Systems that have been running for months, not demos.
Order data moves itself, and payments confirm without chasing.
Five tools connected into one workflow before every prospect call.
An AI pipeline reads job listings and structures them before the platform sees them.
Client names are kept private. We will talk through any of these properly on a call, including the parts that broke and what we changed.
We are not trying to replace the role.
Start before your hire arrives.
Posting the role, shortlisting, interviews, notice period and ramp up. That is months before anything gets built. We do the first piece of work now, so the person you hire walks into something running instead of a blank page.
Best for: teams that have approved the hire and want the waiting time to count.
Work alongside whoever you hire.
We set the foundation and build the first system with them. They stay involved throughout. We document what we build, explain the decisions behind it and hand over properly when they are ready.
Best for: teams that want a second pair of eyes on the foundation, or help with one hard integration.
In both cases the goal is the same. Your engineer succeeds, and you are not dependent on us.
The boring part that protects you.
A named point of contact
One person on your side who can answer questions and get us what we need. Without this, projects stall for weeks and nobody can say why.
A daily report
What we did, what we are doing next, and anything that is blocked. You should never have to ask how it is going.
A signed data protection agreement
What we can access, what we do with it, how long we keep it and when it gets deleted. Signed before we touch anything.
Send us the job description.
Not a sales call. Send us what you are hiring for, and we will spend forty five minutes going through it with you.
What we'd build first
Where the biggest opportunity is, based on the role and the work behind it.
What we'd leave alone
What can wait, what needs a better process first, and where building now would be early.
The first ninety days
Priorities, early milestones and how to measure whether it is working.
What to ask candidates
Questions on failure handling, monitoring, ownership, security and business results.
It is yours to keep. Use it to hire better, use it to brief whoever you hire, or use it without us. If we are a fit, we will both know on the call.
A few things you may be wondering.
Shouldn't we just hire instead of using you?
Probably yes, eventually. Someone inside who owns this is the right end state, and a permanent engineer will understand your business in a way we won't. The question is what happens in the months before they arrive, and whether they inherit a foundation or a mess. That is the part we help with. You may need us before your hire starts, alongside them for one project, or not at all.
We already started and it isn't working. Can you look at it?
Yes, and this is a lot of what we do. We go through what was built, work out where the problem is coming from, and tell you what is worth keeping and what should be rebuilt. We will say so plainly if the honest answer is that it should be scrapped. First we need to understand what it was supposed to do, what is happening instead, and what access and documentation exist.
Where are you based?
Nigeria. We work with clients in Nigeria, the United States and the UK, including the manufacturing and private equity systems above. Everything runs on a daily report and a named point of contact, so time zones have never been the problem people expect.
How do you price it?
On the outcome, not hours. We agree what should change, measure it before and after, and price around that. A focused review is different from preparing the ground for a new hire or working alongside your engineer for months. Once we understand the scope you will know the number before anything starts.
Will you use AI for everything?
No. If a set of clear rules handles the work reliably, adding an AI model only adds cost and more ways for it to fail. AI earns its place when the work involves language, documents, judgement or anything unstructured. Some of what you are hiring for does not need it at all, and we will tell you which parts are which before you spend money on the wrong one.