Software house: how to choose one, what it costs, what to ask before signing and the number that decides over five years

A window and door company in Treviso, forty employees, decides to replace the Excel file it uses to plan installations. It asks three software houses it found on Google for quotes. The first costs 78,000 euros, the second 120,000, the third 135,000. The owner picks the first: "Same result, 57,000 euros less." Eight months later the program is in production, five months late. The code sits in the vendor's repository, every change is billed separately, and no other developer can touch it without a month of study.

The case is a composite, not a real client, but I have seen dozens that look like it. The question "which software house do I pick?" is almost always answered by looking at the first line of the quote, the one with the price. It is the line that tells you the least.

In this article you will learn how to choose a software house by looking at what it really costs over five years. I explain what the six types of company that call themselves that actually are, what they cost in 2026, what changes between fixed price and time and materials, and which twelve questions expose a weak vendor in half an hour. There is a calculation in euros with every assumption written in plain sight, a C# program I compiled and ran to compare three offers, and one number that decides almost everything: how many days another vendor needs to take over your code.

A fair disclaimer. I have been designing software for companies since 1999, and I built and sold a multi-tenant legal management system. I have spent more years on the other side of the table than I care to admit, writing quotes, reading them, and fixing the ones written by others. All the numbers below are orders of magnitude I meet in proposals, plus declared assumptions. They are not market statistics. They are there to make you redo the calculation with your own data, not to replace it.

What is a software house, and why do six different trades hide under the same name?

"Software house" means one thing: a company that develops software. But anyone searching the term on Google finds, under the same label, businesses that have almost nothing in common, and one's quote cannot be compared with another's. The first move toward a good choice is understanding which of the six you are talking to.

The point almost nobody makes: none of the six is better in absolute terms. A web agency is the right choice for a portal that publishes content. A product software house is the right choice if you need a management system for your category and your process fits inside it. A factory is the right choice when the project is large and you need a method. Mistakes happen when you ask one type to do another type's job.

The second point is the word "vendor". A software house that hands you a program and disappears is a vendor. One that stays, maintains it and answers for it for years is a technical partner. The price on the quote is the same. The difference is in the contract and in the person who picks up the phone the day something breaks.

Before asking for quotes, answer three questions in writing. Does the program do something your competitors also do, or something that sets you apart? How many people will use it every day? Who, inside the company, will be the contact person who decides when the vendor asks for clarification? If you cannot answer the third, the problem is not the vendor: the project owner is missing, and no software house, however good, can fill that role for you.

How much does a software house cost in 2026?

Rates are no secret, but they are rarely written down. These are the orders of magnitude I see in proposals for .NET and web projects in Italy, in euros per eight-hour day, VAT excluded.

A structured software house bills you an average rate that blends these profiles, usually between 380 and 480 euros per day. It includes costs a freelancer does not have: someone who manages the project, someone who does testing, someone who answers the phone. When a quote looks cheap, check how the days are made up: four junior days for every senior day is a low price and a high risk.

How much a project costs, by size

On top of these numbers, every year add 12 to 22% of the development cost for maintenance: fixes, security updates, small changes, hosting. Anyone who tells you that software "has no costs after delivery" has either never maintained it or is making their margin elsewhere. For the details on timing and contracts of a custom project, see the guide to custom software development: get in touch for a software consultancy.

There is one cost that never shows up in quotes: your time. A medium project asks the internal contact for four to eight hours a week for months, between meetings, answers, tests and acceptance. At an internal cost of 32 euros an hour, that is 3,000 to 6,500 euros a month of work that no vendor bills you for and that the final calculation must include.

Fixed price or time and materials: who carries the risk?

After the price, the line that decides the rest is the contract model. There are four, and each one moves the risk to a different place.

Fixed price is attractive because it seems to remove the risk. It does not remove it, it prices it in. The vendor knows the requirements will change, and puts a reserve of 20 to 35% into the quote, or writes the scope narrowly and bills everything else as a variation. In a software project the scope always changes, because you find out what you need by using it. With a fixed price, every discovery becomes a negotiation.

Time and materials is honest and dangerous. Honest because you pay for what gets worked. Dangerous because nobody has an interest in finishing. The solution I use, and recommend, is a middle path: fixed price for short phases of four to six weeks, with a written scope for each, and an overall spending cap reviewed at the end of every phase. The vendor has a precise commitment, you can stop after each phase, and discoveries are paid at the price of a phase, not of a variation.

