The first call is free. If a web app would serve you better, we will tell you that instead of selling you an installer.
Desktop software has an obstacle web apps never face: it has to get onto someone's machine, past the operating system, and then stay current there. A team that only builds for the browser tends to discover this in the last week of the project, which is the worst possible time.
Unsigned builds get a scary warning on Windows and are effectively blocked on macOS. Most people never click past it.
Not signedNo update channel, so a fix only reaches whoever revisits the download page. You end up supporting all of them at once.
Version driftHeavy processing on the interface thread. On the test file it was instant. On the customer's 900MB file the window stops responding.
BlockingEverything in one file on one machine, no backup, no export and no migration path. One failed drive and the work is gone.
Data lossOn the web, you fix it and refresh.
On the desktop, the fix has to reach every machine you shipped to.
So signing, installers, update channels and background processing are part of the build from the beginning. They are not polish at the end, they are what makes the software usable at all.
Plenty of things people ask us to build for the desktop would be better as a web application, and we would rather say that on the first call than halfway through. The dividing line is simple: does the software need the machine it runs on, or just a screen?
Sometimes the answer is both: a web application for everyone, plus a desktop companion for the people doing the heavy work. If that is the right shape for your product, we will lay it out on the call and tell you which half to build first. Our web development work covers the other side.
An installer your users can run, an app that behaves like it belongs on their operating system, and a release process that gets fixes to them without anyone having to ask.
Software that feels native on each platform, not ported to it.
InterfaceThe reason it is a desktop app in the first place.
LocalOptional, but usually where the value compounds.
ConnectedEverything between a finished build and a working install.
ReleaseInstallers exist from early on, not from the last week. If you cannot install it, you cannot really tell us whether it works.
What the software does, which machines it runs on, what hardware and files it touches, and whether IT has a say in what gets installed.
Framework choice, the local data model, the threading model for heavy work, and how updates will reach users. Decided together, because they constrain each other.
A signed build you can actually install on your own machines within the first couple of weeks, so signing and packaging are proven while they are still easy to fix.
Each feature built and packaged across all target platforms before the next begins, so nothing accumulates a Linux-shaped surprise for the end.
Testing on the OS versions your users actually run, with files at their real size, plus a restore drill and an upgrade test from the previous version.
Signed installers, a live update channel, crash reporting, and the documentation your team needs to cut the next release without us.
The framework follows the workload. Interface-heavy tools, tight memory budgets and native integrations all point in different directions, and we explain which one your product is.
NoCubical is a small, senior studio. The engineers on your call are the ones writing the software, and they have been through code signing, notarisation and update channels enough times to plan for them.
Hands-on experience per engineer, across agencies, product companies and enterprises. No juniors learning on your budget.
Small by design. The person answering your questions in week one is still reachable in month six.
Software we released and then kept updating across OS versions, which is where you learn what actually breaks. See how we work.
The repository and the signing certificates are registered to your company. No build step only we can run, and no release that depends on us being available.
We will sign a mutual Non-Disclosure Agreement any time you want one, at no cost. You can read the exact document we use before you ask for it.
Desktop when the software needs the machine: large local files, connected hardware, serial or USB devices, heavy processing, or genuine full offline operation. Web when people need to reach it from anywhere and share it easily. If a web app would serve you better we will say so on the first call, because a desktop app nobody wants to install is an expensive way to solve a browser problem.
Yes. Unsigned desktop software triggers a warning on Windows and is effectively blocked on macOS, and most people will not click past it. We set up the certificates, sign every build, run Apple notarisation, and wire it into the release pipeline so the signing happens automatically rather than being something someone remembers to do.
Through a built-in auto-update channel: the app checks for a new version, downloads it in the background and applies it on the next restart. Without that, a fix only reaches the people who happen to visit your download page, and you end up supporting every version you ever released at the same time.
Yes for the great majority of the work, with a genuinely platform-specific layer for the parts that differ: file dialogs, menus, notifications, drivers, installers and signing. What one codebase does not remove is the need to test on all three, because the differences that matter are usually in exactly those edges.
Yes, and it is often the reason a desktop app is the right answer. Serial and USB devices, scanners, printers, scales, cameras, instruments, local databases, network shares and on-premise servers are all reachable from a desktop process in a way a browser tab is not allowed to be.
No. We design offline-first when that is what you need: everything stored locally, fully usable with no connection, and syncing when a network appears. That is a real requirement for field work, secure sites, factory floors and anywhere the connection cannot be relied on.