Custom app development

What custom app development is, and when it is worth it

An application is not a website with an icon on your phone. It is software: it has users who sign in with an account, roles that decide who sees what, states that change through the day and consequences when something goes wrong. A website shows what you do; an application makes it happen. And whatever makes things happen has to be programmed, tested and watched as such.

It is worth it when the process already exists and lives scattered across places that cannot hold it: a spreadsheet only one person understands, a notebook by the bar, a WhatsApp group where alerts get lost, three tools that don't talk to each other and somebody typing the same data twice. The application does not invent a new way of working: it writes yours down and enforces it.

And it is not always worth it, which is the part almost nobody tells you before invoicing. If what you need is to show your services and get calls, that is a website and we will say so. If an off-the-shelf tool genuinely fits your case, we will tell you which one even though we don't build it. Custom development is justified when the standard option forces you to change the way you work to fit inside what somebody else decided.

The proof is not a portfolio: it is Qomanda, our own software running in production

The usual way to talk about app development is to show screenshots of other people's projects. We would rather show you ours. Qomanda is a restaurant booking management platform we built at Alture. It is deployed and running at app.qomanda.es, and we operate it ourselves: payments, alerts, updates, incidents and the automated watchdog that tells us before the client does.

It is two applications over the same data. Inside, the back-office for the floor team: the day view with the service list, the live floor plan and the timeline; the floor plan editor with its zones, tables and levels; the guest CRM with allergens, tags and history; the analytics; the team roles. Outside, a booking engine the restaurant embeds in its own website, in twelve languages with automatic detection and with its own logo and colour.

It is written in Next.js and React on TypeScript, with Postgres on Supabase, deployed on Vercel and using Stripe for payments. It sells at €49 a month per restaurant, with the price published and no per-guest commission, with a thirty-day trial and no card required. None of that is a mock-up: they are decisions we have had to defend in front of a client and then hold up in production, which is where you find out whether they were the right ones.

And now the part that rarely appears on a services page. Qomanda proves we can build and operate a software product, not that we have won a market: traction is shown with customer numbers, and those get published when they exist, not before. What we bring today is the product running, the code written and the decisions behind it. Judge us on that.

An application is not judged the day it ships: it is judged the day something breaks. That is why the proof we show is our own, and we operate it ourselves.

The app your customers book, order or buy through

This is the layer used by someone who does not work with you: the person booking a table, requesting an appointment, placing an order, checking their file or buying. They have never seen your software, they are not going to read instructions and they are most likely arriving on a phone with one hand busy. If they hesitate twice, they leave. That is why this side is designed the opposite way to the internal one: fewer options, fewer steps and no word only your team understands.

The Qomanda engine is exactly that. It embeds in the restaurant's own website rather than a third-party portal; it detects the browser language among twelve; it takes on the logo, the colour and even a transparent background so there is no visible seam with the rest of the page; it lets the restaurant choose which fields to ask for and add its own questions; and it confirms, reminds and thanks by email without anyone having to remember to do it.

Behind that sits a decision that goes beyond design: whoever books there is the restaurant's customer, not an intermediary's. The name, the phone number and the history stay in its database, and so does the relationship. When the app your customers buy through is yours, you stop renting access to your own people.

The software that runs the machinery: plant, floor and warehouse

The other use is the one nobody sees from outside: the software that moves your operation from within. Work orders, production runs, shift control, batch traceability, preventive maintenance, stock in and out, touch terminals on the floor, a code scanned in passing. Aesthetics don't rule here: what rules is that somebody wearing gloves and in a hurry does in two taps what today takes a paper form that somebody else types up later.

And here we have to be plain, because it is the house rule: today we do not have a factory to show you. If you are looking for someone to boast about twenty industrial plants, that is not us, and we would rather you knew before the meeting. What we do have is the complete machinery of a real business, built and running, which is the same problem with different scenery.

In Qomanda, on top of the bookings, the module that runs the service is programmed: ordering straight from the floor plan, the full-screen touch terminal, the real-time kitchen display with colour alerts based on how long each dish is taking, the recipe costing with its yield loss, stock deducted at the exact moment of payment, purchase notes with weighted average cost, the consumption and variance report and the cash-up. That is production control, inventory and traceability: swap “table 7” for “line 2” and the problem is identical.

The part with legal consequences was designed as a document, not as a screen: gapless sequential numbering per series, chained with a signature, in a table a trigger prevents anyone from modifying, and a cash close that freezes its totals so no sale can fall between two closes. Reprinting reads the frozen figures; it never recalculates. When a record has to survive an inspection, looking right is not enough.

