When I worked on the PrestaShop experts directory, we had three months to deliver it. Three developers took part in the project, and the work went on until the last day. Today, looking at the same scope and the tools I use, I estimate I could do it alone in a month.
I come back to this project because it shows well how my work has changed. I know its scope and I remember what we spent our time on. So I can compare specific tasks with how I would approach them now.
A simple directory, a lot of work underneath
The PrestaShop experts directory is a catalogue of certified agencies. A store owner browses their profiles, checks their specialisations and references, and then contacts the chosen contractor. Agencies manage their profiles and take care of how they present themselves against the competition.
From a visitor’s point of view the principle is simple. When building it, though, every stage needs attention: data entry, validation, search and presentation of results. A filter selected on the page must match the parameters in the URL and the database query. A form should accept valid data and catch invalid data. Everything has to work across different language versions.
On top of that comes the admin panel. The directory’s users never see it, but building it took as much work as the public part. These are the tasks that filled week after week for us: necessary, often repetitive, and each one requiring code to be written and checked.
Three people also meant time spent on collaboration
Splitting the tasks let us work in parallel, but it required daily coordination. We waited for code reviews, agreed on solutions and merged changes made in different parts of the application. In the schedule this collaboration looked smaller than it later turned out to be in practice.
That is why three months of work by three people is much more than just writing features. That time also included everything needed to turn separate pieces into one working application.
What the work would look like today
Over recent months I have built myself a set of tools based on language models. I hand a large part of repetitive programming work over to them. For a directory like this I would start by describing the data structure and the rules of operation, and then use that to create the application skeleton, migrations and the admin panel.
These are tasks where today I think in days rather than weeks. The same goes for forms, validation and language versions: a shared description lets me generate related pieces that previously had to be written separately. My job then is to check whether the result matches the assumptions. Places where the solution departs from the typical pattern need particular attention.
The place of testing in the whole process has changed too. Tests used to be left until the end, if there was time, and there rarely was. Now they are written together with the code. I can move straight on to review without waiting for a second developer to finish their task.
Hence my estimate: one month of solo work instead of nine person-months. A large part of that earlier effort went into activities that tools now handle. Working alone also removes the time needed to coordinate three people.
What I account for in that month
I would still need to talk to the people who will use the directory. To agree what an agency profile contains, who can edit it and how search works. The country filter is a good example. Should it indicate where the agency is based, or the market it serves? Both options can be programmed. The choice depends on how a store owner looks for a contractor.
A model can suggest an answer, but without knowing users’ needs it is easy to make a wrong assumption. Writing code faster doesn’t relieve me of making that decision.
In the estimated month I also include reading and checking the generated code. It needs at least as much attention as code written by hand. A solution that looks finished can lull you into a false sense of security, and I am still the one responsible for how it works.
What this comparison says about project pricing
That month is my assessment of a specific project that I know. It shows how much the contractor’s way of working matters to the cost of an implementation. For years we mainly counted the time developers needed to write a solution. Today, for repetitive tasks, that effort can be much smaller.
If you are commissioning a similar panel, ask the contractor to explain what they will spend the quoted time on. How do they use AI? How much work do they plan for defining requirements, and how much for checking the result? You will learn more from that conversation than from the number of hours alone.
This comparison also led me to take a broader look at my profession and how implementations are billed. I write about it in the article AI is changing our world.