Custom software development: what it really costs, how long it takes and what the contract must say

You have three quotes for the same software and they range from eighteen thousand to seventy thousand euros. None of the three is wrong, and that is exactly the problem: they are answering three different questions, and the question was yours to write.

This article gives you the real arithmetic of custom software development. The day rates actually paid and the three project brackets with numbers. Why estimates always miss in the same direction, and where the time that was not in the plan actually goes. The two page document to write before asking for a quote, which is the single cheapest thing you can do and the one that saves the most. The seven contract clauses that decide whether, three years from now, that software is yours or your supplier's. And the seven signs a project is heading for a wall while everyone in the meeting keeps saying it is going fine.

I have been building software for twenty six years. I have written custom systems for banks, industry, professional firms and small provincial companies, I built a product of my own and sold it, and I have spent a fair share of that time putting back together projects somebody else had abandoned halfway. The failed projects I have seen almost never failed for technical reasons.

Here is the premise everything else follows from: when you buy custom software you are not buying lines of code, you are buying the decisions somebody will make on your behalf for the next several months. Code is the easy part, and today it is also the cheap part. The decisions are yours: if you do not make them, the supplier will, and they will make them in whatever way is most convenient for them, which is rarely the most useful way for you.

When custom software development is genuinely worth it, and when it is an expensive whim

There is a question that comes before the quote, before the technology and before the choice of supplier, and almost nobody writes it down: what happens if I do not build this?

If the answer is "we carry on as we are and it is fine", the project has no economic reason and sooner or later it will stall, no matter how well the contract was drafted. If the answer contains a number instead, meaning hours of wasted work, lost orders, penalties, customers walking away or a margin thinning month by month, then you have a project and you also have a budget, because the budget comes out of that number.

Here is an example I have seen in one form or another dozens of times. A company of forty people where three clerks spend two hours every morning re-keying data from one system into another. That is six hours a day, roughly thirteen hundred hours a year, which at fully loaded cost is worth somewhere between thirty five and forty five thousand euros. Software that removes that transfer, and costs twenty five thousand, pays for itself in under a year. No further analysis is needed: that number is already the justification, the budget and the yardstick the result will be measured against.

The three conditions that have to hold together

Custom software makes sense when all three of these are true, not one or two.

First: what you do differs from how others do it, and that difference is your margin. If the way you price, plan production or handle customer exceptions is part of how you make money, an off the shelf product will force you to give it up, because a package is built on the average of a thousand companies and you are off average precisely where you earn. If your difference is instead "we have always done it this way", that is not a margin, it is a habit, and habits can be changed for far less than the cost of software.

Second: the process you want to automate already exists and works. Automating a confused process produces confused software, with the added twist that afterwards the confusion is written into the code and changing it requires a quote. If the process does not exist yet, the right thing to do is run it for a few months with a spreadsheet and goodwill: it costs almost nothing, and at the end you hold the real rules instead of the imagined ones.

Third: there is one person in the company who can say yes and no. Not a committee, not "we will discuss it in the meeting": one person who knows the process, has the authority to decide and genuinely has the time. A custom project needs between two and six hours a week from that person, for its whole duration. It is the scarcest resource in the entire project and the one no quote ever lists. If that person does not exist or does not have those hours, postpone: it is not about money, it is that without timely decisions the supplier either stops or, worse, decides alone.

The four cases where you should not do it

A product already does ninety per cent of what you need. Buy it, and for the missing ten per cent work out whether to change the process or bolt on one custom piece. I worked through that decision, including the threshold beyond which the package stops paying off, in my article on off the shelf versus custom business management software.

The real problem is an integration, not an application. This happens often: people ask for new software because two existing systems do not talk to each other. Building a third system solves nothing and adds one more place where data can diverge.

The software you have is old but does exactly what is needed. Rewriting it from scratch to modernise it is almost always the most expensive and riskiest road there is, because along with the old code you throw away fifteen years of edge cases nobody ever wrote down. The incremental route costs less and breaks less.

You want the software to convince somebody. An investor, a customer, a board. For that you need a prototype, which costs a fraction and can be thrown away without regret. A prototype that becomes the product by inertia is one of the most common and least discussed causes of failure: it is born without thinking about data, without thinking about errors and without thinking about who will actually use it, and those three gaps all come due at once, always at the worst moment.