That module, by the way, is not open to every Qomanda account: we enable it case by case, with a permission only we can grant. A point-of-sale terminal is not switched on with a click and left alone, and saying so costs us sales and saves us trouble.

Integrity is solved in the database, not on the screen

In any real application there comes a moment when two people do the same thing at the same time. Two guests booking the last table, two sales reps committing the same stock, two operators closing the same job. If checking and writing are two separate steps, sooner or later both go through the same gap and nobody finds out until somebody is standing there waiting.

In Qomanda we solved it where it has to be solved: inside the database. Booking is not two calls in a row, it is a function that takes a lock per restaurant and date, checks the sitting capacity and the free table and writes, all inside the same transaction. On top of that a trigger rejects any table overlap even if the booking arrives by another route, and an equivalent function handles reassigning tables from the panel.

The principle is this: the application can get it wrong — it always ends up getting it wrong — but the database will not let it. It costs more on day one and it is the reason why afterwards nobody has to explain how the same table got seated twice. That is the difference between a demo that works in the meeting and a system that holds up on Friday night.

If your app takes payments, the money goes into your account

When an application takes payments, the first question is not which gateway to use: it is whose account the money passes through. We have a fixed answer, and it is yours.

In Qomanda, no-show guarantees run through Stripe Connect with direct charges. Translated: the account belongs to the restaurant, the payment lands in its balance and Qomanda never holds funds at any point. That is not generosity, it is judgement. Standing in the middle of somebody else's money turns you into something you are not, drags you into accounting that is not yours and forces you to explain every delayed transfer you do not control.

The restaurant also chooses how it protects the service — save the card, hold an amount or charge a deposit — and the system does the rest. The same approach applies to any application that takes money: subscription, one-off payment, booking with a deposit or a cart. Your account, your money, and the gateway fee is paid to the gateway, not to us.

Roles, permissions and personal data: who sees what, and what happens to what is left over

Almost every business application stores data about people, and carelessness there is expensive. The first thing is isolation: in Qomanda every table has row-level security enabled, so one restaurant cannot see another's data even if somebody writes a query badly. It is not a check in the application code, which is where it usually lives and where it gets forgotten: it is in the database.

On top of that come per-person permissions. Five hierarchical roles — owner, manager, floor, waiter and read-only — enforced in the database too and not just in the menu, email invitations, and one small detail that prevents a big problem: a trigger stops the account from being left without an owner. When we come in to give support, it happens with a visible on-screen notice and it is logged; nobody looks inside a client's house in silence.

Personal data expires, and we programme it that way. There is a purge that anonymises the guest once the retention period passes but keeps the booking, the occupancy and the invoice: the client does not lose a single statistic, and what is no longer there cannot leak. It ships switched off and the client turns it on, because the retention period is decided by whoever answers to the data protection authority, not by their supplier.

The servers are in Frankfurt and the functions run in that same region, next to the database: the data does not cross the Atlantic and back. And exporting bookings, customers and invoices sits deliberately outside the paywall. If somebody stops paying, the service is cut off; their data is not held hostage.

An application is not maintained: it is operated. And silence is not success

Maintaining and operating are not the same thing. Maintaining is updating and fixing what breaks. Operating is finding out before the client does. Most software disasters do not announce themselves with a red error: they announce themselves with silence.

Qomanda has seven processes that run on their own — reminders, end of day, surveys, safety net, invoicing health, data expiry and a watchdog. The watchdog exists because of a specific lesson: if one of those processes stops running, because of a variable deleted in a deploy or a change of plan, nothing visibly fails. The reminders simply stop going out and the restaurant finds out through the no-shows. Now every process leaves a heartbeat and, if one goes quiet, it tells us.

In the same vein, server errors reach us by email with their fingerprint and a cap so a repeating fault does not drown us, and before calling anything done we compare what the repository says against what is actually applied to the database. Written is not deployed: that distinction came out of an audit of our own and now saves us the kind of surprise you only discover when it is too late.

We do exactly the same with your application. Evolution, monitoring and support go into a monthly retainer: we do not hand over a product and disappear. Software with nobody behind it lasts until the first change it needs, and that change always comes.

What does not work yet is labelled “Coming soon”, not given a green tick

There is one detail in Qomanda that says more about how we work than any list of technologies: when a setting does not yet govern any behaviour, it does not show a green tick. It shows “Coming soon”. There is even a design-system component built only for that.

