Custom software: business systems, web apps and mobile apps

It makes sense in two cases: when you do something off-the-shelf products do not cover, or when their rigidity costs you more than the licence saves you.

If your process is standard, a ready-made package is perfectly fine, and we will tell you so. Building makes sense when the way you work is part of your competitive edge: bending it to fit a generic program means throwing it away.

An example: you arrive with three systems that do not talk to each other and one person who spends their days copying data from one to the next. You leave with a single dashboard where that data talks to itself. That is what we did for R&W Tech: 50 welding machines that used to be blind to each other, now read from one dashboard.

The apps we build are not downloaded because they are handy: they are used because you cannot work without them. The maintenance technician in front of a stopped machine, the engineer inside a warehouse the network does not reach, the sales agent closing an order at the customer's home. The phone here is a work tool, and the app is the mobile piece of a system that already exists: management software, ERP, production data, devices in the field.

Four cases come up more often than the others. The companion app of a machine or device, which configures and controls it over Bluetooth or NFC: for Assa Abloy we rewrote the Mottura locks app without touching the hardware protocol, so the locks already installed kept working while the app changed completely. The app for field technicians, which has to work offline and sync when the network returns. The app for the sales force, with catalogue, price lists and orders that go straight into the management system instead of passing through a PDF and a phone call. And the app connected to an IoT system, which reads the sensors as the data arrives: for HCube it is a continuous Bluetooth stream from a patch sewn into sportswear, with charts scrolling in real time.

We develop iOS and Android in Flutter: one codebase for two platforms, so one thing to maintain and update at every release. Where cross-platform does not reach we go native, Kotlin and Swift: hardware protocols, Bluetooth Low Energy, NFC, system widgets, Apple Watch apps. It is a matter of arithmetic: two native apps to maintain cost twice as much, forever, and there is almost never a technical reason to justify them.

What we do not do is the consumer app to launch on the stores, the kind that lives on downloads, rankings and retention. That is a different trade, won with marketing more than architecture. If your app has to talk to your processes, your data or your devices, you are in the right place. If it has to win a million private users, you are better off looking elsewhere, and if you ask us we will say so.