What custom software costs in 2026

I will start with the building block, because everything else is arithmetic on top of it: the cost of one developer day.

The real rates, by type of supplier

A senior Italian freelance sits between four hundred and six hundred euros a day. Below three hundred, for someone describing themselves as senior, something usually does not add up: either they are not senior, or they are desperate, or they are on three other projects at once and you are the one waiting.

An Italian software house sits between four hundred and eight hundred euros a day per person, and that is the range you see in most serious offers. That figure buys things a freelance cannot give you: somebody to cover illness, a second pair of eyes on the code, a structure that survives the August holidays.

A large consultancy sits between eight hundred and twelve hundred euros a day, almost always with a ratio of experienced to junior people that is worth asking about before signing. The right question is not what the day costs, it is how many of those days will be worked by someone who has done this before.

A low cost offshore supplier sits between one hundred and fifty and three hundred euros a day. It is a legitimate choice and sometimes it works very well, but the sum has to be done in full: add your own time to specify everything far more precisely, the time zone, the language, and above all the fact that the productivity gap between someone who understands your domain and someone executing a specification is enormous. On value for money, a supplier at two hundred a day who needs three times the days costs more than one at six hundred, and costs you months as well.

The reference number I use for back of the envelope maths on a first call is five hundred euros a day, which is about two thousand five hundred a week and about ten thousand a month for one full time person. From there the conversation gets simple, because every feature converts into days and every day into euros.

The three project brackets

Small: eight to twenty five thousand euros, six to twelve weeks. An application that solves one problem and solves it well. A portal where customers upload documents and see the status of their case. A tool that turns four spreadsheets into a proper store with real permissions. An automation that removes a manual transfer. Typically ten or so screens, one data store, one or two links to existing systems, ten to fifty users.

Medium: twenty five to eighty thousand euros, three to eight months. An application covering a whole process, one that enters the daily life of the company. A departmental system, a product configurator, a production planning tool, a portal for the sales network. This is where roles and permissions appear, real integrations with what already exists, the loading of historical data and, for the first time, the fact that if the software stops, somebody stops working.

Large: eighty thousand euros and up, beyond eight months. A system the company runs on, or a product you will sell to your own customers. This is no longer a project, it is a piece of company being born, and it should be treated as such: an annual budget, somebody accountable for it, and a life measured in years. If you land in this bracket on your first project, the advice is to split it, and I come back to that because it is the single piece of advice that saves the most.

Why three quotes for the same thing differ by a factor of four

It is rarely dishonesty. It is that the three suppliers read the same request and imagined three different pieces of software, and what separates them are five items the request did not mention.

How many exceptions. "Order management" can mean a list with four statuses, or a flow with approvals, tiered discounts, credit limit blocks and different rules for three sales channels. The difference between the two is a factor of five, and it lives entirely in one line of the request that was never written.

How much old data. Nobody charges you for "data loading" in a quote, and nobody imagines that data sits in three spreadsheets with customer names spelled five different ways. Cleaning up historical data, on a medium project, is often worth ten to twenty per cent of the total, and in ninety per cent of quotes it is worth zero.

How many systems it must talk to. Each integration with an existing system is worth three to fifteen days depending on how willing that system is to be queried. A modern system with a documented interface sits at the low end; a twenty year old one whose data you extract by reading its tables directly sits at the high end, and there are cases where the most expensive part is working out what those tables mean.

Who will use it. Software used by five people at a desk and software used by three hundred field agents on a phone have the same feature list and twice the cost, because in the second case every feature has to be designed for someone in a hurry, with one hand busy and nobody to ask.

How bad it is if it stops. Software that costs half an hour of work when it stops and software that halts shipments are not the same product. The second needs verified backups, active monitoring, a recovery plan and somebody on call: on its own that can be worth twenty to thirty per cent more.

When you get three very different quotes, the useful move is not to pick the lowest or the highest. It is to take the five items above and ask all three what they assumed on each. The answers will tell you who understood the problem, and the one who understood it is almost never the cheapest nor the dearest of the three.

The sum nobody does for you: five years, not five months

The number at the bottom of the quote is the cost of reaching the first day of operation. It is not the cost of the software: it is the cost of its first day. The real cost shows up over five years, and it has four items, three of which usually appear nowhere.

Building it

The only item in the quote. Call it a hundred, so the rest reads as a proportion.