It sounds minor and it is not. A switch that pretends to save is the fastest way to lose a team's trust: somebody turns it on, relaxes and discovers three weeks later that it never did anything. In Qomanda there are features written and not yet connected — the voice answering service, for example — and the panel says so in those words instead of pretending they are ready.

The same will happen with your application: there will be things left out of the first version and features written before they can be switched on. You will hear it from us, in the quote and on the screen itself, and not as a surprise the day you need it.

Mobile app development: native, web or PWA, and why the app store is rarely needed

“I want an app” almost always means “I want my people to have it on their phone”, and that does not require going through any app store. The first thing we decide with you is whether your project genuinely needs a native application, because the honest answer is usually no.

A well-built web application installs on the home screen, opens full screen, works the same on phone, tablet and desktop and updates itself for everyone at once. There is no store review to wait a week for, no three old versions living alongside the new one and no two separate programs doing the same job. Qomanda works that way, and its touch terminal is used on a tablet.

Native is worth it when the project genuinely demands it: heavy camera or sensor use, working without coverage, reliable push notifications on iPhone, or the store as a sales channel in itself. It costs more, it takes longer and it means going through Apple and Google, so the decision is made with the reason in front of us and not because it sounds better. What we will not do is sell you a store app so your team can open the same thing a link would give them.

The applications we build to order

Bookings, appointments and sign-ups. Availability, sittings, capacity, confirmations and automatic reminders, with our own engine embedded in your website or integrating the one you already use. It is the ground we know best because it is the one we had to solve for ourselves, down to the last odd case.

Customer portals and private areas. Each user signs in and sees theirs and only theirs: their orders, their documents, their file, their invoices. This is no longer about pages but about software with accounts, roles and states, and it is programmed, tested and documented as such.

Operations panels and dashboards. Bringing onto one screen what today lives across five tools and in two people's heads, with live data instead of yesterday's report. It lets you decide in the morning instead of reconstructing at the end of the month.

Touch terminals and field applications. Screens designed to be used standing up, in a hurry and with your hands full: taking the order, closing a job, logging a delivery into the warehouse, scanning a code. Little text, big buttons and no decision that makes anyone stop to think.

Integrations and automation between systems. Connecting by API what you already use — ERP, CRM, invoicing, gateway, email — so data is entered once and travels on its own. It is by far what gives a team back the most hours per month when it is done properly.

Your own product, when the software is the business. Multi-tenant applications with subscriptions, customer self-signup, an internal admin panel and invoicing: exactly the architecture we built for Qomanda. If your plan is to sell the software and not just use it, we have already walked that road end to end, bends included.

First versions and rescues. Validating an idea with a short version before overinvesting, or taking over an application somebody else started that is now stuck. We audit what is worth keeping and what is cheaper to rebuild, and we tell you even when the answer is uncomfortable.

How we build a custom application, phase by phase

The order is always the same: understand the real process, model the data and the states, build a short first version, put it in front of people who work with it, and operate it. No surprise phases and no line items appearing halfway through.

We start by going to see it. A process cannot be modelled from a video call: you have to see who touches what, at what moment, under what pressure, and what they do today when the system gets in the way. That is where what actually needs building comes from, and it rarely matches what is asked for in the first meeting.

Before drawing a single screen we write the states. In Qomanda a booking has fifteen: pending, confirmed, reconfirmed, under review, no card, arrived, at the bar, seated, dessert, bill requested, clearing, released, no-show, cancelled and past. That list did not come out of a creative session, it came out of watching how a dining room is run. When the states are right, the screens almost write themselves; when they are wrong, no design fixes it.

Then we launch early and small: a first version with the essentials, in front of real users, and from there decisions are made on usage instead of assumptions. Correcting a short version costs far less than correcting a big one, and it saves you months building features nobody ever opens. You sign off every phase and you always know what is being built and why.

Custom app development in Granada, Madrid and across Spain

We are a Granada team working remotely and travelling wherever it is needed: we regularly run projects for companies in Granada, Madrid, Málaga and Almería, plus clients spread across the whole of Spain. A development project runs just as well remotely as in person as long as there is a single point of contact and real meetings, and we keep that wherever you are.

The exception is the start: when the application governs a physical operation — a dining room, a warehouse, a shop floor — we go and see it before writing a line, because there are details that never come up in a meeting and do come up in ten minutes of watching. After that, what does not change is who writes your application and who you call when you need something: the same team, with no handovers halfway through.