A dedicated team only makes sense if you already have a technical lead who can steer it, or if you hire an architect to steer it for you. A monthly fee makes sense for an off-the-shelf product, with all the cost of a subscription, and not for a custom project: in that case you are renting something that was made just for you.

What does the cheapest quote really cost?

Back to the three quotes from Treviso. I put them on the same five-year scale. The project is the same, a program to plan installations, orders and crews. The three offers:

• A, the lowest price: 78,000 euros fixed price, a mostly junior development team, code in the vendor's repository, maintenance at 20% a year.
• B, a structured software house: 120,000 euros, code in the client's repository from day one, maintenance at 15%.
• C, a senior architect with a small team: 135,000 euros in phases, time and materials with a cap, maintenance at 12%.

The calculation below has eight items. Every assumption is written in the code, so you can swap in your own.

1. Development price: the one on the quote.
2. Variations: in a real project the scope grows by about 30% over the initial document. Vendor A bills them at a rate 1.35 times the one implied in the price, B at 1.10 times, C at the normal rate.
3. Rework: delivered parts that must be redone after acceptance and are not covered by the warranty. 25% of the price for A, 8% for B, 5% for C.
4. Maintenance: the yearly percentage for five years.
5. Delay: every month of delay costs 4,000 euros in benefits that do not arrive. Five months for A, two for B, one for C.
6. Expected exit: the probability of changing vendor within five years is 35%. If it happens, two people work for the takeover days at 480 euros each.
7. Hostage cost: if the takeover days exceed twenty, the vendor knows you cannot leave and from the third year raises maintenance by 30%.
8. Expected failure: the probability that the project is abandoned (20% for A, 8% for B, 5% for C), multiplied by 70% of the price already spent plus 100,000 euros to redo it elsewhere.

The assumptions are mine and open to debate: the 20% failure rate for the first offer is a professional opinion, not a statistic. That is why the code is below, and why after the result I show you how much the total changes when the assumptions move.

static Costi Calcola(Offerta o, Ipotesi h)
{
    var variazioni = o.Prezzo * h.CrescitaAmbito * o.MoltiplicatoreVariazioni;
    var rifacimenti = o.Prezzo * o.QuotaRifacimento;
    var manutenzione = o.Prezzo * o.ManutenzioneAnnua * h.Anni;
    var ritardo = o.MesiRitardo * h.CostoMensileRitardo;
    var uscita = h.ProbabilitaCambio * o.GiorniSubentro * h.PersoneSubentro * h.TariffaGiornaliera;
    var ostaggio = o.GiorniSubentro > h.SogliaOstaggio
        ? o.Prezzo * o.ManutenzioneAnnua * h.RincaroOstaggio * (h.Anni - 2)
        : 0m;
    var fallimento = o.ProbabilitaFallimento * (o.Prezzo * h.QuotaPerduta + h.CostoRifacimentoAltrove);
    var totale = o.Prezzo + variazioni + rifacimenti + manutenzione + ritardo + uscita + ostaggio + fallimento;
    return new(totale, variazioni, rifacimenti, manutenzione, ritardo, uscita, ostaggio, fallimento);
}

record Offerta(string Nome, decimal Prezzo, decimal MoltiplicatoreVariazioni, decimal QuotaRifacimento,
    decimal ManutenzioneAnnua, int GiorniSubentro, int MesiRitardo, decimal ProbabilitaFallimento);

record Ipotesi
{
    public int Anni { get; init; } = 5;
    public decimal CrescitaAmbito { get; init; } = 0.30m;
    public decimal CostoMensileRitardo { get; init; } = 4_000m;
    public decimal ProbabilitaCambio { get; init; } = 0.35m;
    public int PersoneSubentro { get; init; } = 2;
    public decimal TariffaGiornaliera { get; init; } = 480m;
    public int SogliaOstaggio { get; init; } = 20;
    public decimal RincaroOstaggio { get; init; } = 0.30m;
    public decimal QuotaPerduta { get; init; } = 0.70m;
    public decimal CostoRifacimentoAltrove { get; init; } = 100_000m;
}

record Costi(decimal Totale, decimal Variazioni, decimal Rifacimenti, decimal Manutenzione,
    decimal Ritardo, decimal UscitaAttesa, decimal Ostaggio, decimal Fallimento);

