From Web App to Offline First Desktop App

Who Was the Client?

Young Enterprise Solutions built Bidderize, a tool that helps procurement teams choose between competing suppliers.

When a company runs a bidding process — inviting several suppliers to quote on the same order and comparing their prices — that comparison is usually done by hand in spreadsheets, across multiple rounds of quotes and different discount structures. It's slow, and easy to get wrong.

Bidderize replaces that manual process with software: it runs the comparison automatically and shows the buyer, in numbers, which supplier actually saves them the most.

What Was the Client's Request for Collaboration?

The client already had a working web app — React frontend, Python backend — with the core bid-analysis logic built and tested.

They wanted it turned into a desktop application for Windows and Mac that runs fully offline, with the backend packaged and executed locally on the user's own machine instead of a hosted, public backend. The backend logic itself could not be rewritten.

What Was the Client's Bigger Business Goal?

Procurement teams handle sensitive supplier pricing and contract data, and Bidderize's core pitch is that none of it has to leave the buyer's device. The business goal was to:

• • Back that privacy pitch with an architecture that actually keeps data off the network

• • Give procurement departments a concrete reason to choose Bidderize over spreadsheets or cloud-based tools

• • Position Bidderize as a local-first alternative in a market built around sensitive data

At What Stage Was the Client's Project?

What the client had:

• • A working web app with React frontend and Python backend

• • Core business logic already built: baseline upload, multi-round supplier bids, discount modeling, scenario comparison, supplier feedback generation

• • A validated product concept — the web version was already functional and in use

What was missing:

• • No desktop build for Windows or Mac

• • No way to run the Python backend locally on a user's device — it was built to run as a server

• • No automated tests, which made it risky to touch the backend logic at all

• • No Electron wrapper or desktop packaging pipeline

What Was the Expected Outcome?

• • A desktop app for Windows and Mac with the same functionality as the web version

• • The app runs fully offline, with no internet connection required

• • The Python backend packaged and executed locally on the user's device

• • No rewrite of the backend's existing business logic

How Was the Result Measured?

Technical validation:

• • Test coverage: an automated suite of ~100 Playwright tests built against the existing web app's logic before any backend changes

• • Parity testing: the same test suite run against the desktop build to confirm web and desktop behaved identically

• • Client acceptance: the client tested the finished build directly before sign-off

This was a migration engagement, not a new product launch — the client's web app already had users, so success was defined by the desktop build matching that existing behavior exactly, verified through automated tests rather than adoption or revenue metrics.

How Did the Collaboration Work?

We opened by agreeing scope with the client and mapping out a sequence: write automated tests against the existing web app, migrate the code to Electron, then validate the desktop build against that same suite. That wasn't part of the original ask, so we explained why it mattered before adding it to the plan.

Execution followed that order across the ten-week engagement — day-to-day questions ran through WhatsApp, progress lived in Trello, and the client had visibility the whole way. They tested the finished build themselves before signing off.

The backend couldn't run offline on the user's machine

The Python backend was built to run as a server, not as something bundled into a desktop app. Packaging it to run locally, with no internet connection, is a different problem than deploying it to a host — and Windows and Mac handle bundled Python binaries differently from each other.

Solution: We packaged the backend into local binaries for each OS and wired the Electron app to launch and talk to it locally, so the app runs the same way whether it's on Windows or Mac.

There was no test coverage to protect the port

The app had zero automated tests, so there was no way to confirm the port hadn't changed behavior — a real risk given how much procurement teams depend on getting the numbers right.

Solution: Before porting anything, we wrote an automated test suite (Playwright, ~100 tests) against the existing web app's logic, then ran the same suite against the desktop build to confirm both versions behaved identically.