Custom software for my business in Palma de Mallorca: what happens from the first call to your team's first day using it

Most business owners don't search for "bespoke software development". They type what's actually on their mind, something like "custom software for my business", and add "Palma de Mallorca" because they want someone local. Behind that search there's usually the same story: a spreadsheet that has outgrown itself, paper job sheets that go missing, a WhatsApp group doing the job of a management system, and the feeling that the business has grown faster than its tools.

What hardly anyone explains is what happens after that search. What will you be asked for? When do you see something working? Which decisions are yours, and which ones you shouldn't have to make at all? This article walks through the whole journey, stage by stage, using a hypothetical example to keep things concrete.

Our example

Picture a pool maintenance company based in Palma with customers all over Mallorca: a handful of technicians on the road, one person in the office and an owner who does a bit of everything. Today it works like this:

• Call-outs come in by phone and WhatsApp and get noted in a notebook or on whoever's phone took them.
• Each technician fills in a paper job sheet with the work done and the chemicals used.
• At the end of the month the office types the sheets into a spreadsheet to invoice. There's always one missing.

The owner wants "a program". Here's what that means in practice.

Stage 1: the first conversation

Your part: describe how you work today, honestly. The most useful thing you can bring is an ordinary day told start to finish: who takes the call, where it's written down, who assigns it, how the job is closed and how it gets billed.

Our part: ask a lot of questions and propose very little. It's far too early to talk about technologies or screens.

Red flag: if someone gives you a fixed price on the first call without understanding your process, they're quoting for a generic program, not yours.

Stage 2: mapping the process and finding what hurts most

Before any code is written, the current process gets drawn out, with the spots where time or money leaks marked clearly. For the pool company, the map would probably show three:

1. Call-outs that get lost because nobody logs them in a shared place.
2. Job sheets that arrive late or incomplete, so invoices go out late.
3. Chemicals and parts that never get billed because nobody records them.

Your decision: which of those costs you the most. The first version doesn't need to fix everything; it needs to fix one thing properly. That's often what separates software people actually use from software that gets quietly abandoned.

What you walk away with: a short document covering the current process, the proposed one and what is (and isn't) in version one. It's yours to keep even if you decide not to go ahead.

Stage 3: seeing the software before it exists

Once the scope is clear, we build clickable mock-ups you can try on a phone or laptop. They don't do anything yet, but they answer very specific questions:

• Can a technician close a job one-handed, on a driveway, with August sun on the screen?
• Can the office see at a glance which call-outs are still unassigned?
• Does the job sheet capture exactly what you need to invoice?

Your part: put them in front of the people who'll use them every day, not just yourself. A technician will spot a pointless button or a missing field in two minutes.

Stage 4: building in small deliveries

This is where real development starts, and the sensible way to do it is in small pieces you can test, rather than one big reveal at the end. For the pool company, the order might be:

1. Logging call-outs and assigning them to technicians.
2. A mobile job sheet with photos and materials used.
3. Exporting completed work for invoicing, or connecting to the invoicing tool you already use.

Your part: test each delivery with real cases and flag what doesn't fit. The sooner you say it, the cheaper it is to change.

Our part: show you each delivery working, not a progress report. If all you're getting is percentages, ask what you can try today.

Stage 5: going live, the most underestimated step

New software doesn't save time on day one. First you need to:

• Move the data that matters: customers, addresses, installed equipment. You rarely need ten years of history; active records are often enough.
• Pick the right moment: for a pool company in Mallorca, switching systems in July is asking for trouble. Go live in the quiet months so the team is comfortable before the busy season.
• Run both systems briefly: so if something goes wrong, nobody is left not knowing which villa to drive to.
• Keep training short and practical: one hands-on session per role (technicians, office, management) beats a long manual.

Stage 6: after launch

The first weeks of real use always surface tweaks that nobody caught in testing. That's normal, and it should be planned for. From there the software can grow step by step: a customer portal showing visit history, automatic service reminders or, later on, AI automation to sort the call-outs that arrive on WhatsApp.

Get this in writing: who owns the code and the data, how backups work, what maintenance covers and what's billed separately.

Three decisions only you can make

A good technical team takes plenty of decisions off your plate, but these stay with you:

1. Which problem comes first. Nobody knows better than you where the business loses money.
2. Who will really use it. If the technicians or the office don't adopt it, it doesn't matter how well it's built.
3. What's left out. Saying "later" is what gets version one delivered on time.

Technical choices (language, database, hosting) should be explained to you in plain terms, but you shouldn't have to make them blind.

How to tell whether the project is on track

Good signs:

• You see something working regularly and can try it yourself.
• Conversations are about your process, not about technology.
• You hear "no" to features that don't add value, even when you're the one asking.

Warning signs:

• Weeks go by with nothing to try.
• The scope grows at every meeting and nobody writes it down.
• It's unclear who will own the code when it's finished.

What if your business is in Ibiza or Menorca?

The process is the same. Much of the work can happen remotely through video calls and deliveries you test from your own office, while the key sessions, process mapping and go-live, can be planned in person. On any of the Balearic Islands, what matters is working with people who understand the season, the workload peaks and how business gets done here.

Shall we talk about your software?

If you're thinking about custom software for your business in Palma de Mallorca or anywhere in the Balearics, the first step costs nothing: tell us what an ordinary day looks like in your business and we'll tell you which problem we'd tackle first, and whether you really need something bespoke. See how we work on our custom software development in Palma de Mallorca page, or get in touch directly at derek@dereksolutions.com or +34 680 283 973.