Internal apps, operations & inventory

In almost every company that works there is a person — let’s call her Maria — who is the system. She holds processes together with Excel, WhatsApp, copy-paste and memory. It works as long as she’s there, as long as she doesn’t make a mistake, as long as she doesn’t go on holiday. Then there’s the warehouse that says one thing and the website that says another, the technician on the road who calls to find out where he has to go, the workshop that works off a printed sheet, shifts managed in a WhatsApp group. This guide collects the articles on how to turn that operational chaos into usable internal apps: tools that take work off people instead of adding a login, without buying enterprise software that nobody will use.

The principle: 5 screens, not 50

The reason so many companies stay on Excel and WhatsApp isn’t backwardness: it’s that the spreadsheet is faster than ugly software. An ERP with a hundred forms, useless mandatory fields and three clicks to do one thing always loses against a sheet that does exactly what’s needed, immediately. If your internal tool is worse than the sheet, people go back to the sheet — and you’ve thrown the money away.

A well-made internal app starts from the opposite idea: few screens, the ones that matter, designed around how the person who will use it actually works. Five screens that save time beat fifty that waste it. The value isn’t “digitising”: it’s removing the copy-paste, making the data reliable, and making sure the people who work want to use the tool because it simplifies their day. That’s the thread that ties all the articles below.

The symptoms (and the article that addresses them)

Every company arrives at this topic from a different operational pain. The most common:

• «200 copy-pastes a day, Maria does it anyway» — the real cost of wasted admin hours, and the internal app Maria will use if it’s done well. It’s the piece that opens the guide: the cost of «Maria does it anyway».
• «The technician on the road loses two callouts a day» — the phone app that does in four taps what today gets lost between phone calls and PDFs: the field technician app.
• «Three warehouses, one e-commerce, three truths about remaining stock» — misaligned stock levels that make you sell what isn’t there, and honest availability on every channel.
• «Holidays and shifts still on WhatsApp» — the minimum HR app (request, approval, calendar, balance) without enterprise software.
• «40 identical tickets a day» — customer care with no knowledge base, and the AI that, if it has no procedure to cite, invents the refund.
• «Production orders still on paper» — job progress that the shop-floor manager and the owner can see, so sales stop over-promising.
• «Order tickets, stock and invoices in the venue» — the food cost that doesn’t add up between front of house, kitchen and accounts.

As the articles come out, you’ll find them listed at the bottom of this page.

The invisible piece: the data model

There’s a rule that holds for all these apps: if you get the data model underneath wrong, the app fails, however beautiful it is on top. If the way you represent a job, a stock level, a shift or a work order doesn’t match how the company actually works, the person hits a case that doesn’t fit, gets stuck, and goes back to the spreadsheet. The real work of an internal app isn’t the interface: it’s understanding the real process — exceptions included — and modelling it well. The interface is the part you see; the model is the part that decides whether it works.

It’s the same principle as dashboards and data products: under every screen that gets used there’s a job of definitions and structure that no “ready-made” tool does for you. And as with data, the rule holds: whoever designs the interface and whoever builds the model have to be the same head, or the app is born already detached from the real work.

Adoption: without the people, boycott

The last piece, and the most underestimated, is adoption. An internal app imposed from above, without involving the people who will use it, gets bypassed: they keep using the spreadsheet “because it’s more convenient”, and your software becomes a duplicate nobody updates. Internal apps that work are born with the people who work: you look at how they do it today, you remove the friction, and you budget for a running-in period — the famous “two weeks of hatred” after go-live, which only pass if the tool actually simplifies things.

That’s why, in every article in this guide, you find the same constants: calculating the real cost (in hours and in euros), the few screens that are actually needed, the data model underneath, the UX mistake that makes vendors fail, and maintenance — because when a company rule changes, someone has to be able to update the app without rebuilding it.

How to use this guide

Start from the article that describes your operational pain — you don’t need to read them in order. Each one includes the cost of doing nothing, typical screens, an honest timeline and the “it’s for you if / it’s not for you if” section.

When you want to see what it would look like to solve it for real in your process, the starting point is the project portfolio or two lines in contacts: we start from how you actually work, not from off-the-shelf software.

Below you’ll find all the articles in this guide.