Running it

The software has to run somewhere, and that place has a monthly cost. For an internal business application with a few dozen users, that is fifty to four hundred euros a month of infrastructure today, provided it is sized sensibly. Add the third party services you will use: digital signatures, email delivery, payments, maps. Each has a small subscription and there are five of them, and the sum is not small.

Ordinary maintenance

This is the item that is always missing and always arrives. Live software costs fifteen to twenty five per cent of what it cost to build, every year, and that is not a choice: it is a condition for continuing to use it.

This is not maintenance in the sense of adding features. It is the browser updating and changing a behaviour, a library with a security problem that has to be replaced, a law that changes a file format, a service provider modifying its interface with six months of notice. On a forty thousand euro project that is six to ten thousand a year to budget for before signing, not to discover in year two when somebody asks why the supplier is invoicing for software that was "already paid for".

Evolving it

The software works, people use it, and from that moment they ask for things. That is an excellent sign: it means it has entered real work. On a medium project, a sensible evolution budget is twenty to forty per cent of the initial cost per year for the first two years, tapering after that.

The worst way to handle it is one quote at a time, because every request becomes a negotiation and people stop asking even when they should. The best way I have seen is to buy a pool of days for the year, set priorities monthly and spend them. It costs the same, it is predictable, and it completely changes the relationship with the supplier.

The sum, lined up

A forty thousand euro build, over five years, realistically sits between ninety and one hundred and twenty thousand. That is not a hidden markup: it is the cost of having live software for five years rather than a delivery. The difference between knowing this beforehand and discovering it afterwards is not financial, it is relational: the first has bought a tool, the second feels cheated from year two onwards.

The question to put to every supplier, in writing, before signing, is a single one: what does it cost to keep this alive each year, and exactly what does that figure include? Whoever answers with a number and a list has done this before. Whoever answers "we will see as we go" is telling you the sum will be done when you can no longer change supplier.

How long it really takes, and why estimates always miss the same way

Software estimates almost always fall short, and they fall short by a surprisingly constant amount: between one and a half and two times. It is so regular that it is worth treating as a law of nature rather than as somebody's fault.

Where the gap comes from

A developer who estimates "three days" is honestly estimating the time to write that thing. They are not estimating the time to discover that the Date field in the store also contains empty strings, to wait for somebody to answer how the system should behave when a customer is on credit hold, to redo the screen after the people who will use it have seen it, to write the automated tests, to go back into a feature built two weeks ago because the new one contradicts it.

On a real project, writing new code takes thirty to forty per cent of the time. The rest is understanding, waiting, testing, fixing and coordinating. Estimate only the first slice and you get a number that will be wrong by a factor of two, every time.

Hence a rule of thumb, aimed at buyers rather than sellers: take the estimate you were given, add seventy per cent, and ask yourself whether the project still makes sense at that figure and that date. If it does, proceed calmly. If it does not, the problem is not the estimate: it is that you are buying something already at the limit, and the limit will be crossed.

The four things that were not in the quote

The old data. Always worse than described by whoever owns it. Duplicates, fields holding something other than what their name says, impossible dates, customers spelled five ways. Nobody is to blame: it is fifteen years of different people making things work. The way to avoid this blow is to ask, as the very first activity, for a read only report on the existing data. Two or three days of work, touching nothing and breaking nothing, returning the list of surprises before they turn into delays.

The people who will use it. What the boss describes is the process as it should be. What people do is the process as it is, with the shortcuts they invented to make it work. The two always diverge, and the divergence surfaces at the first demo, which is late. Half a day spent watching three people work, before a line is written, moves a project further than two weeks of meetings.

The integrations. Every external system is a promise made by somebody else. The documentation is old, there is no test environment, the credentials take three weeks, and the real behaviour does not match the written one. That is not pessimism, it is the norm. Integrations should be exercised at the start of a project, not at the end, even with a trivial call, because it is the only way to find out early something that, found late, stops everything.

Access and approvals. System access, authorisations, the contact on holiday, the external consultant who has to sign off. These are the silliest weeks in a project and the ones nobody plans for. There is one way to prevent them: list at the start everything needed from third parties, with a name and a date next to each.

How to buy time instead of buying delay

The most useful advice I can give someone facing their first project is not to buy it all at once. An eight month project has a poisonous property: for eight months you do not know whether it is going well, and by the time you find out you have spent everything.

