Why would a company have an app built?
Almost always for one reason: data that today travels on paper and is typed in hours or days later. An app records it where the event happens. It is not worth it when the process is standard, when it is not yet stable, or when it adds work for the people using it.
The business apps we are talking about here are not for customers: they are for the people who work. A field engineer in a plant, a driver on a delivery round, an operator in front of a line.
1. Data goes in where the event happens
This is the real reason, and on its own it justifies almost every project we do.
Today the service report, the signed delivery note, the quality check and the meter reading travel on paper and get typed in later. Hours or days pass between the moment something happens and the moment it enters the system — and in those hours data gets lost, misremembered or changed.
The gain is not the technology: it is that at month end the numbers exist.
2. People in the field stop waiting for the office
Whoever is out there works on the latest version of the information, and what they record is visible immediately to the people inside. Two phone calls out of three disappear, and with them the transcription error.
3. The processes that live in one person’s head
Every company has a process that works because Giulia knows how to do it. When Giulia is on holiday the process slows down; when she changes job, it is lost.
Putting it into an application is not only automation: it forces somebody to write it down, which is the part nobody ever finds time for.
4. Control, when you have to prove it
Traceability, maintenance, safety checks: if an auditor or a customer asks who did what and when, an application answers in a minute. With paper you go to the archive.
For anyone working in food, medical, or with customers who run audits, that is not an advantage: it is a requirement.
5. The code is yours
A custom application changes when the process changes, not when a vendor decides. Source, documentation, signing keys and accounts stay with whoever paid for the work.
And the three reasons not to
The process is standard. Expenses, time tracking, document signing: there are products that cost a fraction and work better, because thousands of companies have already tested them.
The process is not yet stable. Digitising something you are still deciding how to do means writing a temporary decision into code, and paying for it twice.
Nobody will use it. If the application adds work for the people who have to use it instead of removing it, it will be worked around. That is why we design by watching the shift, not the specification: a button too small for a glove is enough to sink the project.
The question to ask before starting
Not “which app do we need”, but: which piece of data arrives late today, or does not arrive at all?
If you can answer that, the scope of the first project is already written — and it is usually smaller than you thought.
Tell us about it, or read our method.