I compiled it with .NET 10 and ran it. The full program has, besides the block above, three print loops of about twenty lines. This is the result:

Read the difference. On the quote, A costs 57,000 euros less than C. Over five years, A costs 13,555 euros more than C. The apparent saving does not vanish because the vendor is dishonest: it vanishes because the low price gets made up elsewhere, in pricier variations, rework, delays, dependency and a higher chance of failure.

The most useful result for me is not the ranking, it is that the three totals sit within 13,500 euros out of almost 300,000. The quoted price does not separate the offers. What separates them is risk, meaning how wide the range of things that can happen is.

Look at how the comparison between A and B moves when the project grows more than expected:

The more the project grows, the closer the low offer gets to the others, because its base is smaller. But in none of the four scenarios does A cost less than B. And the calculation does not include the worst case, the one where the vendor disappears with the code inside its own repository.

Which number decides almost everything?

I said the price does not separate the offers. What separates them is a number that no quote contains: the takeover days. These are the days a competent person who did not write the code needs to download it, get it running on a clean computer, understand it well enough to fix an error, and release a change.

Why this number and not another? Because it measures, all at once, things you would not otherwise see: whether the code is readable, whether tests exist, whether the environment can be rebuilt with one command, whether documentation exists, whether the repository is yours. Above all it measures how free you are to leave, and the freedom to leave is the only bargaining lever you have after signing.

In the earlier calculation I used it in two ways. The first is the exit cost: if you change vendor, two people work for those days. The second is the hostage cost: beyond twenty days the vendor knows leaving would cost you too much, and maintenance goes up. Here is how the total for offer A changes as the number of days alone varies, with everything else held fixed:

From five to sixty days, the same vendor at the same price costs 32,520 euros more. Almost all of the jump sits between twenty and thirty days, where dependency kicks in. That is why the practical rule is a threshold: under twenty days you are free, over thirty you are a hostage.

These numbers are not carved in stone: the twenty-day threshold is mine, and it comes from projects I have seen change hands. But the shape of the chart is always the same, a step, and the step sits where the client stops being able to threaten to leave.

How do you measure takeover before signing?

You measure it by doing it, in miniature. Any software house with a project already delivered, even a small one, can lend you an example of its work. You ask it to have an outside person, who did not write it, download that project and start the system from scratch. If it cannot do that for confidentiality reasons, you pick an internal one or a test project. The time it takes is your number.

You can hand the check to an independent technical consultant, for a day or two, which costs far less than the calculation above. This is the script I give them. It measures the minutes of each step, from an empty repository to a running system with green tests:

#!/usr/bin/env bash
# Misura in minuti quanto serve per far partire un progetto da un computer pulito.
# Uso: ./test-subentro.sh <indirizzo-repository> "<comando-di-build>" "<comando-di-test>"
set -euo pipefail

repo="$1"; build="$2"; prova="$3"
inizio=$(date +%s)
passo() { echo "[$(( ($(date +%s) - inizio) / 60 )) min] $1"; }

git clone --quiet "$repo" progetto
cd progetto
passo "repository scaricato"

bash -c "$build"
passo "ambiente ricostruito e progetto compilato"

bash -c "$prova"
passo "test passati"

echo "Tempo totale: $(( ($(date +%s) - inizio) / 60 )) minuti"
echo "Ora una persona esterna prova una modifica di una riga e la rilascia in prova."

The number it produces is a minimum, because whoever runs it has the instructions in hand. The rule is: if an expert cannot get the system running in half a day using only the repository and the instructions file, the real takeover days are more than twenty. If you need to call whoever wrote it to find out what to do, they are more than thirty.

The four steps have a maximum time that I consider acceptable for a medium project:

• Download the repository: 10 minutes. If you must ask someone's permission to get the code, the code is not yours.
• Rebuild the environment: 90 minutes. Database, configuration, secrets. If you need "the config file only Marco has", that is a debt, not a detail.
• Get the tests passing: 60 minutes. If tests do not exist, a safe takeover is not possible: every change becomes a gamble.
• Release a trial change: 120 minutes. A one-line change, in a test environment, going through the real release process.

That adds up to about five and a half hours. A project that goes well beyond them is not necessarily badly made, but it is telling you that you will have to pay its knowledge holder forever.

Which twelve questions expose a vendor?

A prepared vendor answers these questions without stiffening, often with pleasure. An unprepared one changes the subject, sends you a brochure or tells you "it depends". Ask them in a half-hour meeting, and write down the answer word for word.

