1. Define the user and the learning goal
Name one primary user and the task the first release must let them finish. State what you need to learn: whether a workflow is useful, whether someone will pay for it or whether staff can complete a handoff more reliably.
Separate known requirements from assumptions. Capture current workarounds and evidence from actual conversations where available. Decide who approves the product scope and who will review delivered work.
- Primary user and the problem being solved.
- Core journey with a beginning and an observable result.
- Success measures and a plan for gathering feedback.
- Budget, target date and decision owner.
2. Agree features and exclusions
Map the journey into screens, data and actions. Define user roles, admin tasks and integration points. Put secondary workflows in a later-release list and make exclusions visible in the proposal.
For an illustrative subscription product, sign-in, one workflow, a basic admin view and one billing integration might form the first scope. Extra roles, advanced reporting, migrations and separate clients are additions to assess rather than automatic inclusions.
3. Confirm integration and data dependencies
List every external system, the account owner and required access. Confirm that API capabilities support the intended workflow. Define synthetic examples for development, the data that belongs in production and the permissions for each user role.
A missing provider credential or unsupported operation can block an otherwise simple release. Assign each dependency an owner and agree when it must be available. Do not share live customer records through an initial enquiry form.
| Dependency | What to confirm |
|---|---|
| Payments | Provider account, supported workflow, test access and webhook handling |
| Email or SMS | Sender setup, templates, delivery failures and usage costs |
| Existing system | API access, rate limits, permissions and source of truth |
| AI feature | Evaluation examples, approved data, human review and usage limits |
| Hosting | Account owner, environments, secrets and backup plan |
4. Write acceptance criteria before engineering
Describe what the user can do when each feature is complete. Cover both success and failure: an invalid upload, declined payment, expired session or failed provider request. Include tests showing that users cannot access another account's records.
Agree the review schedule and the person who accepts work. A screen looking correct is only one part of acceptance. The data changes, integrations, error handling and accessibility also need to work for the supported devices.
- Critical journey passes on the agreed devices and browsers.
- Backend enforces permissions independently of the interface.
- Retries do not create duplicate records.
- Errors show a usable next step.
- Successful enquiries or purchases are measured only after success.
5. Prepare the production release
Check domain and deployment access, environment configuration, monitoring, database migration and recovery. Use a production-like staging environment to test the critical workflow with synthetic data before opening it to users.
Name the person who can roll back a release and the team handling support. Decide how incidents are reported and how long relevant logs are retained. If a mobile app is included, reserve the required distribution and review work in the plan.
6. Confirm ownership and the next release
Receive repository access, deployment instructions, account ownership, dependency information and the agreed support arrangement. Confirm code/IP terms and third-party licenses in the agreement rather than inferring them from a package label.
After launch, compare actual usage, support requests and user interviews with the original learning goal. Choose the next release from that evidence. Do not count all requested features as urgent simply because they appeared during the pilot.
Use the checklist to request a useful quote
Send the core journey, included features, dependencies, acceptance criteria and target date. Kraydl can assess a $4,000 focused sprint, a $12,000 agreed Complete MVP Package or a custom scope. Typical complete-MVP delivery is 6–8 weeks after scope and dependencies are agreed.
Keep infrastructure, model usage, maintenance and later features separate from the initial build price. A useful proposal states assumptions and exclusions; the checklist helps both sides see where those assumptions still need validation.
Get a scope and quote for your project
Tell us who the product is for and the workflow you want to build. We will review your brief and discuss the scope, budget, and next steps.
Helpful References
Authority sources
FAQ
What should a non-technical founder prepare first?
Describe the primary user, one core task, necessary integrations, approximate budget and intended launch date. You do not need to choose every framework before discussing the scope.
Does an MVP need production testing?
A release used by real customers needs checks for the agreed workflow, permissions, integrations, failures and recovery. A learning prototype can have different acceptance criteria, which should be explicit.
How do we stop scope creep?
Maintain an included scope and later-release list. Assess changes against the learning goal, budget and schedule, and approve their cost and acceptance criteria before adding them.
Build the right version first.
Bring Kraydl the workflow, launch goal, risk constraints, and timeline. We will help turn it into a scoped product plan and a build path founders can actually use.