Read the old system first. All of it.
Before writing Bookli I analysed two large booking applications and researched what the market needed. Why it was the best-spent part of the budget.
When a client says “our old system is awful, let’s build a new one”, it is tempting to start from a blank page. That is almost always a mistake.
A legacy system is a record of decisions
Every odd form field, every exception in the code and every manual workaround is a trace of a real problem someone once solved. There is rarely any documentation, but there is code. Before Bookli I analysed two large applications, a sailing school’s and a riding centre’s, and researched what the market needed.
What I found
- Rules nobody mentioned in meetings: sibling discounts, staff exceptions, specific instalment deadlines.
- Things nobody used: whole modules that could safely be left out.
- Security holes: things that had to be fixed, not migrated.
The rule
Keep the behaviour that works, throw away the implementation. The client is not paying for new code. They are paying for a season that runs better than the last one, without losing anything they relied on.
Reading old code is not glamorous and does not demo well. But it is the only way to make a new system better than the old one from day one, rather than merely newer.