Custom Software for an SME in Spain: Seven Questions to Answer Before You Sign

A few days ago the CEO of a clothing retailer wrote to us. They wanted an internal CRM for customers, orders, stock and suppliers, plus an app for their customers. They already had a systems technician on staff. And before asking for a meeting, they asked seven questions: what the phases would be, where it would be hosted, who maintains it, how payments work, what the contract looks like, whether there are grants, and a price range.

Those seven questions are the right ones, and they're in the right order of importance — with the price last. Most quotes answer only the last one. This guide answers all seven, with the sources I'd want to see if I were the one signing.

I'm writing from the builder's seat: I've been an engineer since the late nineties and at Conectia I sign the quotes for the teams we deploy. That's also the conflict of interest, so let me state it up front: we sell exactly this kind of project, and a spec product called Blueprint. Everything below holds whoever you hire.

The question that comes before the seven: should this be custom at all?

The strongest argument against custom software is a good one: for most small companies, off-the-shelf software is cheaper, faster and maintained by someone else. A CRM, an invoicing tool and an e-commerce platform bought as subscriptions will cover the common case, and you'll never pay for a security patch.

Custom starts to make sense in two situations. When the way you work is the advantage — the stock logic, the supplier flow, the way your shop floor and your web store share inventory — and a generic tool forces you to work like everyone else. Or when you've already stitched four subscriptions together with spreadsheets and the stitching is where the errors live. If neither is true, buy the subscription. If one is, keep reading.

Seven questions, answered in the order the invoices arrive

What are the phases of a custom software project?

Five phases, and each one should end in something you could take to another vendor:

1. Specification (one to two weeks). What gets built, the data model, the integrations, and the order. The deliverable is a document, not a slide deck. It's what our Blueprint produces in two weeks — and it's yours, whoever builds it.
2. First usable version (weeks, not months). The smallest version that does real work for real users. We build ours as a 6-week MVP; what matters is that the scope is fixed by the spec, not by the calendar.
3. Pilot. A few real users, real data, two to four weeks. This is where you find out what the spec got wrong.
4. Iterations. Short cycles, each with a visible change.
5. Handover and operation. Documentation, access and a maintenance agreement, so that your own technician — or anyone else — can pick it up.

If a vendor can't tell you what you receive at the end of each phase, you're buying hours, not a project.

Where will it be hosted, and who pays for it?

In a cloud account in your company's name, from day one: the cloud account, the domain, the code repository and the app store accounts. The vendor gets access; you keep ownership. It's the clause that decides how hard it is to change vendors later, and it costs nothing to get right at the start.

The infrastructure bill is rarely the problem. For an internal tool with a few dozen users, the monthly cloud bill in the projects I've seen runs to tens of euros, not hundreds. The fixed costs that do exist are small and public: Apple charges 99 US dollars a year to publish on the App Store and Google charges a one-off 25 dollars for Google Play. What costs money is somebody looking after it: tested backups, updates, monitoring. That belongs in the maintenance line, not in hosting.

One more point if the system stores customer data: host it in an EU region. Transfers of personal data outside the EU need the extra safeguards of Chapter V of the GDPR, and a small company doesn't need that paperwork.

How much does maintenance cost after launch?

The industry rule of thumb is 15–25 % of the build cost every year: a CRM that cost 50,000 € to build costs 7,500–12,500 € a year to keep alive. That covers security and dependency updates, operating-system releases for the app, bugs users find and small changes.

Over the whole life of the system, the build ends up being the smaller part of the bill. Robert Glass, in Facts and Fallacies of Software Engineering (2002), put maintenance at 40–80 % of the total cost of software — and noted that around 60 % of that maintenance is enhancements, not fixes. In plain terms: the software keeps changing because your business does.

Ask for maintenance as a separate, named line with response times. With a technician in-house, a hybrid model works well: the vendor handles security and major changes, your technician handles day-to-day work, and the spec and documentation make that split possible.

How should payments be structured?

