Failure mode one
A decision made too late
The deployment method, the data migration, the third-party component nobody checked the licence for. These are cheap at the start and expensive at the end, which is why assessment comes before scope.
Process at Elmhurst Enterprises
From first call to a build you can repeat.
This page describes how a desktop project runs at Elmhurst Enterprises, from the first conversation to the point where you no longer need us. It is written for the person who has to approve the spend, so it covers who does what, what you get at each stage, and where the risks usually sit.
The phases below are the shape of the work, not a rigid template. A small internal tool and a staged modernisation of a line-of-business system use the same stages at very different sizes.
Scoped conversations only — no quote before assessment
Stage one
The conversation
It starts with a call, usually thirty to forty-five minutes, where we ask what the software needs to do and who will use it. We will want to know whether anything exists already, what machines it has to run on, and how software currently reaches those machines in your organisation.
You do not need a specification to have this call. You do need a real problem and a named person who can make decisions about it. If it becomes clear in the first twenty minutes that a web application suits you better, we will say so and you will have lost half an hour.
Stage two
Assessment, when something already exists
If there is an existing application, the next step is looking at it rather than talking about it. That means running the software, reading the source where it is available, and understanding which parts the users actually depend on.
This stage frequently changes the plan. A system assumed to need a full rewrite turns out to need a targeted fix and a packaging overhaul. Occasionally it goes the other way. Either answer arrives before you have committed to a large piece of work, which is the point.
-
Dotnet target
What runtime the app needs today and what it could reasonably move to.
-
Third-party pieces
Every library the build leans on, with licence and support state read out.
-
Deployment method
How the current build actually reaches machines, not how it was intended to.
-
Reproducible build
Whether the source in the repository still assembles a working package.
-
User dependency
Which screens and workflows people genuinely use, versus which merely exist.
-
Load-bearing surfaces
The parts that other systems quietly depend on and cannot be removed first.
Stage three
Scope in writing
You get a scope document that describes what will be built, what will not be built, what we need from you, and how we will both know it works. Acceptance is described in plain terms: this report prints these totals, this form saves to that database, this installer completes on a managed machine without administrator prompts.
The scope is a fixed reference point for the project. Changes are welcome and are handled as changes, with the effect on time stated before the work starts. Nobody enjoys scope creep, including the people paying for it.
The scope document, in sections
- What will be built
- The features in plain language, in the order they will appear, with the workflows users will follow.
- What will not be built
- The things assumed but not included, named rather than left to be discovered at the end.
- What we need from you
- Access, decisions, and a named approver — spelled out so nobody has to guess on a Friday afternoon.
- How we know it works
- Acceptance written as observations a person can run, not as adjectives.
- How changes are handled
- Each requested change is priced in time before the work begins, so you decide with the figure in front of you.
Stage four
Build, in visible increments
Work proceeds in increments that you can run. For a new application that might mean a first slice that reads and writes real data through a basic interface, followed by the workflows on top. For a modernisation it usually means one process moved across at a time while the old build keeps running.
You get access to builds as they appear and a short note on what changed. If your team has developers, we work in your repository and follow your review process. If not, we keep the source where you can see it and explain what you are looking at.
If you have a dev team
Work lands in your repository, follows your review process, and keeps your commit history.
If you do not
Source stays where you can see it and each build note explains what to run and what to look for.
Stage five
Testing on real machines
A desktop app has to survive the machines it will actually meet. Testing covers the current Windows versions you support, the screen resolutions in use, and the network conditions people work under. We test the installer path on a managed device, because that is where deployment most often goes wrong.
Where the application touches printers, scanners, local files or shared drives, those get tested specifically. These are the parts that behave differently on each site and are impossible to validate from a development laptop.
Where testing actually spends its time
- Windows versions currently in support on your estate
- Covered here
- Screen resolutions actually seen on users' desks
- Covered here
- Managed-device installer path, end to end
- Covered here
- Printers, scanners, local files and shared drives — each on your site
- Covered here
- Network conditions, including slow or intermittent links
- Covered here
- A Windows build you no longer support
- Not covered
Stage six
Packaging, signing and deployment
Packaging happens alongside the build rather than at the end. MSIX is our default format for Windows applications, and it handles installation, updates and clean removal in the way managed environments expect. The package is signed, versioned and tested through whatever deployment route your organisation uses.
You get the package, the signing details and the instructions your IT team needs. If deployment runs through a management platform, we will work with whoever administers it rather than handing over a file and wishing them luck.
Package
MSIX
Default Windows packaging format we ship.
You receive
Signed & versioned
Package, signing details, and the deployment notes your IT team needs.
Deployment route
Your platform
We work with whoever administers it, not around them.
Stage seven
Handover
Handover is a written set of notes covering how to build the software, how to release it, where configuration lives, and what to do when something goes wrong. It includes the decisions we made and why, because the reasoning is usually the first thing lost when a project changes hands.
If you want your team to take it from there, they can. If you want a support arrangement, that is a separate conversation with its own terms. Both are normal outcomes and the handover is written the same way either way.
How to build it
The steps that turn the source into a working package, with the tooling versions pinned.
How to release it
The signing and versioning steps, plus the deployment route it was proven against.
Where configuration lives
Every file, key and server the application expects, and what breaks if one is missing.
What to do when it breaks
The known failure modes and the order to check them, so a first responder is not guessing.
Decisions we made, and why
The reasoning behind each choice, because the reasoning is what usually goes missing first.
If you take support
A separate arrangement with its own terms — the handover is written the same way whether you take it or not.
Risks
Where projects actually go wrong
These are not hypotheticals. They are the three patterns we watch for on every engagement, and the reason assessment arrives before scope in this studio's process.
Failure mode two
A stakeholder who was never in the room
They appear at the first demo and ask for something the scope never mentioned. We ask who needs to see the work during scoping, and we mean it.
Failure mode three
A deadline set before anyone looked at the code
Which is a conversation worth having early rather than during. It is also why we will not quote a date before assessment — and why we are wary of any studio that will.
Timing, honestly
A sequence, not a stopwatch
We will not quote a delivery date before assessment, and we are wary of any studio that does. What we can give you is a sequence: what happens first, what depends on what, and which parts are waiting on decisions from your side.
What runs fast
Small internal tools often move quickly because the requirements are narrow and the users are reachable.
What runs long
Larger modernisations run in phases over months. The dependency graph, not the calendar, decides what comes next.
What actually decides it
The variable is rarely typing speed. It is how quickly decisions get made and how much of the existing system turns out to be load-bearing.
Questions before a scoping call
The five things people ask
Short answers to the questions that come up in the first call, so the call itself can start further along.
How long does a typical desktop project take?
It depends almost entirely on scope and on how quickly decisions are made on your side. A small internal tool and a phased modernisation of a line-of-business system are different kinds of project. We give a sequence after scoping rather than a date before it.
Do we need to prepare anything before the first call?
A description of the problem and a note of who uses the software now is enough to start. If an application exists, access to run it helps enormously and can come later.
Who owns the source code at the end?
Ownership is set out in the project agreement. In practice, clients receive the source and the build notes, and we write handover on the assumption that someone else may maintain it.
Can you work with our IT team on deployment?
Yes, and it usually improves the outcome. Packaging works best when we understand the management tooling and the restrictions on the machines the software will reach.
What happens if the project needs to change mid-way?
Changes are handled as changes. We describe the effect on the schedule before doing the work, so you can decide whether it is worth it rather than discovering the cost later.
Ready when you are
Send us your requirements and we will tell you what runs fast.
A short note about the software, who uses it, and what has to change is enough to open the conversation. If assessment is the right next step, we will say so. If a web application is the better answer, we will say that instead.