Algeria AgencySoftware development
After version one: what evolving custom software really costs
Custom software is not delivered, it is put into service. Everything that matters afterwards turns on how you ask for a change.
The visible part of a software project is its construction: a quotation, weeks of work, a go-live. The part that lasts is what follows, and it has a different currency. You are no longer buying software, you are buying changes, one at a time, for years.
That is where relationships break, and almost never for technical reasons. A quotation at five times the expected price. A correction invoiced that the client believed was covered. A modification that breaks something else. An invisible queue where everybody assumes their request is next.
This article describes that period. It is written for the owner already using a tool built for them and wondering why changing it costs what it costs. The companion article covers choosing and building — the specification, fixed price against time and materials, the data migration — and none of it is repeated here.
It quotes no figure, and the first section explains why: the natural question, what does a change cost, has no answer comparable between one quotation and another, and the reason is more interesting than the absence.
Version one is not a deliverable, it is a starting point
Custom software is the only purchase your business makes where you discover the real need by using it. That is true by construction: it was written for a way of working nobody described completely, because nobody describes completely what they do every day.
The consequence is that the first version is always a hypothesis, and that the weeks following go-live produce more useful information than the months of specification before it. That is not a design failure, it is the normal mechanism.
What it changes is the budget rather than the method. A budget stopping at delivery funds the part of the work done with the least information, and leaves unfunded the part done with the most. That is exactly the wrong way round.
The useful rule is therefore to hold a reserve for the three months after go-live, before even knowing what it will be used for. A project consuming its entire budget on delivery day is a project that will not be able to learn from its own users.
Why two quotations for the same request differ fivefold
This is the question that brings people here, and it deserves better than a suspicion of dishonesty. Ask three suppliers to add a discount on orders and you will get three widely separated prices. None is necessarily inflated: all three priced different things.
The first understood a percentage discount typed by hand onto the order. The second added the rules the sentence implies without saying them: who is allowed to grant it, up to what ceiling, what becomes of it on an invoice already issued, how it shows in the accounts. The third included reworking existing orders and the state of past reports.
So there is no market price for a change, and not because the figure is hidden or badly measured. It is that there is no common unit: the three quotations are not for the same object. A spread between them measures the ambiguity of the request rather than how expensive a supplier is.
The consequence is practical and immediate. Comparing quotations only means something once you have written what the request contains and what it does not — which is the next section. Compared beforehand, the cheapest is simply whoever understood the smallest request.
Describing a change: what exists, what changes, what must not move
A useful change request fits in three paragraphs and is written without technical vocabulary. The first describes what happens today, using a real case rather than a generality. The second describes what should happen instead, on the same case. The third, the one people forget, says what must on no account change.
That third paragraph is the most profitable of the three, because it turns a future conversation into a written constraint. Orders already confirmed keep their old price is a sentence costing ten seconds to write which, absent, produces a week of argument after delivery.
Write the request from a concrete, dated case rather than in general terms: that client order, the one that caused trouble on Tuesday. A real case carries the details a general wording erases, and those details are precisely what moves the price by a factor of five.
Finally, a request is not a solution. Add a button to export is a solution; I have to give this list to the accountant every month and I retype it by hand is a request. The second allows a better and cheaper answer than the one you would have imagined; the first closes it off.
Bug or change: the boundary that decides who pays
This is the most common source of tension, and it is nearly always framed wrongly. The question is not whether the software behaves badly; it is whether it behaves differently from what was agreed.
A bug is a departure from what was intended: it was meant to do this, it does that. A change is an alteration of what was intended, including when the current behaviour is plainly awkward. Software doing exactly what was asked, and turning out to suit the real work badly, contains no bug — it contains a false hypothesis, which is section one.
That boundary is only sharp if something written says what was intended. With no record of the decision, every case becomes a good-faith negotiation between two people remembering differently, and the relationship wears out over small amounts.
The practice that settles it costs nothing: at every delivery, a list of the rules decided, in plain language, in the same document where requests are noted. It is not technical documentation, it is a record — and it serves you as much as the supplier, including when it says you were wrong.
The queue, and why it has to be visible
As soon as more than one person in the business is asking, there is a queue, and if nobody publishes it everybody assumes their request is next. The supplier then arbitrates alone, often by taking the easiest or the most recent, and nobody decided that.
A visible queue is a list everybody can read, with a state against each request — written, priced, accepted, in progress, delivered. Its virtue is not tidiness, it is that it makes arbitration explicit: when two requests cannot both go this week, somebody on your side chooses, and the developer no longer chooses by default.
It also changes the nature of chasing. Without it, each requester chases individually, and chasing becomes the prioritisation mechanism — which gives priority to the most insistent rather than the most useful. With it, where has my request got to has an answer nobody needs to ask for.
One rule keeps it useful: a request enters the queue only when written to the three paragraphs of section three. A queue full of one-line sentences looks like a work list and is not one, because none of its entries can be priced without a conversation.
Regression: the hidden cost of every addition
Software is not a sum of independent features. Every addition touches existing rules, and part of the cost of a change is checking that the rest still works. That part is invisible in the request and very real in the quotation.
It explains something every customer of custom software observes and usually attributes to bad faith: the same request, made two years later, costs more than it would have at the start. The software now contains more rules that must not break, and that is all.
Two consequences follow, and the second is counter-intuitive. The first is that it is better to group changes touching the same area than to ask for them one at a time over six months. The second is that it is sometimes cheaper to remove a feature than to add one, because a rule fewer is a rule that can no longer break.
It also gives a good question to ask at quotation time: which part of this price is the modification itself, and which part is checking the rest. A supplier who can answer understands their own system; a supplier for whom the question makes no sense is telling you something.
Environments: why two, and not five
You need somewhere the software does real work, and somewhere you can try things without consequence. Two. That is the minimum, and it is nearly always sufficient for a business that does not publish software.
Without the second, every trial happens on real data, and can we test the new invoicing ends with a real invoice sent to a real client. It is the kind of incident that happens once and costs more than the setup that should have preceded it.
The second also serves something other than the developer tests: it is where your own people validate a change before it becomes real. Validation by the supplier alone confirms the code does what they understood, which is not the same as what you needed — section three seen from the other end.
Beyond two, complexity grows faster than the benefit for an organisation this size: the copies then have to be maintained, synchronised, and one of them declared authoritative. That is a software publisher problem rather than a user one, and taking it on by imitation is spending with nothing in return.
The single developer, and what happens if they leave
Most custom software in a smaller business is written by one person, or two. That is why it is affordable, and it is the main risk in the arrangement. It never shows itself gradually: it shows itself on a Monday.
The right question is not how to avoid it, because it is not avoidable. It is how long somebody else would need to take over. A week is an acceptable risk; three months is a dependency to discuss while everything is fine, which is to say now.
Three things separate the two, and none is a three-hundred-page document. The code is with you, in a repository you hold access to. There is an installation note letting a stranger run the system on a fresh machine. And the business rules decided are written in plain language somewhere, which is the record from section four.
Those three do not make a departure painless; they make it quantifiable. That is the only reasonable objective, and it is also what lets you stay with a supplier by choice rather than by inability to leave.
What to receive at every delivery
A delivery is not a file or a message saying it is live. It contains four things, and receiving them consistently costs the supplier little while changing your position entirely.
The list of what changed, in plain language, including what changed without being asked for. The list of rules decided along the way, from section four. Confirmation that the delivered code is in the repository you own. And what is known to remain, including defects accepted for now.
That last point reveals a healthy relationship better than any other. Every piece of software in service contains known, uncorrected defects, because correcting has a cost and some are not worth it. Writing them down is a mark of seriousness; leaving them unsaid produces discovery at the worst moment, usually by a user.
Those four fit in one message. They need no tool, no methodology and no vocabulary: they need the habit, and it is a habit taken at the first delivery or never.
The cost of changing supplier, honestly
Changing supplier on custom software is neither impossible nor painless, and pricing it in advance avoids both usual errors: staying with somebody who no longer suits, or leaving in the belief that it costs nothing.
The real cost is almost entirely reading. The new supplier has to understand a system they did not write, and that unproductive period lasts longer the more the three items from section eight are missing. It is a cost you pay at the moment of change and that was decided years earlier.
There is a second, quieter cost: during the handover, changes stop almost completely. That is not an administrative pause, it is that touching a system you do not yet understand is the surest way to break something else. Plan for that period rather than discover it.
What is not a cost, on the other hand, is the software itself — provided the code belongs to you and sits with you. If that condition does not hold, changing supplier is not expensive: it is impossible, and that is a different situation, dealt with beforehand rather than on the way out.
Rewrite or carry on: the three signals
A moment comes when somebody proposes redoing everything. It is sometimes right and often premature, and appetite is a poor guide in both directions: a developer would rather write, an owner would rather not pay again. Three signals beat an impression.
The first is the ratio between time to understand and time to do. When a one-day modification needs three days of reading, this is no longer software being evolved, it is software being deciphered — and that ratio never improves on its own.
The second is chronic regression: every change breaks another, repeatedly rather than occasionally. That indicates the rules are entangled rather than badly written, and entanglement is not corrected in small touches.
The third is the vanished environment: the system rests on a version, a machine or a library that can no longer be obtained or updated. It is the only one of the three that imposes a calendar, because it turns a decision into a deadline. Below two of these three signals, rewriting nearly always costs more than what people believe they are saving.
What we do, and what we refuse
Our share is how this period runs: the visible queue and its arbitration, the request written in three paragraphs, the record of rules decided at each delivery, the two environments, and the code repository that belongs to you from the first line. These are habits more than tools, and they are taken at the start or not at all.
We refuse to give an average price for a change, and the reason is not caution: there is no common unit. Two quotations for the same request are for different objects, and a published rate would only move the ambiguity from the quotation to the invoice. What we price is a written request, and we would rather spend an hour writing it with you than defending a number afterwards.
We also refuse to hold your code. It lives in a repository in your name from day one, including when it does not yet interest you and we are the ones asking for it. A supplier you cannot leave is not a loyal supplier, it is a supplier who no longer needs to be good — and we do not want to be in that position.
Finally, the part that pays back fastest needs no development and needs nothing from us: write your next three requests to the three paragraphs of section three, and ask your current supplier how long somebody else would need to take over. The first will bring your quotations down; the second will tell you where you stand.
Frequently asked questions
Why do two suppliers quote such different prices for the same change?
Because they did not price the same object. Add a discount can mean a field to type into, or that plus the rules the sentence implies — who may grant it, up to what ceiling, what becomes of an invoice already issued — or that plus reworking what exists. There is no market price for a change because there is no common unit. Write the request first, compare afterwards.
How do you tell a bug from a change?
The question is not whether the software behaves badly but whether it behaves differently from what was agreed. A departure from the intended is a bug; an alteration of the intended is a change, even when the current behaviour is awkward. That boundary is only sharp if something written says what was intended, which is why rules get recorded at every delivery.
Why does the same request cost more two years later?
Because part of the price of a change is checking that the rest still works, and the software now contains more rules that must not break. It is not bad faith. Two useful consequences: group changes touching the same area, and remember it is sometimes cheaper to remove a feature than to add one.
Do we really need a second environment?
Yes, and two are enough. Without it every trial happens on real data and can we test the new invoicing ends with a real invoice sent to a real client. It also lets your own people validate a change before it becomes real, which the supplier cannot do on your behalf. Beyond two, complexity outgrows the benefit for a business that does not publish software.
What if only one person knows our software?
It is not avoided, it is made quantifiable. The useful question is how long somebody else would need to take over: a week is acceptable, three months is a dependency to handle while everything is fine. Three things separate them — the code in a repository you own, an installation note a stranger can use, and the business rules written in plain language.
When should software be rewritten rather than carried on?
Three signals, and at least two are needed: a one-day modification requiring three days of reading; chronic regression where every change repeatedly breaks another; and a vanished environment, meaning a version or machine that can no longer be obtained. Only the third imposes a calendar. Below two signals, rewriting costs more than what people believe they are saving.
Where we come in
Writing your next request in three paragraphs — what happens today, what you would want, what that changes elsewhere — costs nothing and changes the answer.
- We make the queue visible, with what goes ahead of what and why.
- We ask for the request in writing, including when it is urgent.
- We put your code under your own account from day one.
No average price for an evolution will be given: there is none, because the same sentence can cost an hour or three weeks depending on what it touches.
Read next
The pilot that will never ship: the signs, from week two
A pilot that fails rarely fails at the end. It fails in the second week, quietly, and everybody carries on for three months.Custom software: the specification you write is not the one you need
Nobody knows what they want before using it. A complete specification written beforehand is a guess set down in the present tense.The clause your supplier contract does not contain
Your contract describes a service: availability, support, price. It almost never says what the supplier is allowed to do with your data.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.