Prepare the problem, user roles, one complete core journey, operating rules, integrations, acceptance conditions and first-release exclusions. You do not need to choose a programming language or design every screen yourself. You need enough information for suppliers to understand the same boundaries and identify the decisions that still affect an estimate.
“An app for bookings” starts a conversation. A usable scope explains who books what, when a booking becomes confirmed, who can cancel it and what happens when requests conflict. That is where a meaningful comparison of development proposals begins.
Do you need a long requirements document before contacting a developer?
A short brief is enough to open the discussion. However, an early estimate should not be treated as a commitment to an unresolved scope. Document length does not establish readiness. What matters is whether someone can connect each function to a user, an outcome and clear operating conditions.
The GOV.UK Service Manual describes user stories through the person, their need and their goal. It describes acceptance criteria as outcomes that help confirm the need has been met. This is a useful documentation approach, not a Saudi regulatory requirement. GOV.UK guidance on user stories.
If your team disagrees about how the service should operate, begin with Product Discovery & Requirements. The priority is resolving scope-changing decisions, not polishing the description of the idea.
Seven decisions your brief should make visible
| Decision | What to record | Risk if it remains unclear |
|---|---|---|
| Problem | Where the current process breaks down and who is affected | Features may miss the underlying problem |
| Users | Customer, employee and supervisor roles, including permissions | Essential administration work may be omitted |
| Core journey | Starting point, steps and completion outcome | Screens are priced without a complete process |
| Operating rules | Confirmation, cancellation, changes and conflicts | Suppliers estimate different interpretations |
| Data and integrations | Systems, fields, owners and available access | A substantial dependency remains unexamined |
| Release boundaries | Included, deferred and excluded work | The first release grows without an explicit decision |
| Acceptance and handover | Tests, files, accounts and approvers | “Finished” means different things to different people |
Add practical constraints: Arabic and English, target devices, weak connectivity, a launch date tied to a real operational event and a planning budget if you want to share one. “Supports Arabic” is incomplete: identify the screens, content, dates, numbers and error messages that need Arabic review.
Worked hypothetical example: equipment bookings in Riyadh
This is a teaching example, not a LAB project or a customer result.
Imagine a business renting equipment for events. It currently manages requests through calls and a shared spreadsheet. The initial brief asks for an app displaying equipment and accepting bookings. A closer look reveals decisions that change the build:
- A customer submits a request but does not receive instant confirmation.
- An employee checks equipment availability and return dates before confirming.
- Some items have several rentable units; others have only one.
- A supervisor can change a booking, with a record of who changed what.
- Delivery management and in-app payments are outside the first release.
The first-release journey is to choose equipment and dates, submit a request, complete an employee review, confirm availability and display the status to the customer. The employee interface is therefore part of the essential product, not an optional administration extra.
Turn that journey into acceptance conditions
Replace “the system prevents booking errors” with testable outcomes:
- An employee cannot confirm equipment that is unavailable for the requested period.
- If two employees simultaneously confirm the last available unit, only one confirmation succeeds. The other sees that availability has changed.
- A pending request is shown to the customer as awaiting review, not as a guaranteed booking.
- Cancelling a confirmed booking updates availability according to the agreed rule and records the person responsible.
- If a notification fails, the correct booking status remains visible in the system. Retrying must not create a duplicate booking.
These cases expose design, development and testing work. User Experience Design can turn them into flows and a testable prototype before detailed interface decisions are approved.
Separate an unresolved decision from a deferred feature
A deferred feature is an intentional boundary: in-app payment is not included in release one. An unresolved decision is a question that still changes the estimate: does the existing inventory system provide an accessible integration interface?
Keep a decision log with the question, its owner, the evidence needed and its effect on scope. For example, the inventory provider may need to confirm access to quantity data. Do not describe “integration with the current system” as settled before its documentation and permissions have been checked.
Where integration matters, API Integration & Development needs explicit boundaries: what is read or written, who authorizes access, and how failures and duplicate requests are handled. Naming a system does not answer those questions.
How to compare proposals against your requirements
Send the same version of the brief to every shortlisted supplier. Collect their questions and share material clarifications so the proposals are not based on different assumptions.
Ask each proposal to explain:
- Which requirements it covers and which are excluded.
- Its assumptions and the consequences if they prove incorrect.
- Stage deliverables, approvers and inputs required from your team.
- External services and recurring costs not included in development fees.
- How scope changes, post-handover support and ongoing operation are handled.
- How code, designs, documentation and accounts will be handed over under the agreement.
Avoid comparing screen counts alone. One screen can involve complex rules and permissions, while several information pages may be comparatively straightforward. A higher price does not prove a broader scope either. Look for written coverage you can verify.
Before you approve development
- [ ] The decision-maker and operational representative agree on the core journey.
- [ ] Customer, employee and supervisor permissions are separated.
- [ ] Failure and conflict cases are documented alongside the successful journey.
- [ ] Open questions have owners rather than being hidden in general statements.
- [ ] Acceptance conditions specify what will be tested and with which test data.
- [ ] Handover responsibilities and separately operated subscriptions are clear.
- [ ] Scope changes have an agreed review and approval process.
Bring Software Quality Assurance into acceptance planning early. A condition that cannot be tested needs clarification before it becomes a handover requirement.
Common mistakes
Using a famous app as the entire specification. A reference can explain an interaction, but it does not define your operating rules or what your business actually needs.
Calling every feature essential. Ask whether removing it prevents the core journey from being completed. If not, discuss deferral rather than automatically including it.
Sharing real customer records with the quote request. Use synthetic examples or appropriately de-identified samples and disclose only what is necessary to explain the problem.
Leaving acceptance until the end. Agree on the evidence required for each important outcome and who will review it before implementation begins.
Frequently asked questions
Do I need complete designs to get an estimate?
No. Clear journeys and requirements can support an initial estimate. If important interactions remain unresolved, a prototype or discovery phase may be needed before a detailed proposal.
Should I write an SRS myself?
You can document business rules, operational examples and intended outcomes. Turning those into connected specifications benefits from analysis, design, development and testing input. The document’s title matters less than its clarity.
Must I choose a mobile app or web app first?
Record the usage need first. Does the task require device features? Is use frequent or occasional? Does an employee work primarily at a desk? These answers help the team recommend a channel rather than choose one because it is fashionable.
Will clear requirements prevent the price from changing?
They cannot guarantee that. They make changes explainable: a new scope decision, an external dependency that did not hold or a revised requirement. Document the effect before approving the change.
Your next step
Bring one complete journey, safe operational examples and an unresolved-decision list to a discussion about App Development with LAB. Use them to establish whether implementation can begin or whether discovery should come first. The discussion can then focus on something that can be delivered and reviewed, rather than a number detached from its scope.
Sources
- GOV.UK: Writing user stories and acceptance criteria. Used for the documentation method, not as a local legal authority.
- Source reviewed on 26 October 2026. The tables, example and comparison checklist are proposed editorial tools, not mandatory standards or reported project results.
