How do you describe an app idea?

1. Describe the problem and intended outcome

Start with the current situation. What do people do by phone, in a spreadsheet or across several systems? Identify a concrete difficulty and describe how the task should work after launch. ‘Customers check the status of their own request’ is more useful than ‘we need a modern app’. You do not need to promise sales growth or specify an outcome you cannot yet measure.

2. Identify users and permissions

Separate customers, employees and administrators. For each role, describe what they can view, add, change or approve. A customer might see their own requests, an employee handle assigned cases and an administrator manage access. The number of roles and exceptions affects design, backend work and testing.

3. Choose one complete workflow for launch

Describe the user journey from beginning to end. Separate the features essential to completing it from ideas for later. If the core product assumption can still be tested without a feature, consider a later stage. The first version needs agreed acceptance criteria, rather than just a list of screens.

4. Explain devices and usage

Say whether users work at a desk, return regularly on their phones or use the product occasionally. Mention offline access, notifications or camera use where relevant. A store application should follow a real requirement; some needs may be better served by a browser-based customer portal.

5. List data, materials and integrations

Identify current systems, document types and data sources. Note any available API documentation and the responsible supplier contact. Integrations need assessment before they become an agreed commitment. Tool names and a description of the data flow are enough initially. Do not share passwords, API keys or real customer records in an enquiry.

6. State constraints and clarify the quote

Mention an investment range or target date if you have one, including the reason for a deadline. If you do not know, say so. Ask for development, external services, hosting and maintenance to be distinguished. An existing application may need a code assessment first. Compare proposals against the same scope, with assumptions and exclusions stated.

Example: a customer request portal

This is an illustrative example, not a delivered client project. Problem: case status is scattered across email and a spreadsheet. The first version lets a customer submit a request and check its status, an employee respond and an administrator grant access. Acceptance criteria: customers cannot see other customers’ cases; a status change remains visible when reopening a request; each reply stays attached to the correct case. Live chat, payments and a mobile application are outside this first stage. Any later development requires a separate scope decision.

Complete the outline and start a conversation