bruvora logoBruvora

Desktop App Development

We Build Desktop Apps for the Jobs a Browser Can't Do.

Windows, Mac, and Linux apps for heavy data, no internet, connected hardware, and data that can't leave the building. We also replace old VB6, Access, and Delphi systems one stage at a time, so the business keeps running while we do it.

Available for new projects

Who This Is For

If one of these is you, keep reading.

Manufacturers and Labs

Workstations pulling data off instruments over serial and USB.

Businesses Running a 15-to-25-Year-Old App

VB6, Access, or Delphi. It runs the business, and the person who built it is gone.

Regulated Firms

Healthcare, finance, legal, and defence, where the data has to stay local or the machine can't be on a network at all.

Media, Engineering, GIS, and Analytics Teams

Big local files and heavy processing a browser can't handle.

Software Vendors

Selling a desktop product that has to work the same on Windows, Mac, and Linux.

Why Build for Desktop

You go desktop when the web can't do the job. These are the six reasons it can't.

It Needs the Whole Machine

Video, 3D, simulation, and crunching big data need all the processor, graphics card, and memory the computer has. A browser only gets a slice.

It Has to Work Without Internet

Labs, field sites, and locked-down environments where the connection is missing, unreliable, or not allowed.

It Talks to Hardware

Instruments on serial and USB, scanners, label printers, cameras, and parts of the operating system a web page can't reach.

The Data Can't Leave the Building

Regulated buyers who don't want their data in anyone's cloud. It stays on the workstation.

The Old App Is at the End of Its Life

VB6 is no longer supported. Access databases stop at 2 GB and corrupt when several people use them at once. The person who built it has left.

Something Forces Your Hand

An operating system going out of support, a vendor shutting down, or the one person who understands it retiring. Half of IT professionals say the old system still working is the main reason it hasn't been replaced.

What Makes Desktop Hard

Problems web teams never run into.

Moving Off the Old App

COM and ActiveX controls with no modern replacement, business rules nobody wrote down, pieces nobody owns, and no tests.

Signing and Notarisation

Mac won't run an app unless it's signed, notarised, and stapled. Windows needs a trusted certificate or SmartScreen blocks the install.

Auto-Updates

Every platform updates differently, and a misconfigured update quietly fails. People end up stuck on old versions without knowing.

Working Offline and Syncing Later

The copy on the machine is the real one, every change gets tracked, and there's a rule for what happens when two machines edit the same record.

Drivers and Native Code

Talking to hardware means code compiled separately for each operating system and each version of the runtime, with security trade-offs at every step.

Getting It Onto Every Machine

Installers for each platform, app stores, and management tools like Intune and Jamf, each with its own rules. One wrong setting and the install fails on the customer's machine, not yours.

Desktop in Numbers

Why most desktop work is replacing something, and why it can't wait.

62%

of organisations still rely on legacy software.

80%

of US federal IT spend goes to keeping existing systems running.

30%

of desktops were still on Windows 10 a year after support ended.

Sources: Saritasa, Legacy Software Modernization Survey (2025) · US GAO, GAO-25-107795 (2025) · StatCounter, Windows Version Market Share

Where Desktop Projects Go Wrong

Five failures we've seen in other people's apps, and built ours to avoid.

A Web Bug Takes Over the Whole Machine

Electron apps shipped with the wrong security settings let any injected script read and write files on the computer. There are published vulnerabilities for exactly this.

Notarised, Still Blocked

Permissions that don't match what's bundled inside the app pass on your Mac and fail on the customer's. Gatekeeper says no and the customer rings you.

Looks Different on Every OS

Frameworks that borrow the system's built-in browser inherit its quirks. What works on Mac breaks on Windows.

The Converter Output Nobody Can Maintain

Automatic VB6 conversion keeps all the tangled logic and shared state. You've put the rewrite off, not avoided it.

Access Hits the Ceiling

At 2 GB, or with too many people in it at once, the back end corrupts. The migration you were planning becomes an emergency.

How We Build It

We sort out how the app ships before we build the app.

Check Desktop Is the Right Call

We confirm you need it for speed, offline use, hardware, or compliance. If a web app would serve you better, we'll tell you.

Pick the Framework for Your Situation

Electron when it has to look the same everywhere. Tauri when you want a small install and low memory. Native or .NET when it has to go deep into the operating system or your team already knows it.

Assess the Old App, Replace It in Stages

We list what it depends on, where the data lives, and the rules nobody wrote down. Then old and new run side by side until you're ready to switch.

Safe Settings from Day One

Locked-down web content, limited access to the machine, and a signed update channel in the very first build.

Signing, Updates, and Installers Early

