With an inherited system, most of the first few weeks is not development but understanding. Here is where that time goes, and how to halve it.
When we take over an existing system, clients are often surprised by the first monthly invoice. "It was just moving a button." True, but first you have to understand what happens behind that button.
Where does the time go?
With an unfamiliar codebase, the first weeks break down roughly like this:
Setting up a local environment: often the slowest part, because the system has only ever run on one specific server.
Understanding the business logic: what the system does, and why it does it that way.
Mapping the risks: what can be touched, and what will bring everything down.
Only then comes the actual development.
In the first few weeks, it is common for understanding the system to take more time than the actual development. That is not waste, it is the cheapest insurance available: change an old system without understanding it and sooner or later you break something that had quietly worked for months.
How can it be reduced?
Give access to everything, at once
Access arriving piece by piece stops the work again and again. A well-prepared bundle at the start of the project can save a week.
Tell us what actually hurts
The technical description matters less than what is not working for you. "Putting the month-end report together takes two days" carries more information than a feature list.
Allow a discovery phase
Starting with a fixed-price, bounded audit is cheaper than starting development and meeting the surprises along the way. You end up with a state assessment and a prioritised plan, which stays useful even if you continue with someone else.
Do not make the most important task the first one
Start with something small that produces a visible result. That way you find out whether the deployment process works before touching the critical part running in production.
How long is realistic?
In our experience, mapping a mid-sized, undocumented Laravel application often takes one to two weeks. With documentation and a working test suite it drops to a few days. Without version control it grows, because the first thing we do is introduce it.
The good news is that this is a one-off cost. From the second month, development speed depends on the state of the system, not on whether we know it.
