The Structural Conflict of Interest in Software Engineering Services

When you go looking for help with software, you tend to meet two kinds of advisor, and they sit on opposite sides of the same trap.

The first bills you by the hour. Often very good engineers, often decent people. But notice the interest they will never say out loud: the longer the work takes, the more they earn. They just have no reason to want it solved quickly, and a quiet reason to want it solved slowly. The second lives on your subscription. They sold you a platform and collect a fee for as long as you stay, and the whole model rewards one thing above all others: that you cannot leave. Your data in their shape, your exit priced high enough that you keep paying rather than face it.

Two different halves, one common thread: both make money from the problem, not from the solution. The easy version of this essay is a rant, and a rant is useless to you. The people are mostly fine. The issue is not character, it is incentive.

The economic name for it

There is a precise term for it, and the term keeps the conversation out of moralising: the principal-agent problem. You are the principal, you own the goal and carry the cost. The advisor is the agent, hired to act on your behalf. The problem is old and structural: the agent's incentive and the principal's interest do not point the same way, and where they diverge the incentive wins on average, whatever the agent feels about it. An incentive is a slope. Put a decent person on it and they drift downhill, telling themselves a reasonable story the whole way down. Nobody has to be a villain.

Where the slope leads: lock-in and debt

You can watch the drift end up in the code. On the platform side it is vendor lock-in, not an accident but the intended shape of the product: a platform whose revenue is your continuity has every reason to make leaving expensive, through proprietary formats and integrations that only reach inward. The pricing does the work.

On the build side the same physics shows up as technical debt. I was once brought in to look at a system a company had paid to run for the better part of a decade. Near the root of the repository sat a single file of roughly fifteen thousand lines that did everything: request handling, database access, business rules, a scheduler, all in one class, methods six hundred lines long without a seam you could cut along. That file was not incompetence. It was, in effect, a design. A clear, tested, documented codebase is one a competent client could take in-house or hand to someone cheaper: lost revenue. A fragile, opaque monolith only its authors can touch is an annuity, where every change routes back through them and every quote is unchallengeable. The file is not a mistake, it is the rational output of an incentive that pays for confusion.

What each party actually sells

Here is what is really on the table, stripped to what each business is built to protect.

• The software house sells input: hours, seats, developers. It is paid for effort, whether or not the effort produced anything you needed.
• The platform sells access: a login that keeps working while you keep paying. It is paid for continuity, whether or not you get more value this year than last.
• I sell the fact that it works: the outcome. I am paid when the thing you needed to be true becomes true, and not otherwise.

The part that matters: neither of the first two can copy that attribute without breaking their own machine. A body shop paid only on outcomes would have to stop selling bodies. A platform that made leaving free would watch its recurring revenue evaporate. The outcome is not a slogan they can add next quarter, it is the one promise their business model structurally forbids them to keep. That is not virtue, it is me standing somewhere they cannot follow.

The objection is the proof

Here a sharp reader says the obvious thing. "Hang on. You founded a software company. You are exactly the person you are warning me about."

Yes. And that is the strongest part of the argument, not the weak spot. I built Cocreiamo so that the conflict cannot exist, with the two roles kept apart by design. I advise you as an independent, paid for the outcome, holding no interest in dragging the work out or locking you in. The company is the proof that the outcome is buildable, not the funnel I am steering you into. You do not have to trust my restraint, you can inspect the arrangement.

That is the whole reason to build it this way. If independence were a personality trait you would be right to distrust it, because personalities bend under a big enough check. Independence that is load-bearing has to be built out of structure, so that it holds even when I would be tempted. I do not sell you programmers. I protect you from the people who want to.

So pay for judgement, not for hours: someone free to tell you what is really wrong, what is worth building, and what you should walk away from, including walking away from me. Judgement only counts when it is free to reach any conclusion, and the moment the advisor's income depends on the answer, the answer stops being advice and becomes a sales pitch with better manners. Insist that the independence be built in by design, not offered by promise. The kind that bends under a big enough check was never worth anything.