Scoping & comparison method
We scope desktop software before we build it
This is the work that happens before any code exists: understanding the problem, comparing the realistic technical routes, and writing down why one was chosen. It is the part of a desktop project that most affects the outcome — and the part most often skipped under delivery pressure.
An hour of conversation usually tells us whether the project is worth scoping properly. Everything after that is measured against constraints you can test.
Inside the studio — where the comparison gets made
Framework matrix
Comparing frameworks against your constraints
Constraints expressed as statements you can test make a framework comparison meaningful. Each option is assessed against them — not against taste. For each realistic option we record what it gives you and what it costs across deployment, native integration and cross-platform reach.
Sometimes the comparison produces an obvious answer. Often it produces a shortlist of two with a trade-off that is genuinely yours to make.
Criterion
WinUI 3
Electron / cross-platform
Deployment to a managed estate
Native installer that fits the organisation's own deployment tools; administrator rights can be avoided by design.
Ships a runtime of its own; every workstation carries it, and package size is larger than the alternative. Signing and update paths need care.
Native integration with Windows hardware
Direct access to system APIs, device drivers and the label printer path; least resistance against IT policy.
Reaches the system through a shell layer; usually adequate for printers and files, occasionally awkward for older device hardware.
Cross-platform reach at the same time
Windows only. Mac needs a second codebase, which is priced into the comparison.
One codebase across Mac and Windows; the runtime cost is the trade-off you accept to get it.
The matrix is a reading, not a ruling. When the trade-off is genuinely yours to make — a heavier runtime in exchange for one codebase, for example — that decision belongs with the people who own the software.
First conversation
Start with the problem, in your own words
What the software has to do, who uses it, what is wrong with the current arrangement. We do not need a specification at this stage — and asking for one usually produces a document that describes a solution rather than a problem.
We will ask about machines, networks, devices and IT policy, because those set the boundary of what is possible. An hour is usually enough to know whether the project is worth scoping properly.
Ref
What we ask you
Why it matters
Note
Reach
Which operating systems the software must run on
Decides the framework shortlist
Windows-only is a different project from Windows and Mac.
Estate
What machines, devices and networks are already in place
Sets the integration boundary
Includes label printers, scanners and any hardware on the shop or site floor.
Policy
What the IT department permits on a workstation
Installer choice becomes a constraint
Change freezes, admin rights and allowed runtimes all sit here and matter more than they look.
Uptime
Whether the software must work offline
Narrows the storage and sync options
A full shift without network access is a design brief, not a preference.
Care
Who maintains the software after delivery
Sizes the handover and documentation
An in-house team changes how we write and what we hand over.
Recording the trade-offs
Every project makes decisions it cannot justify on technical grounds alone
A budget limit. A deadline tied to a contract. A preference for a technology the in-house team can maintain. These are legitimate, and they should be written down.
Decision record
We keep a short decision record alongside the project: what was chosen, what it cost, and what would need to change for the choice to be revisited.
It takes minutes to write and it saves arguments a year later — particularly when the software is handed to an internal team that was not in the room when the trade-off was made.
Risk — what we flag and when
The risks worth flagging usually are not technical
They are organisational: no one available to test, a change freeze that blocks deployment, a hardware refresh that lands mid-project, an IT department that will not permit a required installer. We raise these as they appear, in writing, with a view on what happens if they are not resolved.
A risk raised early is a scheduling question. The same risk raised late is a change request. That difference is the whole reason the ledger exists.
Watch
No one available to test on the target hardware
Raised when it appears; the fix is a scheduled tester, not more code.
Watch
A change freeze that blocks deployment during the release window
Confirmed in writing with the dates; the alternative is a staged rollout around the freeze.
Watch
A hardware refresh landing in the middle of the project
Usually a configuration matrix change, not a rewrite — but it has to be known early.
Watch
IT will not permit the installer a framework needs
Discovered during scoping on purpose; the alternative installer path is priced at that point.
Watch
A dependency on a framework the vendor has shifted direction on
Named in the record with a maintenance commitment and what would trigger a revisit.
Timescales
The heavy work is not where people expect it
Desktop projects do not scale with the number of screens in the way people expect. The heavy work sits in integration, deployment and testing across the environments the software must support. Adding a form is cheap; adding a supported platform is not.
We give ranges rather than dates until the constraints are settled, and we say what would move the range. When a date is genuinely fixed, the honest conversation is about scope rather than effort.
What actually fills a desktop schedule
Integration
Talking to the printer, the device or the existing system. Tested on the real hardware, not on a colleague's laptop.
Deployment
The installer, the signing path and the update route — usually the widest part of a desktop project.
Testing
Across the environments the software must support. Every additional supported platform adds another pass.
Handover
Documentation and a walkthrough, sized against whether an in-house team is going to keep it running.
Working with an in-house team
A system is better maintained by people who will still be there next year
Some of our clients have developers and want to keep them involved. That is usually good for the project — in-house knowledge of the business is hard to buy.
We can work alongside an existing team, take a defined module, or hand over after delivery with documentation and a walkthrough. The arrangement is set out before the work begins rather than negotiated as it goes.
Alongside your team
Joint delivery, shared repository
A defined module
One piece of the system, isolated
Handover after delivery
Documentation & a walkthrough
Before committing to build
What you receive at the end of scoping
The scoping pack
A written description of the problem and its constraints, a recommended approach with the alternatives and why they were set aside, a view of the risks and their consequences, and an indication of cost and timescale.
That pack belongs to you. If it goes to another supplier, or to an internal team, or into a drawer for a year, that is a fair outcome. It is also the point at which you should be able to tell whether we are the right people to build it.