Does cheaper AI implementation justify a rewrite?
A smaller build estimate reopens the decision. It does not settle it.
The question
Morrow uses one cross-platform client. An engineer proposes separate native clients because an AI-assisted prototype was faster to build. You must recommend the next investment across the mobile, product and support teams. Morrow and all data are invented.
| Engineer-weeks | Scope | |
|---|---|---|
| Keep the shared client | 18 | Next quarter: implementation and review |
| Native prototype | 4 | One simple screen; implementation only |
| Full native estimate | 10 | Implementation only; extrapolated from the prototype |
The 18 and 10 estimates cover different work. Do not subtract them as a valid saving.
“Choose what to fund next and what evidence would justify the larger commitment.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: The native estimate is 10 weeks; the shared-client estimate is 18. Can you call the difference a saving?
What would you do here? Open the move you’d make.
Approve native: ten is less than eighteen
Tempting, but it misses something. The native estimate excludes work included in the shared-client estimate.
Keep the old choice because it worked before
Tempting, but it misses something. Past success does not answer whether the cost assumption has changed.
Compare the same scope and missing work
The strong move. This makes the changed assumption testable without treating a prototype as a full estimate.
See how a strong candidate says it
“No. The native estimate excludes review, parity checks and operating work. I would compare the same product scope and include work from both platform teams before claiming a saving.”
Why it works: Different scope makes the apparent eight-week saving unsupported.
Step 2: New fact: the prototype has no offline mode or accessibility review. Which pilot do you choose?
What would you do here? Open the move you’d make.
Pilot a difficult end-to-end slice with named reviewers
The strong move. Offline behavior and accessibility are missing from the first prototype.
Repeat the same easy screen on ten routes
Tempting, but it misses something. More examples of easy work do not test the missing capabilities.
Pause all feature work and rewrite both clients
Tempting, but it misses something. The packet has not established the full cost or ability to maintain parity.
See how a strong candidate says it
“I would fund a bounded slice that includes offline changes, accessibility review and both operating systems. The mobile leads own implementation and review; product agrees which feature work this displaces.”
Why it works: A representative slice tests the excluded work, while an easy-screen repeat does not.
Step 3: New fact: the pilot passes parity checks. Both team leads estimate 14 weeks total, but only 8 are funded. What changes?
What would you do here? Open the move you’d make.
Announce a fourteen-week rewrite without changing commitments
Tempting, but it misses something. There are only eight funded weeks; the plan still has an owner-capacity gap.
Present the six-week gap and a smaller deliverable
The strong move. This separates technical feasibility from an authorized delivery commitment.
Discard the pilot because the rewrite is not free
Tempting, but it misses something. The pilot still answered a useful question about representative behavior.
See how a strong candidate says it
“The pilot improves confidence in feasibility, but the funded capacity still falls short. I would seek a six-week capacity trade-off from product or choose a smaller deliverable. I would not quietly borrow time from support.”
Why it works: Better evidence can support the design while the adoption plan remains unfunded.
Step 4: New fact: product funds the missing 6 weeks and the support lead accepts the runbook. What is the next commitment?
What would you do here? Open the move you’d make.
Run pilots forever because every rewrite has risk
Tempting, but it misses something. The known scope and capacity questions now have answers. Name a remaining question before buying more proof.
Proceed and remove all review points
Tempting, but it misses something. Passing the pilot does not establish every future operating result.
Proceed with the funded scope and explicit review triggers
The strong move. The decision now rests on representative evidence and accepted ownership.
See how a strong candidate says it
“Proceed with the agreed scope, owners and checks. Keep a review point if parity, support load or feature delivery falls outside the agreed limits. A changed assumption can justify a new decision once the missing work is funded.”
Why it works: The funded plan and representative evidence now support proceeding; indefinite testing would add delay without a named question.
The answer, in short
- Decision
- Proceed after the representative pilot and capacity decision.
- Because
- The first prototype reopened an assumption; the later evidence and funding support a commitment.
- What would change it
- A parity failure, unowned support work or a cut in funded capacity reopens the scope.
Common traps
- Treating different estimates as a saving
- Using AI speed as evidence of operating quality
- Refusing a justified change because the old choice succeeded
Check your answer
- Did I compare the same scope?
- Did I test the missing capabilities?
- Did the teams accept the displaced work?
- Did I say what would reopen the decision?
Last reviewed Nov 10, 2026