APPS
DESKTOP APPS
- 5+ projects
- from 2 weeks
- Windows and macOS
Software for Windows and macOS where a browser is not enough: files and hardware, local data, access with no internet. Updates install themselves — nobody has to walk round the office.
WHO IS IT FOR?
Three situations where a browser genuinely is not enough
- .01
THE WORK INVOLVES FILES AND HARDWARE
The program has to read folders on disk, process documents in batches, print to one specific printer, work with a scanner, a till, scales or a card reader. A browser either cannot do that at all or does it through workarounds and a permission prompt for every action. The difference shows up not in the feature list but in how fast a person works: what takes five clicks and a confirmation in a browser happens at once in a program.
- .02
THE INTERNET IS NOT ALWAYS THERE
A factory floor, a warehouse, a site, a branch somewhere remote, a ship, a garage. The connection drops and the work must not — data keeps going in and travels to the shared system once the network is back. Hence a requirement no website has: the program must carry on alone and then reconcile what it accumulated with what changed on the server.
- .03
THE DATA MUST NOT LEAVE THE MACHINE
Documents, personal data, finances, engineering drawings or medical records. Company or industry rules do not allow any of it into a cloud — not even one of your own. A desktop app settles that in the architecture: processing and storage stay on the machine, and the only thing that ever leaves it is what you have explicitly allowed to be sent.
WHAT'S INCLUDED
We do not build below this line
- - Custom design, never a template.01
- - Windows and macOS.02
- - Working with files and devices.03
- - Data stored locally.04
- - Works with no internet.05
- - Automatic updates.06
- - Installer and code signing.07
- - Documentation and project handover.08
- THIS IS THE FLOOR, NOT A PACKAGE
Everything listed ships in every project — even the simplest and cheapest one. There are no stripped-down versions.
- UPDATES WITHOUT WALKING THE FLOOR
The program updates itself. Otherwise every fix turns into a tour of the offices, or an email with instructions half the people never open.
- IF A BROWSER WILL DO, WE WILL SAY SO
A desktop app costs more to build and more to keep running. On the first call we go through the job and say plainly whether it is needed here or whether a web app would be cheaper.
WHAT'S INSIDE
THE APP CONTINUES THE SYSTEM, IT DOES NOT LIVE APART
We build sites, stores and CRMs — so the app is built on the same database and the same admin panel as everything else. A product, a price, an order, a customer are entered once and look the same everywhere: on the site, in the app, in Telegram. That removes the work which usually eats a budget unnoticed: entering content twice, reconciling by hand, and chasing down the differences between storefronts. If the system already exists and is somebody else’s, we connect to it through its API.
THE FORMAT IS CHOSEN FOR THE JOB
A mobile app, a desktop program and Telegram solve different problems, and the difference in price between them is a multiple, not a margin. We are tied to none of the three, so on the first call we work out what is genuinely needed: where an app inside the messenger is enough, where the app stores are unavoidable, and where a mobile site would do the job outright. Selling you the expensive format where the cheap one would do is a bad deal for us too — projects like that do not take off, and we are the ones who end up explaining why.
IT KEEPS WORKING WHEN THE SIGNAL DROPS
A phone on the underground, a warehouse with no coverage, a site out of town, a laptop on the road. The app has to carry on alone, accumulate the changes and reconcile them with the server once the network returns — including the case where the data moved in both places meanwhile. This is not a feature bolted on at the end: it goes into the architecture from the start, or everything gets rewritten.
LAUNCH AND UPDATES ARE WORK TOO
Publishing to the App Store and Google Play, answering moderation, the signing certificate for Windows and macOS, automatic updates, a server side ready for day-one load — all on us. The accounts and the certificates are registered to you: the app has to be your property, not ours. After that it lives on our infrastructure if you want it to — monitoring, backups, and updates for the new operating system releases that arrive every year whether you asked for them or not.
CATEGORIES
Three levels of scope. Yours is the one you recognise yourself in
A PROGRAM FOR ONE JOB
WHEN IS THIS YOUR CASE?
One clear job currently done by hand or in spreadsheets: processing files, preparing documents, working with a single device, keeping local records. The whole base build: design made for you, Windows and macOS, files and devices, local storage, working with no internet, automatic updates, a signed installer. Nothing stripped out — just without the extras you do not need yet.
A WORKSTATION
WHEN IS THIS YOUR CASE?
A team uses the program and the working day depends on it: several roles with rights of their own, data exchange with your system or your site, offline work that syncs afterwards, hardware attached — scanners, tills, label printers. Plus the server side under all of it: a shared database, access split by role, figures and logs in the admin panel. Central installation across the workstations and the update policy are part of it too.
AN INDUSTRIAL SYSTEM
WHEN IS THIS YOUR CASE?
The program becomes part of a production or industry process: several kinds of hardware, large volumes of data handled on the machine, integration with accounting and internal systems, demands on resilience and on keeping data inside the perimeter. Deployment into a closed network with no internet access, a role model, an action journal, documentation and handover to your team. The logic is designed around your processes rather than bent to fit someone else’s limits.
FAQ
Answers to the most popular questions
From $5.000 for a program that does one job to $15.000 and up for a system built into a production process. The figure depends on the number of scenarios, on the hardware involved, and on whether it needs a server side and syncing between workstations. After the first call you get a plan rather than a guess: what makes up the total, and what can wait for a second stage.
A program for one job takes 2–5 weeks. A workstation for a team, 3–6 weeks. An industrial system, from 6 weeks. On top of that we set aside time for testing in real conditions: with the actual hardware, the actual volume of files and an actual loss of signal. We name the deadline before we start and we hold to it.
The test is simple. If the program has to read and write files on disk, talk to hardware, keep working without internet or hold the data on the machine alone, you need a desktop app. If it just shows data, forms and reports, and people are happy opening it in a browser, a web app is cheaper to build and far cheaper to maintain. We say so on the first call: selling you a desktop app where a browser would do is a bad deal for us too.
Usually yes: we build on a shared codebase, so the second platform is not a second project but an addition to the price for platform details, testing and signing. If every workstation runs Windows, the second platform can wait — the architecture allows it to be added later without a rewrite. What you actually need is settled before the estimate.
On its own. The app checks for a new version and installs it with no input from the user — otherwise every fix turns into a walk round the workstations. For closed networks with no internet we update from an internal server or ship a deployment package. The update policy — enforced or with the user’s consent — is configured to your rules.
Without a signature Windows and macOS warn that the program comes from an unknown developer, and some security software simply blocks it. The signature is a certificate issued to your company: it clears the warnings and confirms that you released the program. It is registered to you and you pay the annual certificate fee directly. Setting it up and signing the builds are on us.
It depends on the hardware. With the standard kind — printers, scanners, tills, readers, scales — we work through the normal interfaces and the manufacturer’s drivers. Anything unusual needs a protocol or documentation from the manufacturer: if it exists we connect it; if it does not, we say so during discovery rather than halfway through the build. We always ask for exact models before estimating.
Yes, and it is the usual arrangement: the program runs on the machine while the data goes to a shared system, yours or ours. If we built the site and the admin panel too, the link is direct with no intermediate exports. If the system is somebody else’s, we connect through its API. We think through what happens when the connection is down separately: the data piles up locally and travels once the network is back.
You do. The sources, the rights and the documentation are handed over with the project — this is not a subscription and not a tie to us. The signing certificate is issued to your company and the installers go out under your name. If you ever decide to change contractor, the project leaves with you: we write it so another developer can pick it up.
Desktop programs need upkeep over the long run: Windows and macOS move on, security requirements change, certificates and hardware drivers go out of date. We ship updates and extend the program as the process itself changes. The server side, where there is one, can stay on our infrastructure — monitoring, backups, updates.