Why we stopped handing projects over

Bluehex started in 2014 as an implementation practice. Someone needed a system put in, a network built, a platform migrated, and we did that work. Some of it was on the largest technology projects in the country. Some of it was for businesses with a handful of staff. The pattern was the same either way: scope it, build it, hand it to whoever was going to run it, and move on.

That last step is where it kept going wrong.

What a handover actually costs

An implementation is a moment of unusual clarity. For a few months, someone understands why every decision was made: why the integration works the way it does, which shortcuts were deliberate, what the thing was actually for. Then the project closes, that understanding leaves, and what remains is a system nobody can explain.

What we watched happen next was consistent enough to stop being bad luck.

• Configuration drifted, because the people maintaining it did not know which settings were load bearing.
• Small changes were made in the safest available way, which is usually the way that adds another exception rather than the way that fits the design.
• The parts that needed ongoing attention, patching, licence review, the integration that quietly fails on a schema change, got attention only after something visible broke.
• Two or three years later the client was told the system was end of life and needed replacing.

None of that is anyone behaving badly. It is what happens when the party who understands a system is not the party who lives with it. But the effect on the client is real money: an investment that should have lasted was written off early, and the replacement started the same cycle again.

Owning the outcome instead of the deliverable

So we changed what we sell. Bluehex now takes on partial and full outsource arrangements, and the point of that is not the recurring revenue. It is that the people who designed the thing are still there in year three when it needs a decision made about it.

That changes the incentives in a way that shows up in the work.

• We do not build something clever that only we can maintain, because we are the ones who will be maintaining it at 4pm on a Friday.
• We do not defer the boring parts, because deferred maintenance lands on us.
• We push back on requests that will cost more later than they save now, because we are still here later.

It also means we can be honest about scope. If the answer is that your existing system should be extended rather than replaced, we say so, because we are not being paid to leave a project behind.

What it means if you are on the other side of it

Practically, three things.

One provider across IT, security and systems. The same practice that hardens your Microsoft tenancy implements your ERP and installs your access control. That is not empire building. It is that the gaps between vendors are where the failures live, and they close when there is one party accountable.

You can start small. A partial outsource is a normal arrangement, and plenty of engagements begin as a single piece of work: one process that will not scale, one fleet nobody owns, one security questionnaire that cannot be answered. If it makes sense to do more afterwards, we do more.

The investment is supposed to last. That is the whole argument. Not a cheaper implementation, a longer useful life for the one you pay for.

If any of that reads like your last three years of technology spend, that is the conversation to have.