Cheap development, expensive maintenance
You ask three companies to quote the same software. Two come back with similar numbers. The third is quite a bit lower, and nobody explains why. The easy reading is that the other two are padding their margins. Sometimes that is true. But there is a more common explanation: the cheap quote is not competing on the development. It is buying what comes after.
Before going on, one clarification that matters: this is not about scams or bad professionals. It is a business model, legal and very widespread, and some vendors who follow it deliver software that works. We know it from the uncomfortable side: at Vettra we have been the client of a development contracted this way. This article is that experience turned into criteria: what to look for in a proposal to know which model you are dealing with.
Where the difference is recovered
The initial development is priced tight, sometimes below what it really costs. The difference is recovered later, through three channels that have one thing in common: they are all recurring.
The maintenance fee. Mandatory from the day of delivery, whether you need it that month or not. It does not cover new features or improvements: it covers keeping the software switched on. In the proposal it shows up as a small line next to the project price; multiplied by the years the software will be in use, it stops being small.
Hosting with a markup. The vendor rents the servers and resells them to you inside the fee. You never see the real infrastructure bill, so you cannot tell which part is cost and which part is margin. And since it is contracted in their name, you cannot take it anywhere else either.
Every change, billed separately. The fixed price covers exactly what was signed. But software is alive: the business changes, a regulation changes, a need appears that nobody foresaw. Each change is quoted separately, at whatever rate applies that day. And that rate no longer competes with anyone, because switching vendors has stopped being a real option. We will see why in a moment.
The two conditions that hold it up
This model only works if two conditions are met. Both are usually in the contract. Or, more precisely, in what the contract does not say.
The code does not belong to the client. The repository is in the vendor's name and the client has no access. You pay to use the software, not to own it. Many contracts do not even mention who owns the code; others hand it over "at the end of the service", an end the model itself makes sure never arrives.
The infrastructure is in the vendor's name. Domain, servers, database, backups. All of it contracted by them, in their accounts. The client has a login to get into their application; the vendor has everything else.
Neither condition is hidden. They are simply not mentioned, and almost nobody asks about them. Asking costs nothing and is, by far, the most profitable thing you can do before signing.
Why it is so hard to leave
With the code and the infrastructure in the vendor's hands, switching is not switching: it is starting from scratch. A new team with no access to the code cannot pick up anyone's work. It can look at the application from the outside and rebuild it, which means paying for the project a second time. Meanwhile, your data, your domain and your email live in accounts you do not control, and getting them handed over has to be negotiated with the vendor you have just left. That is why the repository, the cloud, the domain and the admin access need to be in your name, and why the contract has to say so in writing. We go through what that means in who owns your software code.
That closes the circle. The maintenance fee is no longer compared with other fees on the market: it is compared with the cost of rebuilding everything. Against that alternative, any figure looks reasonable. The business is not in overcharging for each thing; it is in making sure leaving always costs more than staying. If what you are evaluating is a custom ERP, this filter matters even more: the system that would end up trapped is not a website, it is the tool that runs your daily operations.
How we do it
We tell you not to show off, but because it proves the opposite model exists and works. Four decisions, made precisely because we have been on the other side:
The code and the repository are in your name from day one. Not at the end: from the first delivery. If tomorrow you want to carry on with another team, you give them access and they pick up where we left off.
The cloud subscription is in your name. You pay for usage directly to the infrastructure provider, with no markup and without going through us. You see the same bill we see, down to the last cent.
Maintenance during the warranty costs nothing. For six months after each delivery, fixing whatever fails is on us. No fee.
After that, maintenance is optional, with no lock-in. If you want it, you hire it. If you build your own team or prefer another vendor, you leave with everything. Because everything was yours from the start.
This only holds up one way: charging for development what development costs. That is why our rate is published on our pricing page and we do not need to recover anything through the back door.
What to ask any proposal
You do not need to be technical to spot the model. Four questions, asked before signing, are enough: who owns the code and the repository, and since when? Whose name is the infrastructure in, and who sees the cloud bill? What happens if I want to leave next month: what exactly do I leave with? How much does maintenance cost, what does it include and is it mandatory?
The answers need no interpretation. Where there is hedging, handovers "at the end" or fees that cannot be broken down, you know which model you are looking at. You can still sign it, and it is a legitimate decision if the upfront price is what your cash flow allows today: but you sign knowing what you are buying. If you want these four answers applied to your project, tell us about it: ours are always the same, and they come in writing.