The shape that works is different. Pick the slice that, on its own, is already worth something to the company, and buy that. Six to eight weeks, a piece that reaches real people and produces a measurable result. Then decide whether to continue, and decide on facts rather than hopes: you have watched the supplier work, you have seen how users reacted, you have a number.

This costs maybe ten per cent more in total, because some things get redone. In exchange, the maximum exposure drops from the whole budget to the cost of one slice. It is the cheapest insurance in this trade, and almost nobody buys it.

The two page document to write before asking for a quote

There is a costly misunderstanding here. Many people think the alternative to "I will explain what I need" is an eighty page specification. It is not, and the eighty page specification is often worse than the conversation: it is long, nobody reads it to the end, it describes the easy things in detail and stays vague exactly on the things that drive the price.

What you need is two pages, written by you, in plain language. They are the two pages that save the most across the whole project, and they take an afternoon.

The eight items

1. The problem, in five lines, with a number in it. Not the solution: the problem. "Three people spend two hours a day re-keying orders from the portal into the business system, and once a week an order goes missing." A serious supplier reading that can propose a solution you had not imagined, sometimes a cheaper one.

2. Who will use it, how many, from where. Five clerks at a desk, or eighty technicians on a phone on site with no signal. It changes everything and it is one line.

3. The three things that must work on day one. Only three. The exercise is annoying and that is precisely why it is useful: it forces you to separate the essential from the desirable, and it gives you the criterion for judging the first delivery.

4. The things that can wait. Listing them serves two purposes: the supplier keeps them in mind while designing, and you do not pay for them now.

5. The systems it must talk to, with name and version. Not "our business system": the name, the version and, if possible, who maintains it. It is the single piece of information that moves the price most, and it is missing from most requests.

6. The data that already exists and where it lives. How many rows, in what shape, who put it there. Even if the answer is "four spreadsheets looked after by Anna", writing that down is worth more than ten lines of functional description.

7. Your exceptions. The rules you apply that a generic company in your sector would not. This is the most valuable part of the document, because it is the reason you are buying custom, and it is almost always what nobody mentions because to the people doing it, it seems obvious.

8. What you are prepared to spend and by when you need it. Many leave this out for fear the quote will rise to meet the stated figure. The opposite happens: a supplier who knows the budget can tell you what fits inside it, and one who does not will propose the project they imagine, which is usually not the one you can afford. If a figure is not feasible, better to know in week one.

How to use it

Send those two pages to three different suppliers, not one, and read not so much the prices as the questions they ask. A supplier who quotes without asking questions is guessing, and the gap between their guess and reality will be paid by you, either in change requests or in software that does not do what is needed.

Good questions are recognisable: they are about exceptions, old data, what happens when things go wrong, and who inside your company will decide. Weak questions are about button colours and preferred technology.

Choosing the supplier: ten questions and five red flags

The criterion I use when somebody asks me to help them choose is simple: I am not looking for the most technically brilliant supplier, I am looking for the one who has already done something similar three times and who answers awkward questions without dodging.

The ten questions

1. Will you let me speak to two customers you did something similar for? Not the testimonials on the website: two phone numbers. Whoever has worked well has them and gives them gladly.

2. Who will work on my project, by name, and what else will they be on during the same period? This is the question that exposes the gap between who sold to you and who will do the work.

3. What happens if the person leading the project leaves? The right answer describes a practice, not a reassurance: the code is written so somebody else can read it, there is minimal documentation, there is a second person who knows where things are.

4. How often will I see something that works? An acceptable answer is measured in weeks, not months, and "something that works" means something I can click on myself, not a presentation.

5. Where will the source code live? The right answer is: in a repository owned by you, which you can access from day one, containing everything needed to restart the project elsewhere.

6. How are unforeseen requests handled? There will be some, always. There has to be an agreed way to assess them and to decide whether they replace something else or add to it, and that way must be written down early, while the relationship is still calm.

7. What will you not do? An experienced supplier has an answer ready, and it is usually an interesting one. Anyone who says they can do everything is saying they have not yet met their limits, which is more worrying than reassuring.

8. What does it cost to keep alive in year two? A number and a list, as above.

9. How will I know it is going well while you are doing it? Two or three agreed indicators must exist, visible to you without asking permission.

