You are here


15 August, 11:40, Palma de Mallorca. A ferry delay holds a technician at the port. In Ibiza, three cleans collide because the system marks one “done” that has not started. In Menorca, warehouse stock does not match what the field team is asking for. Nobody sabotaged the SaaS on purpose: peak season exposed it. This article does not start with the perfect brief. It starts from the August crisis and rewinds the calendar: what should have survived 90 days earlier, what must not fail at peak, and what you review in the 30 days after.

If you operate in the Balearic Islands —or sell to teams who do— custom SaaS software development is not judged by a May demo. It is judged by the August Monday when volume, languages and the ferry collide. This reverse calendar has a concrete job: know what to build (and what not to) so the product survives high season without emergency spreadsheets.

Three windows on the calendar

Treat the year as three windows that feed each other. If you only stare at the peak, you arrive late. If you only prepare in winter, you skip the post-mortem. In Palma de Mallorca, Ibiza and Menorca the dates shift; the logic does not.

90 days before

This is the design-and-hardening window. You are not adding pretty features: you are closing debt that becomes an incident in August.

  • Capacity and queues: clear limits per island/site; what happens when Ibiza saturates and Palma still has slack.
  • Season data: check-in/out calendars, suppliers with ferry lead times, temporary surge roles.
  • Controlled failure: what degrades gracefully (notifications, reports) vs what is sacred (assignment, critical stock, shift close).
  • Realistic load rehearsal: not “a thousand fake users”, but last year’s worst-week pattern.

Peak

Here the SaaS must survive, not impress. The UI can be austere; operations cannot invent parallel truths.

  • Single states: a task cannot be “done” on WhatsApp and “pending” on the board.
  • Multi-island visibility: Palma sees Ibiza and Menorca queues without mixing inventory or permissions.
  • Human escalation: who takes over when automation falls short —without rewriting the process by hand.
  • Documented degraded mode: if an integration drops, the team knows what to log and what not to promise guests or clients.

30 days after

The window almost nobody schedules. Skip it and next August repeats the same fire.

  • Data-backed post-mortem: queue peaks, assignment times, incidents per island —not only vibes.
  • Prioritised debt: three changes that would have avoided ~80% of the pain —not a 40-item wishlist.
  • Next year’s calendar: rehearsal dates, feature freeze and temporary-hire windows.

If you are still choosing buy vs adapt vs build, the cold filter in buy, adapt or build when custom SaaS pays belongs before this 90-day window: a season calendar only matters once you know the product is yours (or will be).

Peak-season availability contract

In multi-island ops, “the site is up” is not enough. You need an availability contract the business understands —even if you are not signing a hyperscale SLA. Treat it as explicit expectations between product, ops and leadership.

Useful availability: the critical flow (create → assign → complete → bill/close) responds in peak hours, not only the homepage. If login works and assignment does not, the SaaS is down for the business.

Latency by island: in Ibiza in August, a few extra seconds on “assign clean” multiply across hundreds of shifts. Set different thresholds for reads (lists) and writes (state changes). Palma HQ must not “feel fine” while Menorca works blind on half-synced data.

Maintenance window: never the bridge-weekend Friday and never 14–16 August. Freeze risky deploys; allow hotfixes with rollback only. If your custom software partner in Palma does not propose a freeze calendar, ask for one.

Season support: one channel, clear severities, and an island owner on extended hours. SaaS does not replace that human contract: it makes it operable (who is on call, what is P1).

Non-negotiable integrations: PMS, payments, messaging or ERP —short list. Each with a written plan B. Everything else can wait until September.

Deep case: multi-island operations SaaS

Picture a fictional property and hospitality operator —call it MedOps— headquartered in Palma de Mallorca, with a surge team in Ibiza from June to September and a lean cell in Menorca. They do not sell “software”: they sell on-time turnovers, cleans that do not collide, and stock that does not vanish between ferries.

In May, MedOps had a pretty board: task calendar, check-out photos, internal chat. On 12 August, the board lied. A ferry delay left two technicians at the port while the system showed them “en route” in Ibiza. Three cleans overlapped because “started” could be tapped on mobile with no geofence and no supervisor confirm. In Menorca, the warehouse showed 12 welcome kits; the van held 4 —nobody closed consumption in the same flow as the task.

The redesign was not “more screens”. It was a state contract plus a season calendar:

  • 90 days before: unified states (pending → assigned → in progress → blocked → done → verified). Removed the “mark done” shortcut without photo or minimum checklist on critical typologies.
  • Peak: per-island queues with visible capacity; if Ibiza saturates, the system may suggest diverting only remote-capable work to Palma —never physical inventory. Degraded mode: if chat dies, the task still lives on the board.
  • 30 days after: measured mean assignment time per island, % reopened tasks and days over queue threshold. Froze new features until three debts closed: stock sync, close permissions and ferry/supplier alerts.

MedOps did not need an add-on marketplace. It needed the operations core to survive August. That is what separates useful custom SaaS from a spreadsheet with a login —including when the mobile front leans on solid delivery in Mallorca and local presence for Ibiza web and apps alongside Menorca ops.

Survival scorecard (8 yes/no questions)

Answer cold. Every “no” is work for the 90-day window —not a slide for investors.

  1. Can you name the critical flow that, if it fails on 15 August, stops the business (one sentence, no slides)?
  2. Do you have single states per task/order —with no parallel “truth” in WhatsApp or Excel?
  3. Are capacity and queues visible per island (Palma / Ibiza / Menorca) without mixing stock or permissions?
  4. Is there a written degraded mode for the integration you most fear losing at peak?
  5. Is there a deploy freeze and a hotfix owner on the high-season calendar?
  6. Can a temporary hire operate on day 1 with limited roles —without admin access “because there is no time”?
  7. Do you measure at least two operational metrics at peak (e.g. assignment time and % reopened), not only uptime?
  8. Do you schedule a post-mortem within 30 days after, with owners and debt dates —before winter feature planning?

6–8 yes: harden, do not reinvent. 3–5: prioritise state and capacity debt. 0–2: peak will audit you; a honest brief now helps —the one-page brief format still works, even though this post’s angle is the calendar, not the quote.

FAQ

Does this calendar only apply to tourism and vacation rentals?
No. Any strongly seasonal Balearic operation —logistics, group F&B, maintenance, retail— hits the same pattern: prepare, peak, learn. The critical flow changes; the need for windows does not.

Do you need AI to survive August?
Not necessarily. AI helps once states are clean and queue data exists. If truth lives in chats, fix the system first —then automate. If the bottleneck is chat-to-board, the WhatsApp → system bottleneck map complements this calendar.

What do we freeze at peak: features or integrations?
Freeze risky features and schema changes. Keep hotfix capacity for non-negotiable integrations. The classic mistake is shipping “the big improvement” on 10 August because it is “almost ready”.

How much time for the 90-day window?
Enough for a load rehearsal with your real pattern and to close the debt that kills the critical flow. If 90 days are not enough, shrink the peak you promise —do not fake capacity.

Next step

If you operate from Palma de Mallorca or coordinate Ibiza and Menorca, send us your worst peak-week scenario (what broke, which island, what you invented by hand). No product pitch: we look at what your custom SaaS must survive and what belongs in the prep window. Email derek@dereksolutions.com · +34 680 283 973. You can also review our web design in Mallorca and online marketing in Mallorca when product and acquisition move together —but August is won in operations, not on the landing page.

Contact us now!