Across the first 18 months the project stopped twice and spent 397 days in standstill. First the full scope did not fit the budget. Then the key specialist was taken by another employer.
A third start only made sense with a different plan, because the old one had already failed twice. We cut the agreed scope from 3,393 hours to 667 and put one testable question first: produce a drawing a factory can cut glass from.
Snapshot
| End-client sector | manufacture and installation of glass structures |
| End client | under the code-name Glass Configurator, Russia |
| Engagement | direct contract; after the restart, work inside the client’s team |
| Task | restart a stalled build by cutting the scope |
| Before | 397 days of standstill, no working version |
| After | first version handed over for pilot use 69 days after the restart |
| Verification | 2 external factories confirmed they could cut glass from the drawings |
| State as of 5 August 2026 | the product is usable on the templates already loaded; routine release of orders into production has not started yet |
The problem
The manufacturer wanted to replace the industry tool that had left the market with one of their own. The full estimate did not match the budget and the project stopped for 270 days. The client came back on their own, work resumed, and 52 days later it stopped again: the key specialist moved to full-time employment elsewhere. The second pause ran another 127 days.
By autumn 2024, 18 months had passed since the first conversation. 397 of those days the project stood still, and there was still no working version. The need had not gone anywhere: production still wanted a tool of its own.
Why this is hard
The main risk here is arithmetic rather than technical. Until the product ships, the money is spent and the value is zero: an unfinished build performs exactly like no build at all.
Starting a third time on the old plan was pointless, because that scope was what had halted the project twice already. What needed to change was not the pace of development but the contents of the first version. And until real use began, nobody knew for certain which feature would matter first.
How we did it
1. Found the block eating almost 79% of the estimate. It held 3 product types: shower enclosures, railings and partitions. Each needed its own geometry, its own cut-outs for hardware and its own tolerance maths. We kept the most common type. That single move released 1,440 hours out of 3,393.
2. Removed everything that did not bring the machine drawing closer. Stock control, the order funnel, roles and permissions, the admin panel, the surveyor’s calendar and the mobile version all moved to later. Every one of them was useful, and none of them answered the question the first version existed to answer: can a factory work from a file this program produces.
3. Put the most painful task first. Price calculation looked like the natural opening, but managers were already handling that in spreadsheets. The real delay came later: a standard order could not reach the shop floor without a draughtsman in AutoCAD. So the first stage was built around the manager: the program itself had to prepare a production drawing with every cut-out and hole.
4. Narrowed the scope again. Even 1 product type produced around 100 possible configurations. For the first version we kept the 4 most frequent. Adding the rest only made sense once those 4 had been through real orders.
5. Shipped an incomplete version on purpose. Some data was still hard-coded and template selection did not work yet. We put the limitations in writing, and the client agreed to go into pilot use. The next day the drawings went to 2 external factories. Both confirmed they could cut glass from them.
What the first version showed
The limitations surfaced immediately. 10 days after release, a back end with new endpoints reached the production server while the interface stayed as it was. We caught it within the hour and rolled the version back in 26 minutes. The front-end developer had a compatible build ready that same night.
Users set the priorities fast. The first 13 pieces of feedback turned into 8 tasks. In 2 weeks a raw version with hard-coded data delivered what the full estimate never could: the order of the next features, decided by real work.
Results
| Metric | Value |
|---|---|
| Standstill before the restart | 397 days: 270 + 127 |
| Agreed scope | 667 hours instead of 3,393 |
| First release | 69 days after the restart, into pilot use |
| Main hypothesis tested | 2 external factories confirmed the cutting from our drawings |
| First feedback round | 13 comments consolidated into 8 tasks |
| State as of 5 August 2026 | usable on the loaded templates; routine release into production has not started |
Before the restart the project stood still for 397 days. After the scope was cut, the first working version reached the client in 69. From there the product grew on user feedback: new structure types, PDF documents and price handling.
We are not inventing a final full stop. As of 5 August 2026 the product can be used on the templates already loaded, and routine release of orders into production has not begun.
Team
- Analyst-developer from the bureau, scope and technical leadership
- Front-end developer from the bureau, the configurator interface
- Anton Hersun, Xaver Pro, project manager
If development has been standing still for months and it is unclear where to push, send us the current state: what is done, what is left, where it stopped. We will tell you which minimum scope produces a working version and when it reaches real orders. The review is free.