Before you commission an app in Mallorca: a checklist for businesses

Commissioning app development in Mallorca without locking down four or five questions usually ends the same way: a bloated quote, a scope that changes every fortnight, and an app nobody opens after launch. That is rarely a “technology” problem. It is a briefing problem.

This article is a practical checklist for businesses in Palma, the rest of Mallorca, Ibiza and Menorca that are considering an app (for customers, for the team, or both). It does not replace a discovery meeting. It does stop you arriving at that meeting with a vague wish.

A hypothetical example: seasonal delivery operations

Picture a catering and office-delivery business serving Palma and Calvià. In summer the phone never stops. They want “an app” so regular clients can order, see availability and pay. In the first conversation three different products appear: an app only for VIP clients, another for delivery drivers, and another that “should also work as a public catalogue”.

None of those ideas is silly. Together they are three different projects — each more expensive than the last. The checklist below exists so you pick one and park the rest… or decide that, for now, a solid mobile website and organised WhatsApp are enough.

1. What concrete problem should the app solve (one sentence)

If it does not fit in one sentence, it is not ready to build.

Useful sentences:

• “Let regular clients place the weekly menu order without calling.”
• “Let field technicians log photos and signatures without paper.”
• “Let holiday-rental guests open the door and read instructions without calling the host at 23:00.”

Sentences that are not ready yet:

• “Digitise the business.”
• “Have a presence on mobile.”
• “Compete with the big apps.”

In the Balearics, also note whether the problem is peak season, off season, or year-round. An August-only app can be the right call; an “everything” app with no peak priority often ships half-finished in July.

2. Who uses it (and in which language)

Name the primary user. Not “everyone”.

• End customers: tourists, residents, or companies? Spanish, English, German?
• Internal team: drivers, reception, field technicians?
• Both: then you have two products (or two modes), even if they share a backend.

In Ibiza and Menorca the user mix shifts more with the season than in many inland Mallorca businesses. If the app must work in three languages in August and one in January, say so on day one: it affects design, copy, support and testing.

3. App, web, or both: a quick filter

Before assuming you need a native app in the stores, answer:

• Does the user need real push notifications (order ready, booking change, incident)?
• Do they need the camera, GPS or sensors continuously or in the background?
• Will they use it several days a week, or once a month?
• Could a well-built mobile website — or a PWA with a home-screen shortcut — cover the essentials?

If the answers point to “occasional use, no sensors, no critical push”, a mobile web experience often solves the problem with less install friction. If usage is daily, offline-heavy or tightly tied to the phone, an app makes more sense.

This is not a technology war. It is about not paying for an App Store release when the bottleneck was the process, the catalogue or messy WhatsApp. If you are also weighing an internal panel or a custom programme, look at custom software in Palma in parallel: sometimes the app is only the visible face of a system that does not exist yet.

4. Integrations you cannot improvise

List everything the app must touch. If you do not write it down, it will surface in week four as “obvious”.

• Payment gateway / POS / invoicing
• PMS or booking software (hotels, holiday rentals)
• ERP, stock or warehouse
• WhatsApp Business, email, SMS
• Google Calendar, maps, Google/Apple sign-in
• Access control, locks or IoT

In hospitality and tourism across the Balearics, integrations are often the real project. The polished screen is the visible part. The bridge to the system you already use sets the timeline and the risk.

5. First-version scope (and what stays out)

A first version is not “the full app at a discount”. It is the smallest version that already delivers measurable value.

For the hypothetical catering example, a reasonable V1 might be:

• Login for already-registered clients
• Weekly order with delivery windows
• Confirmation and a basic status

And deliberately leave out:

• Public catalogue to acquire new clients
• Driver app
• Loyalty programme
• Live chat

Parking items does not mean discarding them. It means not mixing three products into one quote.

6. Data, legal and day-to-day operations

Questions that prevent surprises:

• Who enters and maintains the data (prices, stock, slots, copy)?
• Are there sensitive personal data? Who is the controller?
• What happens if a payment fails or an order is cancelled at the last minute?
• Who handles incidents in August when the team is already stretched?

An app without an operational owner decays in weeks: stale prices, wrong hours, notifications nobody configures. In island peak season that shows up faster.

7. Success criteria (before design)

Decide how you will know it was worth it at 30–60 days:

• Fewer calls for one specific type of request
• Fewer order / delivery errors
• Average time to resolve an incident
• Real usage: active users, not only downloads

Without a metric, every demo “looks fine” and no iteration decision is clear.

How to use this checklist in the first meeting

Bring in writing:

1. The problem sentence
2. Primary user and languages
3. Why an app (and not only a website)
4. Mandatory integrations
5. What is in V1 and what is not
6. Who maintains the data
7. How you will measure success

With that, a mobile app development team in Mallorca can talk about real scope, risks and phases — in Palma, across the island, or for operations that also touch Ibiza and Menorca — without improvising on a generic “we want an app”.

CTA

If you are at that stage and want to pressure-test the checklist against a realistic scope, email derek@dereksolutions.com or call +34 680 283 973. We can help you decide whether an app, a website or custom software is the right next step before you invest in the wrong version.