When desktop is the right choice
Most business applications can run in the browser today, and usually they should. Desktop is the right choice where work must not stop when the connection drops, where the software runs alongside hardware, or where data has to stay local. We make that call together in the discovery call; if you don’t need desktop, we’ll recommend a web application.
Scope tiers and timelines
| Scope | What it includes | Time |
|---|---|---|
| Single-purpose tool | One flow, local data, export | 3-5 weeks |
| Offline business app | Roles, local database, sync when back online | 6-10 weeks |
| Device-integrated app | Works with printers, barcode scanners, scales and similar hardware | 6-12 weeks |
| Modernising a legacy desktop program | Migrating existing data, renewing the interface and foundations | 4-8 weeks |
Offline behaviour can’t be bolted on later
How the application behaves without a connection (which data lives on the device, how conflicts are resolved when it reconnects) has to be planned into the first version. Adding it later means rebuilding the data model.
Is desktop right for you? A quick check
Desktop is likely the right choice
- The till, warehouse or production line must keep going when the internet drops
- The software works alongside a device such as a printer, barcode scanner or scale
- Data has to stay on computers inside the company
- It will replace an old desktop program that has been in use for years
A web application may suit you better
- Users will connect from different places and different devices
- You want to give customers or suppliers access
- The app will change often and everyone needs the new version on the same day
- Connectivity isn’t a problem and there is no device to connect to
What the application does when the connection drops
Take a point-of-sale app as an example. Sales carry on without internet, each one is written to the local database on the computer, and the records go to head office once the connection returns. It sounds simple, but a few questions need clear answers at the planning stage.
- Which data lives on the computer: the full product list and prices, or only the day’s records?
- If the same item is sold at two tills while both are offline, how is stock corrected?
- How long can the connection be down: a few hours, or a few days?
- If a price changes at head office, when and how does it reach a till that is offline?
- Will users see on screen that they are offline and how many records are waiting to be sent?
Preparing for an app that works with hardware
The most common problem with device integration is not having the real device to hand during development. That’s why we ask for the make and model of your devices during discovery. If your branches use different models, listing each one early saves surprises later.
Receipt and label printers
The model and connection type (USB, network or Bluetooth) should be known up front. Receipt and label templates go into the scope too.
Barcode scanners
Most scanners behave like a keyboard and connect easily. If you need a special scanning mode, test it early.
Scales
How weight readings reach the program varies by model. We need the device’s technical documentation.
A test device
Ideally a sample device stays with the team throughout development. If not, we test remotely on your computer.
Moving from a legacy desktop program to the new version
The risk in replacing a program that has run for years lies in moving the data and the team’s habits. So we recommend a staged switch, with the old program and the new one running side by side for a while.
- 01
Review the existing program
We map the screens, reports and data structure, and note which task people do on which screen.
- 02
Trial data migration
A copy of the real data is moved into the new structure. Missing or broken records are checked with you.
- 03
Side-by-side use
A few users try the new version on real work, while the old program stays open as a fallback.
- 04
Switch-over day
The final data transfer runs and everyone moves to the new version. If you like, the old program is kept as a read-only archive.
Frequently asked questions
Desktop app or web app?
If work must continue offline, the software has to run with hardware, or data must stay local, go desktop; if none of those apply, a web application is faster to build and easier to maintain. We decide together in the discovery call.
Will it run on both Windows and macOS?
Yes, we prepare installers for both operating systems. Only where a hardware requirement is specific to one operating system is that part handled separately.
Can you rebuild our old desktop program?
Yes. The first step is reviewing the existing program and its data structure; how the data will be migrated, and how much can be kept, becomes clear after that review.
Do updates have to be installed on each computer by hand?
No. The app can check for a new version when it starts and install the update once the user agrees. If you would rather roll updates out across the company yourselves, we can plan for that instead.
Why does a security warning appear when the installer is opened?
Windows and macOS warn about installers that aren’t signed. To avoid this, the installer is digitally signed. The certificate and developer account needed for signing carry a yearly fee, and it’s best to have them in your company’s name.
Where is the data kept, and how is it backed up?
The data sits in a local database on the computer where the app is installed. During discovery we agree how often it is backed up and where a second copy is kept: a separate disk, a company server or a cloud account of your choice.