1. Who will write the code for my project, with names and years of experience? A good answer has three names and one lead. A bad one says "our team", with no names.
2. Where does the code live, and whose repository is it? It must be in your account, with vendor access, from day one. If it is in theirs and "handed over at the end of the project", that is blackmail with a deadline.
3. How many days does another vendor need to take over? This is the question from the previous chapter. A confident vendor proposes the test itself.
4. How do you handle a request that changes the scope mid-project? You want to hear a process with a written rate. Not "let's talk about it".
5. Which parts of the work are covered by automated tests, and what percentage? Any number, even a low one, as long as it is honest. "We test by hand" is an answer too.
6. Can I talk to two clients with more than three years of relationship with you? Not the case studies on the website. Two phone calls, with real people. Whoever refuses has a retention problem.
7. What went wrong on your last project, and what did you change? Whoever has never failed has never delivered. What counts is the lesson.
8. Who answers when something breaks at night or on the weekend, and how fast? A good answer has a number of hours and a stated cost.
9. Where will the system run, and who pays for the infrastructure? If the server is the vendor's, the data is in their hands. If it is yours, you need to know what it costs per month.
10. How do you handle personal data, and will you sign the data processor appointment? A vendor that touches customer or employee data must have the appointment and know what it means.
11. Which technologies will you use, and why these? If the choice is "what we know how to do" instead of "what you need", the vendor is selling their own convenience.
12. What should I not ask you for? This is my favorite. An honest software house can tell you what it does not do well and who to send you to.

After the meeting, score each answer from 0 to 2. Zero for evasion, one for a partial answer, two for a precise and verifiable answer. Under fourteen points out of twenty-four, you do not go forward.

Which signals in the quote say "stop"?

The quote speaks even when the vendor stays silent. These are the six signals that make me reread everything.

• A single number, with no assumptions. "Application development: 78,000 euros". A serious quote says what is included, what is not, how many days per profile, and which assumptions it rests on.
• No separately paid analysis phase. Pricing a medium project without having talked to the people who will use it means the price is a guess, and you will pay the difference later.
• Timelines much shorter than the others. If two vendors say nine months and the third says four, the third is not faster: it understood something else or is promising in order to sell.
• No names. If the quote does not say who will work on the project, whoever is free that month will.
• Maintenance absent or very high. Under 10% a year means there will be no service. Over 25% means the cost is hidden in the aftermath.
• Vague code ownership. "The client has the right of use" is not "the client is the owner". The difference costs you the day you want to change vendor.

One signal alone is not enough to rule anyone out: quotes get written in a hurry, and many are badly written by people who work well. Two signals together deserve a phone call. Three are a reason to pick someone else.

Which contract clauses really matter?

I am not a lawyer and this is not legal advice: have someone qualified review the text. But after many projects I know which clauses make the difference when things go wrong, and there are eight.

1. Ownership of code and documentation. Yours, from the moment each phase is paid, not "at the end". With the explicit exception of the vendor's pre-existing libraries and components, which stay theirs but come with a perpetual license of use in your favor.
2. Client repository. The vendor works in your account, with their permissions. Changing vendor becomes removing a user, not a negotiation.
3. Acceptance by phase. Written criteria, acceptance testing within a defined time, payment at the end of the phase. Silence is not acceptance.
4. Warranty on defects. At least twelve months from going into production, with fix times by severity. Define clearly what a defect is and what a new request is.
5. Service levels. Response and resolution times by severity, covered hours, a penalty if they are missed. A penalty does not compensate for downtime, but it directs attention.
6. Orderly exit. If the relationship ends, the vendor guarantees a handover period with the successor, at rates already written down. One sentence saves half of the takeover days.
7. Key people. If the names in the quote change, the client has the right to approve the replacements. This is often dodged with the phrase "or people of equal level", which means nothing.
8. Data protection and confidentiality. Data processor appointment, list of sub-vendors, place where data is stored, duty to notify in case of a breach within a written number of hours.

The contract does not replace trust, it makes it verifiable. A vendor that asks you to sign a five-page draft without changes is telling you how it intends to work.

How does the relationship with a software house change now that we program with AI?

In 2026 almost every vendor uses coding assistants. That is good: a feature that took three days now takes a day and a half, and the time saved can become a lower price or more testing. It is not automatic, though, and you should ask explicitly how it is used.

