Case study · Software development
Custom software in two weeks – for a date that could not be moved
In 2015, at around 9 pm on a Saturday evening, we received an enquiry from a German airline. Custom software had to be up and running ahead of an official visit by the then German Chancellor. The previous provider could no longer meet the date, and the providers approached in Germany and Switzerland quoted four to six months of development time. Three and a half weeks remained until the date.
The figures
The timeline
The starting point
A call on a Saturday evening, a date that was fixed
Most software projects do not fail because of the technology but because of the calendar. Here the calendar was the problem: the date was the official visit of the then German Chancellor – set from outside, not by an IT department, and impossible to move. By then the software not only had to exist but had to be running – operated by people who had never seen it before.
The previous provider had pulled out. The software companies subsequently approached in Germany and Switzerland quoted development times of four to six months. There were three and a half weeks left until the date. On paper, the project was over before it had begun.
We did not say yes that evening because we program faster than others. We said yes because the scope could be narrowed down: it was a clearly defined task with a clearly defined result. That is precisely the condition under which timeframes like this are feasible at all – and the reason we turn projects down when the scope is unclear.
The assignment is covered by a non-disclosure agreement that is still in force today. It covers the content and purpose of the application: what the software did and what it was used for are therefore not on this page – and never will be.
This is not coyness; it is the same discretion you get from us. Our clients include law firms, tax advisory firms and businesses whose processes are nobody else’s business. For them, a case study in which we had given things away would not be a selling point but a warning sign.
What can be said is here: the timeframe, how it was split and the conditions under which something like this is feasible. The basis was a detailed specification, against which the software was also formally accepted – this was not a project built on verbal instructions. The project documents are held by us and support the figures in this case study. They will not be shown: they fall under the same agreement.
The process
Three and a half weeks, divided up
How the time was divided is the real core of this case study: development did not take up all of it. The bigger part of the risk lies not in the programming but in everything that comes after it.
Saturday, 9 pm: enquiry
Initial consultation that same evening. The first step was to pin down the scope – what the software had to do and what it explicitly did not.
Two weeks: development
The software was custom-built. No platform, no toolkit that fits 80 per cent – with the time available, adapting one would have cost more than building from scratch.
One and a half weeks: testing
All of the remaining time went into testing. When a date cannot be moved, software that works 95 per cent of the time is not software.
Training and handover
The client’s staff were trained. Anyone operating the system on the day has to have practised beforehand – not just read what a manual says.
On-site go-live
We supported the go-live on site. Not via remote support, not with a phone number for emergencies.
What made it work
Why three and a half weeks were enough – and when they would not be
It would be dishonest to present this as the norm. Timeframes like this work under conditions that are not always met. Here they were:
- The scope could be clearly defined. One task, one result, no open-ended wish list. When the scope grows during development, speed does not help.
- Decisions were made immediately. Each side had one contact person with the authority to decide. Questions were settled within hours, not in rounds of meetings.
- We do our own development. No subcontractor, no offshore team in another time zone. The person who wrote the source code sat at the same table as the person who took down the requirements.
- More time for testing than usual, not less. Of the three and a half weeks, one and a half went into testing. Under deadline pressure, testing is usually what gets cut – and that is exactly what leads to failure on the day.
- Conservative technical choices. Proven components rather than the newest ones. With three weeks available, an unfamiliar framework is not progress but a risk.
For comparison
What was estimated and what was needed
Frequently asked questions
What prospective clients usually ask
So what did the software actually do?
We are not allowed to say. The non-disclosure agreement covers the content and purpose of the application, it is still in force today – and we keep to it even when mentioning it would benefit us.
If you want to know whether we can solve a task like yours, describe it to us. We will then tell you what comparable things we have built – as far as we are allowed to.
Does that mean you develop any software in two weeks?
No, and we would not claim so. Two weeks were possible because the scope was clearly defined, decisions were made immediately and we did the development ourselves. If one of these conditions is missing, it takes longer – and we tell you so beforehand.
What this case study shows is not speed at any price, but what is possible when a project is tightly scoped and the lines of communication are short.
Does quality suffer when things have to move this fast?
It suffers when testing is cut short – and under deadline pressure that is usually what happens. Here, the larger part of the time window went not into development but into testing: two weeks of building, one and a half weeks of testing.
When a date cannot be moved, there is no second attempt. That is why testing time is planned in first, not last.
Why did other providers decline?
You would have to ask them. Four to six months is not an unrealistic estimate for a business application – if you assume a conventional project structure: requirements specification, tendering phase, development stages, acceptance tests. The schedule often results from the procedure rather than from the actual effort.
We narrowed the scope until it fitted into the time available – and explicitly left out the rest.
Do you still do this kind of thing?
Yes. Short-notice projects with a fixed deadline are nothing unusual for us. What we clarify beforehand is always the same: what has to be running by the date, what can follow afterwards, and who makes the decisions on your side.
If we conclude that there is not enough time, we say so – before the contract, not halfway through.
Which airline was it?
We only publish client names with explicit consent. If you have a specific interest, we are happy to put you in touch personally after consulting the client.
A note on confidentiality
For reasons of confidentiality, we only publish client names and contact persons with their explicit consent. In addition, this project is subject to a non-disclosure agreement covering the content and purpose of the application. The timings in this case study are taken from the project documents.
Related
How we develop software
Free initial consultation
A date that cannot be moved?
Tell us what has to be running by when. We will tell you whether it can be done – and if not, what could be achieved by then instead.
+49 221 984300-0Switchboard and support hotline
[email protected]Reply within 4 hours on working days
Robert-Perthel-Straße 7250739 Köln – Bilderstöckchen
Mon–Fri 9 am–6 pmEmergency support outside these hours by arrangement