The test that decides who owns your systems

An uncomfortable test for anyone who buys software development: if your vendor disappeared tomorrow — how long before anyone else could take over your systems?

Ask the question at your next management meeting. If the answer is "a couple of weeks," you can stop reading here. If the answer is "months" — or if nobody in the room really knows — you're in good company.

Because the reason is rarely what you'd think. It's almost never that the code is complicated. It's that the knowledge of how everything fits together — why things were built the way they were, what you must never touch, which shortcuts were taken and where they're buried — lives with the vendor. Not with you.

No villain in this story

It's easy to read that as an accusation against the vendor. It isn't.

Knowledge accumulates with the people who do the work. Every change request, every 2 a.m. debugging session, every "why is it built this way?" builds understanding in the consultant doing the job. That's how all skilled work works. Nobody did anything wrong.

Contracts try to compensate, of course: documentation requirements, handover plans, exit clauses. But anyone who has been close to one of these deliveries knows how it goes. The documentation gets written after the fact, often by someone other than the person who made the decisions, and starts aging the day it's saved. When you finally need it, it's reassurance on paper — not in practice.

The price shows up at exactly one moment: renewal. That's when many companies discover they aren't really negotiating. They're re-signing. The alternative — moving an engagement that only the current vendor understands — feels too expensive and too risky to even price. So the contract renews. Again.

It's not a pricing problem. It's a memory problem.

What a knowledge graph actually contains

The solution isn't more documentation. It's a different kind of memory.

A knowledge graph is not a document archive. It captures what documents rarely do: decisions and the reasoning behind them. Trade-offs, and the alternatives that were rejected. Which systems connect to which, and why. Lessons — "we tried this two years ago, it didn't work, here's why."

The difference from classic documentation comes down to two things. First, it's built while the work happens, not after the fact — so it describes what was actually done, not what someone happens to remember in an interview months later. Second, it's connected: from a single change you can follow the thread back to the decision behind it, the systems it touched, and the lesson it left behind.

That is exactly the knowledge that makes your vendor "know" your systems today. And it's the knowledge that can be brought home.

How it works — without changing anything

What has become possible in recent years is separating the memory of the work from the work itself. The mechanics are simpler than they sound:

1. Notice where the knowledge lands today. Every change request, every decision, every hard-won lesson about your systems — does any of it land in an environment you own? Or does it all live with the people you rent? For most companies, the honest answer is the latter.

2. Connect read-only. A read-only connection to your environments: boards, code, documentation, monitoring. Nothing in the delivery changes — your vendor works exactly as before, with the same tools and the same processes. But from that day, a knowledge graph builds in your environment, in your ownership.

3. Do nothing. For months. The contract runs. The graph grows with every ticket, decision and release. The gap between "what the vendor knows" and "what you own" shrinks every week — no project, no workshops, nobody being interviewed about things they did three years ago.

4. Walk into the next renewal as a different customer. Not because you're threatening to leave — but because staying, switching and taking it in-house are real options for the first time. And priced accordingly.

Three outcomes — and all three are better

Renewal is where the value becomes concrete. Three paths are open:

Stay. The most common outcome — and the most underrated. A vendor relationship is healthiest when both sides know the customer could leave: prices become reasonable, conversations more honest, the priorities yours. And the graph makes daily life better for the vendor too — new consultants get up to speed on your systems in days instead of months, because the entire history is there to ask.

Switch. A handover that would otherwise take months takes weeks. The next vendor doesn't start from zero — they start with every decision, connection and lesson since day one.

Take it in-house. Long unrealistic for companies without their own development organization. That has changed. AI agents can now do the work itself — planning, code, review, testing, releases — with your knowledge graph as the memory and a small number of people setting direction and providing the judgment. That's how we at Wizardworks run our own deliveries today, at Nordic companies in production. The same model can run on your engagements.

The point isn't that you should leave anyone. The point is that the choice should be yours.

Start small

This doesn't start with a transformation program or a feasibility study. It starts with a connection that changes nothing — and that, every week, makes you a little more the owner of what you've already paid to learn.

Want to see what it would look like on one of your systems? We're happy to show you — or start even simpler, with a single delivery, so the difference is there in black and white.

Book a delivery →