The release pipeline gets built at the start, so the first beta installs and updates cleanly on every operating system.

Works Without Internet

The machine's copy is the real one. Changes sync when there's a connection, and there are rules for each field so two machines don't overwrite each other.

What we build with

  • Electron
  • Tauri
  • Rust
  • TypeScript
  • React
  • .NET
  • SQLite
  • PostgreSQL
  • code signing and notarisation
  • auto-update

Built the same way: Receivables · Banyan · Egis · Lift

Why We Replace It a Piece at a Time

A year-long rewrite with one cut-over day is how a business ends up running two broken systems. We ship a signed build every two weeks, and the old app stays on until each piece is proven.

A Signed Build on Your Machines in Weeks

An installer that passes Gatekeeper and SmartScreen, running on your real hardware, inside the first month. You're using it on the workstation it's for.

The People at the Workstation Steer the Roadmap

The staff who use the old app every day tell us which workflow to rebuild next. Twenty years of workarounds get designed out in the order that hurts most.

Stop at Any Point

Every two weeks you see a live demo on real hardware and make a decision: keep going, change direction, or stop. You are billed per step, so if you stop, you pay for what shipped.

Change Your Mind Cheaply

Adding a screen or a workflow costs the next step. The two decisions we fix early, because they are expensive to reverse, are the framework and the offline model.

Hardware and Shipping First

The instrument connection, signing, notarisation, installers, and auto-update get built before any screen is polished. If something is going to block the release, you find out in week two.

No Cut-Over Day

Old and new run side by side. Each workflow moves across when the people using it say it's ready, and the old app is switched off last.

How a Fixed-Price Desktop Build Runs

Short loops. A signed build on your real hardware early, then the old app replaced a piece at a time. You own the code and the certificates throughout.

Typical timeline
12-24 weeks
First signed build
Week 4
Live demo
Every 2 weeks
  1. 01

    Discovery and Fit Check

    Week 1

    A fixed-fee week. What the software does, who uses it, what hardware it touches, and whether it really needs to be desktop. You keep the findings whether or not you go ahead.

    • Fit verdict
    • Scope document
    • Fixed price for the build
  2. 02

    Look at the Old App

    Week 1-2

    For replacement work: what it depends on, where the data is, the hidden rules, and what people rely on today.

    • Dependency list
    • Hidden-rules inventory
  3. 03

    Architecture and Framework

    Week 2-3

    The runtime, how data is stored, how it syncs, and how it talks to hardware, all decided against your constraints.

    • Framework decision
    • Offline and sync model
  4. 04

    Redesign the Screens

    Week 3-5

    A 20-year-old interface carries 20 years of workarounds. We design the workflow people need now.

    • Clickable prototype
    • Staff-tested screens
  5. 05

    Build With the Real Hardware

    Week 4-18

    Tested against the actual instruments and on every operating system from the first step. A signed build every two weeks.

    • First signed build, week 4
    • New build every 2 weeks
    • Live demo every 2 weeks
  6. 06

    Release Pipeline

    Week 4-6

    Signing, notarisation, installers, and auto-update set up and tested at the start, so every build from then on installs cleanly.

    • Installers per OS
    • Auto-update channel
  7. 07

    Switch Over in Stages, Then Support

    Week 16-24, then ongoing

    The old app keeps running alongside the new one, you move across in steps, then we agree an update schedule. On a monthly retainer, or handed to your own team with the pipeline.

What It Costs

1Discovery week

Fixed fee

Ends with a scope document and a fixed price for the build. Yours whether or not you go ahead.

  • Scope document
  • Fixed price
2The build

$35k - $180k

A single-purpose tool for one platform sits at the low end. Three operating systems, hardware, offline sync, and a staged replacement of an old system push it toward the top.

Billed
Per 2-week step
Stop
At any point
Price moves
Only if scope does

Electron, Tauri, or Native

It depends on what you're up against.

Electron

Brings its own browser along, so the app looks the same on every machine. The price is a bigger download and more memory. Pick it when consistency and speed of build matter most.

Tauri

Uses the browser already on the machine, so the download is small and memory use is low. The price is small differences between operating systems. Pick it when size matters and the screens are fairly standard.

Native or .NET

The deepest access to the operating system and the best performance, but each platform costs more. Pick it when you already have a native team or the hardware connection is the whole product.

Common Questions

If yours isn’t here, book a call and ask.

Running Something That Needs Replacing?

Tell us what it does, what it talks to, and what happens if it stops, on the call. If it's a fit, a one-week discovery follows, and at the end of it you know whether desktop is the right answer, and have a staged plan with a fixed price.