estimation·ai-development·launch
Screens Were Built Fast. Why Did the Launch Estimate Stay Long?
I compared two project histories and revised an estimate by separating screen work, external connections, and changes after launch.
- PROBLEM
- I needed to check whether fast screen development with AI could support the full estimate for another project.
- DECISION
- I separated screen work, external connections, and changes after launch, then used different evidence for each.
- OUTCOME
- I recalculated the estimate. The final schedule and the actual launch result are still unconfirmed.
While estimating a project, I looked at an earlier project built quickly with AI. It had produced many screens and APIs in a short time. I thought that pace might help estimate another project of a similar size. But this time, I needed to estimate the time to live use, including the work after building screens.
I compared the fast development record with a project that had already launched. The same number of screens could describe different amounts of completed work.
How much of the fast development record could I use?
First, I counted active dates, screens, APIs, and tables from the Git history. This showed the pace of feature development. However, an active date was a date with a commit. People also worked on other tasks, so it did not prove a full day of work on this project.
The screen, API, and table rates used those same dates. Adding them as separate amounts of work would count the same time more than once. I needed to check what each number measured before using it.
The larger limit was completion. There were records of starting external connections, but none had confirmed completion. Rapid growth in screens and server code did not prove that real identity checks or payments worked.
I compared it with a project already in live use
I checked another project’s development history. It had launched and included changes made after customers began using its screens. I had been comparing the pace of adding features with the pace of changing a live service.
I did not read the difference as a simple difference in developer or AI tool performance. I used the fast admin screen record for admin screens. For changes to customer flows, I used the project that had reached live use.
I treated external connections separately. Even the fast project had no confirmed completion for those connections. Screen counts could not support a shorter estimate for that work. I needed records of earlier connection work and the outside procedures involved.
I changed the basis of the full estimate
At first, I applied the fast development record to a screen-based estimate. Then I used separate records for admin and customer screens. I added external connections, shared setup, testing, and data migration. Including work from the live project increased the estimated workload compared with using only the fast screen rate.
The result was a clearer basis for the full estimate. I could separate screen development speed from the work still needed for launch. Agreement on the final schedule and checks on external connection conditions remain open.