Project planning guides
A useful MVP starts with a complete task, not fewer screens.
Before asking for a price, describe a first version that lets a specific user complete a useful task. Narrow the feature scope without leaving validation, permissions or operational responsibilities undefined.
Name the problem and the user
Write one sentence: “For [user], we need to make [task] possible because [current problem].” Describe the present workflow and what would change. “Build an app” describes a format, not a business need.
Identify different roles. The person creating a request may not be the person reviewing it. Give each role a task and a reason to use the product; do not put every administrative capability in the customer interface.
Choose one complete journey
Map the path from entry to an observable result: open the product, sign in if necessary, supply information, submit an action and see what happened. Include what staff must do afterward. A successful screen transition is not necessarily a completed business workflow.
Hayah is a useful portfolio example of separate mobile and staff roles. Its case study shows selected local flows, not proof of a complete donation lifecycle. Use that distinction when deciding what your own release needs to demonstrate.
Separate this release from later work
Make three lists: required for the chosen task, useful later and explicitly excluded. For each proposed feature, ask whether the user can complete the priority task without it. Notifications, dashboards and extra account roles are not automatically first-release requirements.
Do not confuse a prototype with a finished product. Selleva’s case study distinguishes storefront/cart prototypes from API-connected screens. If checkout is required for your release, a cart appearance or success message is not an acceptance test for payment.
List data, integrations and ownership
Identify the minimum records the workflow needs, who can read or change them and which existing system owns them. List API documentation, access requirements, translations and content the project depends on. Do not send credentials or sensitive customer records in an inquiry.
Decide who will own provider accounts, recurring costs and release responsibilities. An undocumented integration or unavailable account can change scope; it should be investigated before being treated as a fixed delivery commitment.
Write checks that demonstrate the result
Use concrete conditions. For example: “A signed-in requester can submit valid information, receive a reference and see the status; an authorized staff member can review the record.” Also specify invalid input, missing permissions, empty results and provider failures.
Choose the devices, languages and environments to check. Arabic text, English text and mixed-language data can expose different layout issues. Define how you will verify the selected flow; a screenshot proves appearance, not persistence or reliability.
Plan what happens after handover
Discuss deployment, source/design handover, documentation, backups, maintenance and how defects are reported. Distinguish defect correction from new features, and agree the support period and responsibilities rather than assuming unlimited availability.
Share a target date and budget range if you have them, including why the date matters. Treat these as constraints to discuss, not a reason to invent a guaranteed estimate before the dependencies and acceptance criteria are understood.
A brief you can use for the first conversation
- Problem and intended user
- Primary journey and staff responsibilities
- Required features and explicit exclusions
- Languages, devices and existing integrations
- Data needed and access/ownership boundaries
- Acceptance checks and release responsibilities
- Target timing, constraints and budget range if known
The workflow above is an illustrative acceptance example, not a claim that Hayah or Selleva has completed every release check.
Inspect the examples, including their limits
Choose the relevant service
Bring the brief, even if it is unfinished.
Share the problem and the decisions you have made. We can discuss which questions need answering before defining the next step.