10. If we part ways in a year, what am I left holding? The most awkward question, and the one that separates suppliers from owners of your software. The right answer is a list of concrete things and a procedure for getting them.

The five red flags

The quote arrives without questions. Already said, but it is the most common and the most expensive.

The price is far below the other two. In software there is no discount on raw materials: the raw material is people's time. A price at half the others means half the time, and half the time means something will not be done. Almost always it is the part you cannot see: the tests, the error handling, the security, the data cleanup.

Technology comes before the problem. If in the first meeting they explain why they use a certain tool and have not yet asked how you work, you are buying their enthusiasm, not your solution.

The code stays with them "for convenience". It is not convenience, it is a bargaining position that makes itself felt at the first disagreement.

They cannot tell you who will use the software. If, asked who will use it every day, they answer with job titles rather than with people and what they do, they have not understood the problem yet, and they will design for the buyer instead of the user. That is the mistake that produces software nobody uses.

The contract: seven clauses that decide whether the software is yours

This is the part almost nobody reads carefully, and it alone decides half the value of what you are buying. These are not clauses hostile to the supplier: a serious supplier accepts all of them without argument, because they are the normal way to work. Resistance on any one of them is, in itself, information.

1. Ownership of the code, stated explicitly

The contract must say that the economic exploitation rights in the commissioned software are yours, exclusively, without limits of time or territory, and that they transfer to you as the work proceeds. The wording to avoid is "the client receives a licence to use": that is a different thing, and over time it weighs heavily.

The part the supplier reuses across clients must be handled too, and handled now, because it exists in nearly every software house. The balanced form is: what the supplier already had stays theirs and you receive a perpetual, irrevocable right to use it inside your software, while everything written for you is yours. What must not happen is discovering two years later that an essential part of the system is a supplier component nobody else may modify.

2. The source code in your own house, from day one

Not on delivery: from day one. The code repository should be owned by your company, with one of your email addresses as owner, and the supplier joining as a collaborator. It costs nothing and it changes everything.

Inside there must be not only the code but the instructions to start it from a blank machine, the structure of the data store and the release procedures. There is one proof that this clause is genuinely honoured, and it is worth demanding halfway through: an outside person, with what is in the repository and nothing else, can get the software running. If they cannot, what you have is not your software: it is a promise that your supplier will run it for you.

3. Dependencies and licences, declared

All modern software is partly made of third party components. The contract should require an up to date list of these with their licences, and an undertaking that none of them imposes obligations incompatible with your use. It is trivial to satisfy, and the day you buy or sell a company it is one of the first things somebody will ask for.

4. Infrastructure in your name

The domain, the cloud subscription, the third party services: in your company's name, paid by you, with the supplier accessing through their own user. This is the most frequent mistake and the most irritating to fix afterwards: when the subscription belongs to the supplier, changing supplier means migrating everything under time pressure, and that migration always costs more than what was saved by letting them handle it.

5. The data is yours and comes out in a readable form

There must exist, and it must be proven before the project ends, a procedure that extracts all your data in an open, documented format. Not "we can do an export if needed": a procedure somebody has run at least once and whose output you have seen.

6. What "it works" means, and who says so

Delivery should be tied to verifiable criteria agreed in advance, not to an impression. No lengthy document is needed: ten to fifteen sentences of the form "an operator enters an order with three lines and a discount, and the business system receives it within five minutes with the correct total". Anyone can check those, and they remove the most exhausting argument there is, the one about what was included.

7. The exit, described while you still agree

The contract must say what happens if the relationship ends: how many handover days are included, at what price, with what notice, and which materials are delivered. It takes ten lines and it is written at the start, because at the end, when it is needed, nobody feels like being reasonable any more.

One more thing, which is not a clause but is worth as much as the seven. If the software your company runs on depends on a single person, the biggest risk is neither technical nor contractual: it is that this person changes their life. The way to reduce it is to own the code, own the infrastructure, own the data and have a second supplier look things over now and then.

How to pay: fixed price, time and materials, or by sprint

There are three forms and they are not equivalent. The choice of form moves risk from one side of the table to the other, and it is worth knowing which way it is moving.

Fixed price for a defined result

It looks like the safest for the buyer and partly it is: you know what you will spend. But the price contains a safety margin the supplier adds to cover uncertainty, and the vaguer the request, the higher that margin. If the project turned out to be simple, you paid the margin anyway.

