Custom software in the Balearic Islands: what to ask before you order

Before ordering custom software, you should have answers to five questions: what stays from what the company already uses, where the program will run, who installs and maintains it, what the price will be compared with, and whether the project will apply for public funding. The first four apply anywhere. The fifth has a Balearic twist that changes the order of the whole project.

These are not textbook questions. They are the ones that have decided the projects we have run from Palma, with companies on the islands and on the mainland, and some of them we learned the hard way. Each case comes with its real status.

What stays from what you already use

The first conversation rarely starts with the new program. It starts with the ones already in place that don't talk to each other.

An importer in Barcelona had a sales management program it had outgrown, an accounting program that worked well and, in between, spreadsheets that arrived from each factory in its own format. Their worry was not getting a new management system. It was not losing what already worked.

The decision was a custom management system built in modules. The first one is the product catalogue, which is where most of the manual work was. The accounting program stays untouched: it keeps doing the books, and the connection to it comes in a later module. Since some people in the office have worked with the old system for decades, another condition was that the screens be very simple.

Status: contracted and in development. Not yet in production and no users yet.

The question to ask whoever builds it is: which programs do you keep using on day one, which ones do you drop, and in which module does each thing change. If the answer is "we replace everything at once", that is a lot of risk in one place. How a custom program lives alongside the accounting one is also covered in how to automate processes in a small business.

Where it will run: your network or the cloud

This question cost us a project, which is why it comes second.

A manufacturer received its customers' orders by email in every format: PDF, Excel, phone photos and handwritten sheets. We built a system that reads them and leaves each line ready for a person to review before it goes into their management program. The demo worked with real orders and their IT manager gave it technical approval.

We pitched it with what we thought was the best argument: it runs entirely on the company's own machines, without sending documents to any outside service. Management decided not to go ahead. They gave three reasons, in this order: they had cheaper proposals, they preferred the tool to run in the cloud rather than on their local network, and they had frozen investments because of market conditions.

The second reason is the one that matters here. What we sold as an advantage was, for that customer, a drawback. Nobody had asked them before the demo.

Status: built and technically validated, handwritten orders included. Not in use.

That is why it is a question for the first meeting, before designing anything:

• Where do your programs live today? On a server in the office, in a vendor's cloud, or in the company's own cloud account.
• Who pays for and runs that place? If the company already has its own cloud, the normal thing is to install there, not to add another provider.
• Is there data that must not leave the company? Sometimes there is, and then local makes sense. But the customer decides, not the builder.

Who installs it and who maintains it

A finished program is not a program in use. Between the two sits the installation, and in a small business there is almost always someone else in the conversation: the outside IT provider who looks after their machines and email.

For an accounting and employment advisory firm we built a board where every email from a shared inbox comes in as a card and moves from pending to in progress to done. Getting it running needed three things, and none of them depended on the code:

• a domain of the firm pointing to its server;
• temporary access to that server to install it;
• the mailbox credentials with IMAP and SMTP access, the two standard ways of reading and sending email from another program.

All three go through the firm's IT provider, who has the final say on how it gets installed.

Status: built and tested. Waiting to go live at the firm.

What we took from it: the outside IT provider has to be in the conversation from the start, not once the program is done. And before signing, it should be written down who does what after delivery: backups, updates, adding users and who to call when something breaks.

Finished program

Domain and server

Email access

Users set up

In use

Each arrow in that diagram depends on a different person. If it doesn't have a name before you start, the project stalls there.

What you will compare the price with

We don't publish prices, and the reason is practical: the same label ("a management system", "an order reader") covers very different projects. After the consultation we send a written proposal, with the scope split into modules.

What we have learned is what the person receiving it compares the price with. The manufacturer above had cheaper proposals on the table and saw the system as a helper tool, not as something central to the business. Read that way, comparing it with an off-the-shelf product is reasonable, and off-the-shelf wins.

Custom software pays off when the process is central and no product handles it without patches: a catalogue that arrives in each factory's own format, a way of working that sets the company apart. If an off-the-shelf product does almost everything you need and what's missing is nice but not essential, the honest thing is to say so.

Two questions for any proposal you get: which module comes first and what can you use when it's done, and who owns the code at the end. What we usually answer is in the FAQ.

Custom software in the Balearic Islands with public grants

This is where the islands differ. Some grants from the Balearic Government can pay for part of a software project, and their rules ask for documents that only the people building it can prepare.

An example with an official source: the 2026 call for tourism businesses in the Balearics, in its innovation programme, covered 50 % of the cost for SMEs and 15 % for large companies, for projects between 10,000 and 300,000 euros excluding VAT per application (CAIB, 2026). The application window closed on 30 September 2026.

What matters for any software project is not the figures but what those rules require:

• a project description with phases and a timeline, and a budget broken down by line item;
• three quotes from different suppliers when a service exceeds 15,000 euros (CAIB, 2026);
• that the work starts after the application is filed;
• that the invoice is issued to the beneficiary company, which is the one that pays;
• one application per establishment.

The third one breaks the most projects. If the work is ordered first and the grant requested later, that work no longer counts. The right order is:

Project defined

Description and itemised budget

Application filed

Order and invoices

Final report

So if a grant is a possibility, say so in the first meeting: it changes how the budget is written (by line items and phases, not a single closed figure), when work can start and who gets invoiced. Conditions change with every call, so what counts is what the current rules in the official gazette say.

Where to start

Before the first meeting with whoever will build it, have this written down:

1. The list of programs you use today, and which ones you want to keep.
2. Where they live: a server in the office, a vendor's cloud or your own cloud. And whether there is data that must not leave.
3. The name of your outside IT provider, if you have one, so they are involved from the start.
4. The process that takes the most manual work today. That is the first module.
5. Whether you will apply for a grant. If yes, nothing gets ordered before the application is filed.

With that, the consultation is for deciding something, not just for introductions. The kinds of projects we do are on the services page.