Can a 2,800-Hour Project Fit Into Six Months?

The first article in this series was about the 8x signal I had already seen in bounded software work: CRUD-heavy business applications, clear framework conventions, narrow scope, and enough experience around the process to review what the agent produced.

The second article moved up a level. A two-hour client walkthrough became a structured rebuild estimate of roughly 2,800 hours of traditional software effort. It was not a quote, and it was not a claim that AI had solved the project. It was a work breakdown detailed enough to inspect.

This article is the next step in that chain. Once the model says 2,800 hours, the practical question is whether a one-person, AI-assisted delivery system can bring that inside a six-month project without hiding half the work under enthusiasm.

The easy calculation is too blunt

Six months of full-time work is roughly 1,000 hands-on hours. Multiplying that by eight produces a large and very attractive number. It also treats every hour in the project as if it behaves like a well-bounded implementation task.

I would not plan the project that way. I am a one-person delivery system, and not all of my time is under the same kind of control.

Some time depends on the client and the working relationship we have not built yet: project management, review cycles, client clarification, decisions that need someone else's answer, and the friction of learning how a new client makes decisions. I cannot responsibly assign an 8x multiplier to that. It might compress a little because the material is better organised. It might not compress at all. In the early weeks it may even go backwards, because there is onboarding cost on both sides.

Some time is under my control, but not recurring in the same way. Infrastructure and deployments belong here. I can design the review environments, deployment path, seed data flow, and rollback habits. That work should benefit from automation and prior experience, but it is not weekly feature output. Much of it is a one-off investment near the beginning, and the estimate should treat it like setup capital rather than pretending it consumes the same amount of time every week.

Then there is work the first estimate missed. I do not think of that as a pure overhead bucket. If the missing item is an import process, a permission boundary, a data cleanup tool, or an admin screen implied by the legacy system, it is still build work. It belongs back inside the work breakdown with its own multiplier, confidence level, and risk. Missed work becomes dangerous when it stays outside the model until it appears as delay.

The allowance I considered was 12 hours a week for the parts of the project that should not be treated as straightforward feature build time. Across 26 weeks, that is 312 hours. Out of a roughly 1,000-hour six-month budget, it leaves 688 hours as the first pass for focused build work.

If the whole 2,800-hour project had to be compressed only through those 688 build hours, the average multiplier would need to be just over 4x. That is less dramatic than 8x, but still too blunt, because software projects are not made from one kind of labour.

The second multiplier is parallelism

The first 8x result came from comparing traditional effort with my direct hands-on time on bounded work. A larger AI-assisted project adds another possible source of leverage: multiple slices can move at the same time.

That does not mean four agents produce four times the output. Parallel work has coordination cost. Slices can depend on each other. A review bottleneck can move from coding to me. If two agents make incompatible assumptions, the saved implementation time comes back as merge and review time. I have already seen enough of that risk to avoid treating parallelism as free.

But it cannot be ignored either. If one slice is waiting for review, another can be generating tests. If infrastructure is stable, a separate agent can work through a well-scoped admin flow while I inspect an import path. If the work is split correctly, the calendar can compress more than the raw build-hour multiplier suggests.

That gives the model two different numbers. One multiplier describes how much faster a bounded slice can be implemented. A second, much less certain multiplier describes how many bounded slices can progress in parallel without the coordination cost eating the gain.

A work breakdown should have different multipliers

The 2,800-hour estimate was built as a work breakdown, so the delivery model should be built the same way. Not one multiplier across the top. Different categories, different compression rates, then add the parts back together.

Some work has the shape where AI agents are strongest: repeated implementation patterns inside an established framework. Entities, migrations, repositories, form types, admin screens, list views, filters, validation, fixtures, tests, and template work can move quickly when the conventions are already set. This is where the 6x to 8x range is plausible, sometimes better, provided review does not get skipped.

Feature decomposition, route design, permission modelling, acceptance criteria, and test planning sit in a slower band. AI helps because the first draft arrives faster and can be challenged earlier, but the value is in the review and correction, not in raw generation speed. I would not give that the same multiplier as generating the fourth admin CRUD flow that follows the same pattern as the previous three.

Some work barely compresses at all. Client clarification, reviewing the first usable version, deciding which legacy behaviour is intentional, finding undocumented import rules, and choosing the right boundary around a feature still take attention. AI can organise the evidence, but it does not remove the decision.

Some work can expand after the first estimate. Imports are the obvious example. A screen might show a field called "category", but the old system may contain years of inconsistent category data, missing records, duplicated terms, redirects, special cases, and format drift. The visible field is small. The data history behind it is not.

The form is the small part

A generated form is a useful example because it looks like exactly the kind of work AI should make cheap, and often does. If the entity is known, the validation is obvious, the security boundary is simple, and the UI follows an existing pattern, the implementation can be fast.

But a rebuild rarely stops at the visible form. The real work may be deciding which users can edit which records, which fields are imported from the legacy system, which fields are now owned by the new system, what happens when old data violates new validation rules, and whether changing a value should trigger other workflow state.

The code for the form can move quickly. The decisions around the form belong in a different bucket. If both are assigned the same multiplier, the estimate becomes tidier and less useful.

The model I want from here

The next pass on the 2,800-hour plan should split the work into multiplier bands rather than pretending one blanket number can describe the whole project. A rough version might look like this:

• high-compression implementation work: framework-standard CRUD, tests, migrations, fixtures, admin views, repetitive templates
• medium-compression design and planning work: feature slicing, acceptance criteria, route structure, permissions, review checklists
• client-dependent coordination: project management, review cycles, clarification, decisions, relationship overhead, feedback timing
• controllable setup work: infrastructure, deployment environments, seed data flow, rollback habits, review-environment automation
• discovered build work: imports, data cleanup, missing admin tools, hidden permissions, legacy behaviours not visible in the first pass
• parallelism risk: how many slices can move at once before review, merge conflicts, dependency order, and inconsistent assumptions consume the gain

The next pass needs to put the 2,800 hours into those bands. How many hours are standard implementation? How many are planning and design? How much is client-dependent coordination? Which items belong in the 312-hour reserve, and which should be moved back into the build model as work that still needs to be done? How much parallel work can run before I become the review bottleneck?

If too much of the estimate sits in client-dependent coordination, data uncertainty, and review remediation, the six-month model fails no matter how fast the CRUD work becomes. If enough of the project can be shaped into bounded implementation slices, and if enough of those slices can progress safely in parallel, the model starts to look possible without pretending every hour behaves the same.