There is a worse side effect. At a fixed price, every change becomes a negotiation, and since changes in a software project are inevitable, the relationship slides from collaboration into accounting. In the worst cases the supplier starts defending the scope instead of solving the problem, and you stop reporting things to avoid opening yet another argument.

It works when the scope is genuinely closed and small: an initial phase, a single integration, a piece of work you can describe in one page without embarrassment.

Time and materials

The form most honest about how the work actually goes, and the one everybody fears because it looks like a blank cheque. It is not, if you set two limits: a ceiling beyond which work stops and you talk, and a report you can read in two minutes showing what was done and what it cost.

It works when the problem is still being understood, when an old system is involved that will hold surprises, or when the project is long and will inevitably change course.

By sprint: you buy a period, not a list

This is the form I use most and recommend most. You buy a two week block at a fixed price, at the start of the block you agree together what goes in it, at the end you see something that works and decide whether to buy the next one.

The advantage is that maximum exposure, at any moment, is one block. There are no change negotiations, because priorities are set afresh every two weeks. And there is a less obvious benefit: it forces both sides to think in terms of priority rather than complete lists, which is how things actually get done.

The drawback is that it needs more involvement from you: those two to six hours a week become a real commitment, not an intention. Anyone unwilling to put them in is better off with fixed price, and should budget for the safety margin.

The mixed form, which is the one that works

In practice the arrangement that gives the best results is mixed. A short first phase at fixed price, two or three weeks, whose output is not code but clarity: the report on existing data, the integrations actually exercised, the scope of the first delivery and an estimate that is by then worth something. On a medium project it costs three to eight thousand euros and it is the highest yielding spend in the whole project, because it removes the estimation gap exactly where it is widest.

Then the rest in blocks. And, after go live, an annual pool of days for maintenance and evolution, with priorities set monthly.

The seven signs a project is about to fail

Projects do not fail suddenly. They give signals for weeks, and it is always the same seven. The value of knowing them is that each has a response that costs little if done now and a great deal if done in month six.

1. Three weeks in and you have not clicked on anything. You have been shown drawings, slides, perhaps an analysis. No working software. The move: ask for something working within ten days, however ugly, however partial. If the answer is that it is not possible until the architecture is complete, the project is heading down the road where all the problems are discovered at once, at the end.

2. Meetings have turned into reassurance. When the status goes from "this week we closed these three things and a new one came up" to "we are progressing well", something has broken. The move: ask for the list of closed and open items, in writing, every week. It is a normal request and the reaction will tell you a lot.

3. The same things are "nearly finished" more than once. A feature declared done in March reopens in April and again in May. It almost always means there are no criteria for calling something finished. The move: the fifteen verifiable sentences described earlier, written even mid project. It is never too late to introduce them.

4. None of the real users has seen it yet. The software is only shown to whoever commissioned it. The move: put it in the hands of two people who will use it, for an hour, and stay quiet and watch. It is the most instructive hour of the whole project and it always happens too late.

5. The supplier has stopped saying no. At the start they explained why a request was expensive or wrong. Now they say yes to everything. That is not service, it is surrender. Whoever says yes to everything has stopped designing and is accumulating debt you will pay in delays and in things that break each other.

6. The to do list grows faster than it shrinks. Measure it, do not sense it: two numbers a week, opened and closed. If for three weeks running the opened ones grow, the project is not converging, and pushing harder will not help. The move is to cut scope, not add people.

7. Nobody can say how much is left. Not "I do not know precisely", which is honest: the actual inability to give an order of magnitude. It means the map is gone. The move is to stop for a week and rebuild the list of what genuinely remains. It looks like wasted time and it never is.

If you recognise three of these together, stop the project for a week. Do not cancel it: stop it. A week's pause with a serious review costs five days. Pushing a project that is not converging costs months, and the difference between those who stop and those who do not is not the supplier's skill: it is that somebody had the nerve to say it was not working.

AI has changed the sum, but not where you think

In 2026 this question comes up in every negotiation, and it almost always arrives in the wrong form: "now that there is AI, shouldn't it cost less?".

The honest answer is: partly yes, and not in the part you imagine.

