Custom software for businesses in the Balearics: what should belong to you when the project ends

When a company commissions custom software in the Balearics, most of the conversation is about what the system will do: the screens, the workflows, the timeline. Far less attention goes to a question that only comes up on handover day: what, exactly, do you own?

It sounds like a legal footnote, but it is a practical issue. If you ever want to switch providers, hire an in-house developer or simply know where your data lives, the answer depends on what was left in your name. This guide walks through each piece that should be under your control when a custom software project wraps up, whether your business is in Mallorca, Ibiza, Menorca or Formentera, and how to check it without being technical.

Why this matters more than it seems

Custom software is not just a set of screens. Underneath there are several layers, each living somewhere different:

• The source code, usually in a repository such as GitLab or GitHub.
• The server or cloud account where it runs.
• The database holding your business information.
• The domain and certificates that make it reachable online.
• Third-party services: email delivery, payments, maps, messaging, AI.
• The documentation explaining how it all fits together.

If any of these sits in the provider's name rather than yours, you depend on them, even if the contract says the software is yours. It doesn't take bad intentions for this to hurt; it only takes a provider closing down, changing focus or being slow to reply in the middle of peak season.

A hypothetical example

Picture a pool maintenance company with crews in Mallorca and Ibiza. It commissions an internal app to plan routes, log each visit with photos and email the customer a service report. The project goes well and the team uses it every day.

Two years later they want to add invoicing, and they find that:

• The code repository is in the developer's personal account.
• The server is paid with the provider's card and the company has no login.
• The email delivery service is registered to the provider's address.
• Nobody ever wrote down how to deploy a new version.

None of this stops the app working today. But every change, and every incident, has to go through one person. It's entirely avoidable if it's checked at handover.

The checklist: what should be in your name

1. Code repository

The code should live in an account or organisation owned by your company, with the provider invited as a collaborator, not the other way round. If the relationship ends, you just revoke their access.

Make sure you can log in with your own user and see the change history, not just a zipped copy of the code.

2. Server and cloud

The hosting or cloud account should be in the company's name, with the company's payment method. Your developer can have technical access, but you should be able to log in, see invoices and grant access to someone else if needed.

3. Database and backups

Ask three specific questions:

• Where are backups stored?
• How often are they taken?
• Has anyone actually restored one?

A backup that has never been restored is an assumption, not a guarantee. Also make sure you can export your data in a standard format, such as spreadsheets or CSV, without needing the developer.

4. Domain and DNS

The domain should be registered to the company, using an email address you control. It's one of the easiest pieces to lose and one of the hardest to get back.

5. Third-party services and integrations

List every external service the software relies on: payments, email, SMS, WhatsApp, maps, AI, analytics. For each one, note whose name the account is in and who gets the bill. Ideally they all belong to the company, especially anything that handles money or customer data.

6. Minimum documentation

You don't need a hundred-page manual. A clear document covering this is enough:

• Which pieces make up the system and where each one lives.
• How to set it up in a fresh environment.
• How a new version is released.
• Which settings or keys it needs to run (without writing the keys themselves into the document).
• Who to contact if something breaks.

The real test: could another developer understand the system from that document and the code alone, without calling anyone?

How to check it without being technical

You can run a simple review in an afternoon, in this order:

1. Ask for an access list: a table with each service, its URL, whose name it's in and who has access.
2. Log in yourself to each one. If you can't, that item isn't done.
3. Look at the invoices: if the provider pays for a service, ask why and when it will be transferred.
4. Request a test restore of the database into a separate environment.
5. Check the licence: the contract should spell out your rights over the code written for you, and which parts are third-party libraries or components with their own licences.

What reasonably may not be yours

Ownership doesn't mean everything has to be exclusive. It's normal for a provider to use:

• Open-source libraries, which carry their own licences.
• In-house components reused across projects, as long as you get an indefinite licence to use them for your system.
• Internal tooling that isn't part of the final product.

What matters is that it's written down and that none of it stops you maintaining or moving the software later.

Maintenance: the other half of ownership

Owning the code doesn't help much if nobody looks after it. Before closing the project, agree on:

• Who applies security updates, and how often.
• How bugs are reported and prioritised.
• What response time you need in high season, when many Balearic businesses simply can't afford downtime.
• What happens if you end the maintenance agreement: how much notice, and what gets handed over.

How to choose a provider

If you're comparing proposals for custom software for businesses in the Balearics, these questions help separate the options:

• Do they offer to create accounts in your company's name from day one?
• Is documentation a deliverable rather than an optional extra?
• Do they clearly explain which components come from third parties?
• Is there a defined exit procedure in case the relationship ends?

A provider who answers all of this plainly is usually easier to work with day to day as well.

How we work at Derek Solutions

On our custom software development projects in Palma de Mallorca, we set things up so the repository, server, domain and external services sit in each client's name, and we hand over the documentation needed so the system doesn't depend on a single person. We work with businesses across Mallorca, Ibiza, Menorca and Formentera.

If you're planning software for your business, or want to check whether the system you already have is properly in your hands, email derek@dereksolutions.com, call +34 680 283 973 or use our contact form. We'll go through it with you, no strings attached.