By milestones tied to accepted deliverables, not by calendar dates. A reasonable pattern: a first payment when the spec is signed off, one per milestone as each version is accepted, and a final payment held back until the pilot is over. Be wary of any plan that asks for most of the money before you've seen working software.

Two facts that help the conversation. Between companies in Spain, Law 3/2004 caps payment terms at 60 calendar days, and that limit can't be extended by agreement. And the choice between fixed price and time and materials depends on the spec: a fixed price is fair when the scope is frozen in writing; time and materials is fair when you get weekly visibility of hours and progress. What doesn't work is a fixed price on a vague scope — the contingency is then paid for in change requests.

What should the contract include?

Six clauses I wouldn't sign without (and have a lawyer read the final text — this is a checklist, not legal advice):

1. Transfer of intellectual property. Under Spanish IP law, software written by an employee belongs to their employer (art. 97.4 LPI). When you commission a vendor, their employees are the ones writing it, so the rights start with the vendor, and any transfer has to spell out the forms of exploitation it covers (art. 43). Write it explicitly: exclusive transfer of exploitation rights, including modification, worldwide, for the full legal term.
2. Source code and accounts in your name, with access from the first day, not on final delivery.
3. A data processing agreement. If the vendor touches your customers' data — and a CRM does — article 28 of the GDPR requires a written contract with the processor.
4. Acceptance criteria and a warranty period during which defects are fixed at no cost.
5. Exit and handover: documentation, credentials and reasonable help if you change vendors.
6. Invoicing compliance, if the system issues invoices. Under Spain's VeriFactu rules, whoever develops the invoicing software must give you a declaration of compliance. The obligation applies from 1 January 2027 for companies that pay corporate tax and from 1 July 2027 for everyone else, after the postponement in Royal Decree-law 15/2025.

Are there grants for custom software?

Fewer than people expect, and it's better to know that before planning around one. As of September 2026:

• Kit Digital subsidises catalogued solutions — customer management among them — delivered by registered «digitalising agents», with fixed amounts per company size. It doesn't fund bespoke development as such. There's no new open call: Order TDF/39/2026 removed the programme's fixed end date and uses remaining funds mainly for applicants who were turned down when the money ran out.
• ENISA lends, it doesn't give: participatory loans from 25,000 € to 1.5 M€ for innovative SMEs, with no guarantees, but your equity must at least match the loan.
• CDTI's innovation line (LIC) starts at 175,000 € of project budget. Too big for most SME tools.
• The innovation tax credit in article 35 of the Corporate Tax Law (12 % of eligible spending) explicitly excludes adapting an existing product to a customer's requirements. A CRM that digitises how you already work rarely qualifies.

Regional programmes change every year; check your region's development agency. But budget the project as if no grant will arrive, and treat any that does as a bonus.

What price range should I expect?

I've written the full arithmetic in how much it costs to build an app in Spain. The short version: a simple product built by senior people sits at 10,000–23,000 €; a mid-complexity app from a Spanish agency, 40,000–120,000 €. A CRM with stock, orders, suppliers and a customer app sits in the upper part of the first range or the lower part of the second, depending on integrations. The fastest way to narrow it down is to write the spec: once it exists, any vendor can quote to within twenty per cent.

If you're comparing vendors, I've also put together a list of custom software development companies in Spain with the criteria I'd use to choose.

What I'd do this week, before asking anyone for a quote

1. Write down the process, not the software: who enters an order, where stock is counted, what goes wrong today and how often.
2. Check the subscriptions first. If one covers 80 % of the process, buy it and customise the remaining 20 %.
3. Commission the spec before the build, and make sure it's yours.
4. Open the cloud, domain and repository accounts in your company's name.
5. Budget maintenance as a line of its own, at 15–25 % a year.
6. Plan without the grant.

The seven questions that retailer asked are the right ones because six of them aren't about price. Answer those and the price stops being a guess. If you'd like a second opinion on your own list, talk to a CTO — we'll go through it with you, whoever ends up building it.