Writing code today is faster. On repetitive, well bounded work, with tools used properly, the gain is substantial: the skeleton of an application, standard screens, automated tests, documentation, translation from one language to another. But writing new code, as I said, is thirty to forty per cent of a project's time. Even halving it does not halve the project: it comes down by fifteen to twenty five per cent, which is still a notable result.

The rest of the time, understanding the problem, deciding, testing, fixing, coordinating, has not shrunk. In one case it has grown: reviewing code produced quickly demands more attention, not less, because it is plausible even when it is wrong.

What to demand from a supplier on this

Do not demand the discount: demand the speed and the quality. A supplier using these tools well in 2026 shows you something working sooner, has higher automated test coverage than two years ago, and produces documentation without being asked three times.

And demand two written guarantees that have become normal and that many contracts still lack. First: code produced with automated assistance is covered by the same ownership and non infringement warranties as the rest. Second: your data, your code and your documents do not end up in services that use them to train models. Two lines, and a supplier who has already thought about it signs them without fuss.

Anyone offering a sixty per cent discount because "there is AI now" is telling you they have cut hours, not that they have got better. You will see the sum in month three, when somebody has to work out why a feature does something nobody decided.

A real case, including what I got wrong

The most instructive custom project I ever did was my own: LegalDesk, a multi tenant platform for law firms, built from scratch and later sold.

What it taught me has nothing to do with technology. It has to do with where the time actually goes, and it is the reason I estimate differently today when I estimate for somebody else.

The part everyone pictures as the product, the features the user sees and pays for, was less than half the work. The other half went into things no quote lists and no customer sees: keeping the data of different firms separate so they can never touch, access and permissions done properly, loading the data firms brought with them from previous systems, subscriptions and invoicing, and the piece I underestimated most of all, what happens to a new customer in the first thirty minutes they open the product.

That last piece, the way in, I had treated as a detail to sort out at the end. It was in fact the thing that decided whether a customer stayed or disappeared, and redoing it afterwards cost far more than thinking it through beforehand would have.

Two lessons I carry into every project of somebody else's.

First: the value is not in the features, it is in the transitions. Software is judged by the moment a person arrives at it for the first time and by the moment something goes wrong. Those are the two moments almost everybody postpones and the two that decide whether it gets used.

Second: the cost of software is dominated by what you cannot see. If in a quote the "existing data" line, the "permissions" line and the "what happens when something fails" line are all worth zero, that quote is not lower: it is incomplete, and you will make up the difference, in money or in months.

What to do on Monday morning

If you are weighing up a custom build and want to start on the right foot, this is the order I would follow.

Write the problem down with a number in it. Half an hour. If you cannot put a number in it, the project is not ripe and the most useful thing is to measure for a month.

Watch two people work. An hour each, without interrupting. Note the shortcuts they use: those are the real requirements.

Write the two pages. One afternoon, the eight items above. This is the document that will make the difference across the quotes.

Ask three suppliers and read the questions. Not the prices first: the questions. Then compare prices knowing what each one assumed.

Buy clarity first. A short initial phase at fixed price with a concrete output: the data report, the integrations exercised, a serious estimate. Three to eight thousand euros that stop you making the wrong forty thousand euro decision.

Put the seven clauses in the contract. Code yours, repository in your name from day one, dependencies declared, infrastructure yours, data exportable, verifiable criteria, exit described. An hour of work with your adviser, worth years.

Budget for year two. Fifteen to twenty five per cent a year for maintenance, plus whatever you choose to spend on evolution. Before signing, not after.

The point, briefly

Custom software development is not expensive or cheap in the abstract: it is expensive when you buy a project and worthwhile when you buy a result you can measure. The difference between the two is made by you before you request the first quote, not by the supplier afterwards.

There are only a few numbers to remember. A working day is around five hundred euros. A small project is eight to twenty five thousand, a medium one twenty five to eighty thousand. The estimate you receive should be raised by seventy per cent to see whether the project still holds. And every year, to stay alive, the software costs fifteen to twenty five per cent of what it cost to build.

The two highest yielding moves are both cheap and neither is technical: writing two honest pages before asking for offers, and buying a short first phase of clarity instead of buying everything at once.

And the last one, the one I see skipped most often. Custom software is yours only if the code, the infrastructure and the data are in your name from day one. If they are not, what you bought is not software: it is a subscription to a supplier, with the difference that you will learn the renewal price when you can no longer say no.