The new risk is not that the code is written by a machine. It is that nobody has really read it. A program generated at speed and delivered without review is hard to read, and taking it over costs more days than one written by hand. That is why the takeover question is worth more today than before.

Three more questions to add to the list of twelve. Who reviews the AI-produced code before it enters the repository? There must be a named person. Are the tests written by a person, or generated by the same tool that wrote the code? A test generated by the same source confirms the source's mistakes. Which of my project's data leaves for external services? Client code must not be pasted into a tool without a data processing agreement.

For the method I use to assess generated code, see the guide on how to evaluate AI-generated code, and for the broader view of how AI changes the team, the one on AI adoption in the development team.

Software house, in-house team, freelancer or architect: who do you need for which job?

The choice is not always between three software houses. Sometimes it is between a software house and another route. This is how I reason about it.

The in-house team deserves a remark, because it is the route everyone rules out for cost. A .NET development team in Italy costs a six-figure sum a year even with just three people, as I explain in the guide to the cost of a .NET development team. So it only makes sense when software is the center of your value.

In every other case a well-chosen external vendor costs less, provided you do not leave them the ownership of what they build.

There is one last case, often underestimated: the architect before the software house. Paying a senior independent two to five days to write the requirements, choose the structure and compare the quotes costs between 2,000 and 4,500 euros. That is less than 4% of a medium project, and it greatly reduces the probability of failure.

A comparison of quotes made by someone who sells nothing is the service that is requested least often and that most frequently prevents trouble.

How do you complete the selection in four weeks?

A well-made choice does not take months. It takes an order of steps, and a small investment to verify before committing.

• Week 1: write down the problem. Two pages: who uses the software, which decisions it must support, which systems already exist, what it must not do. It is not a specification, it is a story. Then choose the internal contact.
• Week 2: three vendors, one meeting. Pick three vendors of different types (an established company, a studio, an architect). Ask the twelve questions. Exclude anyone under fourteen points.
• Week 3: the paid discovery phase. Give two vendors a paid discovery phase of two to five days: process map, risks, reasoned estimate. It costs between 1,500 and 4,000 euros each. It is the only way to see how they work before choosing, and to get a quote with its assumptions written down.
• Week 4: the takeover test and the decision. Have an outsider run the script on a project already delivered by your preferred vendor. Make the call to the two references. Compare the five-year totals with the program from earlier, changing the assumptions with what you have learned.

If in the end two offers are close, pick the person. In software the vendor is a group of people, and the one you will talk to every week for a year matters more than the company name.

When do you not need any software house?

It happens often, and saying so is part of the job. Three cases.

• Your process is the standard one in your sector. A management system for your category already exists, with years of fixes. If eight rules out of ten are in its manual, buying it costs less than building, at every horizon. The reasoning is in the guide to replacing Excel with a management system.
• You do not yet know what you want. If requirements change every week because the process is not decided, an outside vendor does not solve it: it freezes the confusion into code. First you decide the process, then the tool.
• You have no contact person. A project without an internal person who decides and tests fails with any vendor. First you appoint the owner, then you look for the software house.

What would have happened in Treviso?

Back to the windows and doors. With the five-year calculation in hand, the owner would have seen that the 57,000 euros of difference between the first and the third offer became, over five years, 13,555 euros in favor of the third.

He would have seen that the deciding number was dependency on the vendor, not the price. And with the takeover test he would have known, before signing, that the code of the first offer could not be taken over by anyone else in under two months.

It is not certain he would have picked the third. He might have picked the first, with a clause putting the repository in the client's account and a paid discovery phase, paying less with less risk. What changes is that the choice would have been his, made with numbers and not with the price on the first line.

If you are choosing a software house for a project of this size, the route I recommend is a software consultancy: get in touch: one or two days to write the requirements and compare the quotes, before you commit to anyone.

If instead your problem is a system already in production, written years ago by someone who is no longer around, you will find the method in the guide to the cost of legacy software and on the page about legacy software modernization: get in touch. For timing, contract and costs of a project, see custom software development: get in touch.

In five lines. Do not compare quotes on price, compare them on the five-year total. Measure the takeover days before signing, and if they exceed twenty, ask for the repository in your account. Ask the twelve questions and score them. Buy a paid discovery phase from two vendors before choosing one. Put code ownership, orderly exit and the names of the people in the contract.