A lean MVP starts with deciding what you will not build yet

EDITORIAL PRACTICE

Build enough to inform the next decision

An MVP does not always need a thin version of every future feature. Define one situation in which a particular user should complete a task. Decide whether a visual prototype is sufficient or whether working data storage is necessary.

For an enquiry tool, the first scenario might be a team member reading a submission and updating its status. Billing, complex permissions and analytics should each be tested for necessity. The following example is illustrative, not a standard package or delivery promise.

FROM PRIMARY SOURCES

Write down requirements before handing work to AI

GitHub’s introduction to Spec Kit describes a workflow that carries a written specification through planning, tasks and implementation. It makes the intended product explicit before coding.

Sources: [1]

EDITORIAL PRACTICE

Pair each feature with acceptance criteria and exclusions

Give the overseas team and AI the same definition of completion. Keep screen names, fields and exception conditions consistent across Japanese requirements and translated tasks.

EDITORIAL PRACTICE

Make total cost and assumptions visible

AI-assisted work still includes requirements, design, human review, testing and release preparation. Evaluate the cost of completing the agreed scope, rather than model usage alone.

Distinguish initial and recurring work, included revisions, ownership of external subscriptions and approval for additional work. Agree what happens when AI or tool usage reaches a cap.

• Design and development: screens, features and deliverables included.
• Review and tests: scenarios, environments and correction scope.
• AI and external services: usage costs, caps and account ownership.
• After release: maintenance, monitoring and further changes.
• Scope changes: estimate the impact and obtain agreement before adding work.

EDITORIAL PRACTICE

Review small deliverables before expanding

Once one scenario works, observe users and review the remaining problems. Prioritize requests related to the next question you need to test.

Receive the code, configuration instructions, test results and known limitations. Completion should be understandable from the deliverables even if a different team takes over later.