How to Choose a Tech Vendor Without Going Broke (and Without Hiring a Body Shop)

68% of outsourced software projects in Spain end up costing more than double the original budget. Not because the technology fails, but because the company picked a vendor looking at a single variable: the hourly rate. It is like choosing a surgeon based on who charges the least per minute in the operating room. Sounds logical on paper. In practice it is an expensive way to go broke.

We have been watching the same pattern for years. A company needs to digitize a process, requests three quotes, picks the cheapest, and eighteen months later they have a half-working system, a vendor that has rotated the team twice, and a bill that comfortably exceeds the "expensive" quote they rejected at the start.

The problem is not that there are no good vendors in Spain. There are. The problem is that the selection process most companies use is designed to pick badly.

The Spanish software market: three categories nobody explains to you

When a company looks for a tech vendor in Spain, they find a market that looks homogeneous from the outside but operates in very different ways on the inside. There are three operating models, and understanding them changes the conversation entirely.

The body shops. These are companies that basically rent out bodies. They have a CV database, an aggressive sales department, and a margin that comes from the gap between what they charge you per hour and what they pay the developer. The developer did not choose to be on your project. They were assigned because they were available. If a better-paying project shows up tomorrow, they get moved and you get a replacement. Your project is a line in a utilization spreadsheet. These companies do not sell results. They sell hours. And the more hours you need, the better they do. Think about that for a moment.

The software factories. One step above. Here you get more or less stable teams, project methodology, and a delivery manager doing follow-up. They quote a fixed project with a defined scope. The problem is the ownership model: they build the software to whatever specifications you give them, hand it over, and leave. If the specifications were wrong, the software is wrong. If the business changes six months later, the software does not change with it. It is a transactional model. It works for projects with stable, well-defined requirements. It does not work for almost anything that involves the reality of a company in motion.

The product partners. This is the least common model and the hardest to find. These are companies that commit to the business outcome, not just the technical delivery. They understand your operation, participate in defining what needs to be built, and take responsibility for the software delivering the expected impact. They do not sell you hours or fixed-scope projects. They sell you integrated technology execution capacity embedded in your company. They build assets that remain client property. At SAUCO we call this the FDE approach, and it is the reason the company exists.

Most procurement processes do not distinguish between these three models. They throw all three into the same comparison, ask for an hourly rate, and pick. It is like comparing a taxi, a bus, and a rally co-driver using only cost per kilometer.

The hourly-rate trap and why your CFO should hate it

Let us run the numbers. It is the only thing that works to dismantle this trap.

Say you need to build an order management system integrated with your ERP. You request quotes from two vendors.

Vendor A: offers a team of three low-experience profiles at €32/hour each. Estimate: 6 months. Estimated cost: 3 people × €32/h × 160 h/month × 6 months = €92,160.

Vendor B: offers a senior full-stack team at an average of €72/hour. Estimate: 3.5 months. Estimated cost: €72,800.

The CFO looks at the hourly rate and sees 32 versus 72 on average. Picks A. Obviously.

Except no. Because Vendor A's profiles need supervision they do not have. Two months in, the data architecture has to be rebuilt because nobody accounted for concurrency. At four months they rotate one of the three because "they need them on another project." The replacement takes three weeks to get up to speed. The project stretches to nine months. A fourth resource gets added to "speed things up." The real cost ends up at €148,000 and the system ships with defects that require another €20,000 in fixes during the first year.

Vendor B delivered in four months, slightly over estimate. Final cost: €83,200. Stable system. No rework.

Real difference: €84,800. In favor of the "expensive" vendor.

What surprises me most when I see this is that it is not an extreme case. It is the average case. Standish Group data has been showing for decades that projects with higher seniority on the team have significantly higher success rates. Yet the procurement process keeps optimizing for the wrong variable.

The hourly rate measures input cost. It does not measure output value. Your company does not need to buy programming hours. It needs to buy the ability to solve business problems with technology.

Seven questions your current vendor does not want you to ask

If you are evaluating vendors right now, or if you want to audit the one you already have, these seven questions separate those who build assets from those who bill time. We have put together a full guide on selection criteria with more detail, but these are the ones that make people the most uncomfortable.

1. Can I talk to the technical team that will work on my project before signing? If the answer is "we have not assigned the team yet," run. It means your project is a slot in a resource calendar, not a technical decision.

2. Who owns the source code from day one? Not at the end of the project. Not when the last invoice is paid. From the first commit. If the contract says otherwise, you are funding an asset that does not belong to you.

