Skip to content

Custom applications

Mobile and web applications built around the way you work. When no tool on the market fits, the alternative isn't to change your process: it's to build the tool.

A worker in a high-visibility vest checks a tablet next to the pallet racking of a logistics warehouse

You've asked for quotes for an app and everyone has said yes. We start with a different question: are you sure it needs building? Custom software is expensive to make, expensive to keep running and only understood by whoever wrote it. When your process is the same as everyone else's, the off-the-shelf tool wins. When your process is exactly what sets you apart, no tool will do. This service is for the second case.

Are you sure it doesn't already exist?

We start by ruling things out. If what you need is invoicing, booking appointments, running an ordinary warehouse or filing job sheets, that already exists. And an off-the-shelf tool has three advantages a custom build won't give you: it costs less, people other than you have already tested it, and when a bug appears its maker fixes it while you sleep. We earn more by building. Even so, we'll tell you to buy it, because a project that shouldn't have happened ends badly for both sides: you pay for maintenance you didn't want and we keep alive something nobody opens.

When is it worth building?

In three situations. First: the process is your advantage. You do something in a way your competitors find hard to copy, and squeezing it into an off-the-shelf program forces you to do it like everyone else. Second: the cost is in the seams. Not in each program on its own, but in the person acting as the bridge, copying from one screen to another. If connecting what you already have fixes that, it's systems integration and it costs less; if what's missing is the piece that should sit in the middle and nobody sells it, it has to be written. Third: your case simply isn't catered for. It happens in narrow sectors such as customs, haulage or agriculture, where nobody has built what you need.

Do you really need an app in the store?

When you ask for an app you usually picture an icon on a phone. Sometimes that's right: if your people work without signal, or need the camera, GPS or notifications that arrive with the phone locked, it has to be a native app. But another question comes first: will anyone install it? A customer who buys from you twice a year won't download anything. There, a website that works well on a phone, or a conversation over messaging, reaches further, because that's where people already are: 94.7% of Spain's population used instant messaging, against an EU average of 82.3%. Your own team is different: what gets used every day does get installed.

Source: Eurostat, use of instant messaging in Spain (2025)

You start with one piece, and you see it before it's coded

We never start with the whole system. We pick the piece that repeats most often in your day and build that, even if it looks small next to what you had in mind. You feel the difference sooner and it tells you early on whether this is heading the right way. And before writing code, the prototype: clickable screens, with your data and your names, so you can say "there's a field missing here" while changing it means moving a box, not rewriting half the app. This isn't just for big companies: 54.4% of Spanish companies have no employees at all, and there, custom work only pays off if it starts small.

Source: INE (Spanish National Statistics Institute), Central Business Directory (DIRCE) as at 1 January 2025

The code is yours and the exit plan is written at the start

The code is written in your repository, under your account, from day one. We don't hand it over at the end like someone returning a deposit. The same goes for whatever needs contracting underneath, the server, the database or outgoing email: the accounts are in your name and you pay for them. The exit plan is agreed at the start, while we're still on good terms: where the code is, how it's deployed and what another team needs to pick it up and carry on. Ask everyone who sends you a proposal, not just us. If someone won't put it in writing before starting, ask yourself why.

Custom software is never finished: it's maintained

Nothing ends the day it goes live. Apple and Google change the rules of their stores and operating systems, and an app nobody touches stops installing on its own. The libraries it's built with publish security patches that need applying. Your business changes and the case nobody mentioned turns up. And the law moves: if your app issues invoices, mandatory business-to-business e-invoicing has already been published in Spain's Official State Gazette (BOE), and your software has to keep up. That's why the quote has two parts, building and keeping it running, and we show you both before you sign. Tell us about your case and we'll tell you whether we can do it, how we'd approach it and what it would cost. If it isn't for us, we'll tell you that too.

Source: BOE (Spanish Official State Gazette), Royal Decree 238/2026 on e-invoicing

Frequently asked questions

How do I know whether mine is standard or really doesn't exist?
Look at what you've tried. If you've seen several programs and they all do what you need under another name, yours is standard: buy it. If they all fail at the same point, because the piece of data your business depends on doesn't fit in any field, there's something that hasn't been built. If you're unsure, that's what the audit is for.
Is the code really mine?
Yes. It's written in your repository from day one, and the accounts for any services that need contracting are in your name. If tomorrow you decide to carry on with another team, they take the code and the documentation, without asking our permission or paying a ransom for them.
How long until it's ready?
We won't give you a date before we know what's inside, and be wary of anyone who gives you one on the first call. What we do give you is the order: first the prototype you can click through, then the piece that repeats most in your day, and from there you decide, having seen the previous step working.
Do I need to have everything decided before we start?
No, and if you think you have, the prototype will probably prove otherwise. What is needed is someone on your side who can make decisions and has a little time to look at what we show them. The project that stalls isn't the difficult one: it's the one where nobody replies.

How we work

  1. 01

    Understand

    We sit down with you and look at how you really work. We come away knowing what makes sense to build and, above all, what doesn't.

  2. 02

    Build

    We build it on the tools you already use and show it to you working, not in a slide deck.

  3. 03

    Stay with you

    We measure, we adjust and you can always reach us. Software isn't something you install and forget.

Other services