3. What is the actual experience level of the proposed team? Not what the CV says. What is verifiable. Ask for specific profiles with years of experience on projects comparable to yours. A team where only one person has real experience surrounded by people who are still learning is not a senior team — it is training subsidized by your invoice.

4. What happens after the project is delivered? This question reveals more than any other. If the answer is "we sign a separate maintenance contract," the vendor does not take responsibility for what they build beyond delivery. Software does not end when it is deployed. It begins.

5. Can you give me three references from projects similar to mine where I can talk to the client directly? Not testimonials on the website. Real calls with real people who can confirm scope, timeline, and outcome. If they cannot or will not, you already have your answer.

6. How do you manage knowledge when someone on the team leaves? Turnover in the Spanish tech sector is high. A good vendor has documentation, pair programming, code reviews, and processes that minimize the impact. A bad one tells you "don't worry, that won't happen."

7. Have you said no to a project in the last six months? A vendor that accepts everything has no judgment. Good ones say no when the project does not fit their capacity or their model. The ones that say yes to everything are selling bodies, not solutions.

The inflated portfolio: how to spot ghost projects

You open a vendor's website and see logos of well-known companies. Telefónica. Repsol. Inditex. Impressive. Until you find out that their contribution to that project was placing one developer for two months inside a 40-person team managed by another company.

This is more common than it seems. Body shops, by definition, place people on other companies' projects. Every project where they place someone becomes a "success story" in their portfolio. Technically they are not lying. They participated. But the difference between "we participated in the digital transformation project at [big company]" and "we led and delivered the complete system" is the difference between being an extra in a movie and being the director.

There are signals that give away inflated portfolios.

No technical detail. If the project description talks about "digital transformation" and "innovative solutions" but does not mention a single technology, a single outcome metric, or a single concrete challenge they solved, they probably did not solve anything concrete.

Logos without context. Showing a multinational's logo without explaining what exactly they did, with how many people, and for how long is marketing, not a portfolio.

Projects you cannot verify. Ask to speak with someone at the client. If the vendor makes excuses, the project either did not happen the way they describe it or the client was not happy.

The same project described three different ways. I have seen it: a single engagement appears on the website as "platform development," in the commercial proposal as "strategic consulting," and on LinkedIn as "end-to-end transformation." Three portfolio lines that are actually one, and a modest one at that.

A real portfolio has projects with names, numbers, and consequences. "We built the picking system for warehouse X. We reduced order preparation time from 12 minutes to 4. Five-month project with a specialized team." That is verifiable. The rest is smoke.

As we documented in Low-Code Is Technical Debt with a Pretty UI, what matters in software is what remains when the vendor leaves. If what remains is a working asset that belongs to you, they chose well. If what remains is a dependency you cannot cut, they chose badly.

Why "Forward Deployed" changes the equation

Everything above describes a broken market. The FDE model exists precisely because that market was not solving the real problem.

The idea behind The Birth of the FDE is simple: instead of the client specifying what they need and the vendor building it remotely, the engineer integrates into the client's operation. They see the problem firsthand. They understand the real constraints, not the ones someone wrote in a requirements document three months ago.

The engineer is responsible for the outcome, not the delivery. At a body shop, success is measured in billable hours. At a factory, in features delivered. In the FDE model, success is measured in operational impact. Is the warehouse processing more orders? Is the sales team closing faster? Does the process that used to take two days now take twenty minutes? If not, the work is not done, regardless of how many lines of code have been written.

There is no "requirements gathering" separate from building. The FDE observes, prototypes, validates with real users, and adjusts. The cycle between "understanding the problem" and "delivering the solution" compresses from months to days. Requirements are not collected in a meeting; they are discovered in the trenches.

The code is yours from minute one. Everything is built in the client's repositories, with standard technologies, documented so any team can continue it. If the client wants to drop us tomorrow and build an internal team, they can do it without rewriting anything.

At SAUCO we apply this model because we have seen from the inside what happens with the others. We have picked up projects abandoned halfway by body shops. We have migrated systems delivered by factories that the client could not maintain. And in every case, the cost of fixing was higher than the cost of doing it right from the start.

It is not the easiest model to sell. It requires engineers who can talk to a director of operations and also write production code. It requires saying no to projects where they just need a warm body in a seat. But it is the model that generates real assets for the client and relationships that last years, not months.

Are you evaluating vendors or want to understand better how the FDE model works? Check our full guide on selection criteria for a structured comparison, or read our manifesto to understand why we built SAUCO this way.