By Richcom Technology · Updated 19 October 2026 · 4 minute read
Custom business app planning works best when you begin with one job your team needs to complete. A focused app can help organise requests, capture records or make a repeated task easier to follow. Before commissioning it, define the users, the information they handle and what a successful result looks like.
| Requirement | Write in the brief | Avoid assuming |
|---|---|---|
| Platform | Target devices and installation | App-store publication |
| Data | Local, shared or connected records | Cloud sync in a local package |
| AI | Exact task and review step | Unlimited provider usage |
| Acceptance | Examples and expected results | That a demo covers all cases |
Choose one useful workflow
Write the workflow in everyday language. For example: a staff member records an office request, checks the details and exports a summary for a manager. Identify where it begins, where it ends and which steps require a decision.
List the problems in the current process. Perhaps details arrive in several messages or staff forget a required field. Prioritise problems that can be tested. “Make the app modern” is hard to measure. “Prevent saving a request without an item and quantity” gives both the developer and reviewer a clear outcome.
Define screens through tasks
Sketch the main screens and the action each one supports. A starting structure might include a dashboard, records list, entry form, record detail and settings. Five sections do not mean unlimited features inside each section. Agree the fields, buttons, validation rules and outputs as part of the written scope.
For each screen, describe empty, successful and error states. What does a new user see before any records exist? What happens when a required field is missing? Can a saved entry be edited or removed? These ordinary cases affect daily usability as much as the appearance of a finished screen.
For the next part of this decision, read Quotation Software Buying Guide for Small Businesses.
Decide where the information lives
Richcom’s current custom app packages describe direct installation and local device records. They do not include a Richcom-hosted cloud database, central synchronisation or cloud backup. If staff must share live records across devices, treat that as a separate requirement for assessment.
Connected catalogue features need internet access. Ask which actions work without a connection and what users see when a request fails. Agree backup and export arrangements before real business records are stored. Device access, lost-device handling and staff responsibilities should form part of the operational plan.
Give optional AI a precise job
Richcom offers optional AI features for custom apps at an additional $500 USD, with LLM/API usage paid separately. Possible scoped tasks include drafting, summarising or assisting a workflow. Agree the exact input, expected output, provider arrangement and review step; do not describe the requirement simply as “add AI”.
Use a realistic example without private customer data to define the task. For a summary feature, specify which fields it may read and what details the summary must preserve. Decide what should happen if the provider is unavailable or the output is incomplete. Keep a manual route available for the core business task.
Turn a vague AI request into a testable feature
“Summarise office requests” is a starting idea. A usable specification says which records are included, the reporting period, the desired headings and how the result is reviewed. For instance: produce a draft summary of selected requests, grouped by department, while preserving item quantities and marking missing information.
Prepare examples of a clean request, conflicting quantities and an unclear item name. Define the correct behaviour for each. When information is ambiguous, asking for clarification is usually more useful than producing a confident guess. Specify that the original records remain accessible beside the generated draft.
Decide what information is allowed to leave the device when a cloud provider is used. Send only the fields needed for the agreed task, and assess the chosen provider’s current data-handling terms before using real customer information. Confirm who controls the account and how usage is monitored.
The acceptance test should cover failure as well as success. If the provider times out or usage is unavailable, staff should still be able to read their records and complete the core workflow manually. That makes the AI feature an aid to the business rather than a new dependency for every action.
Make acceptance tests part of the brief
Create a small set of examples before development starts. Include a normal record, a long entry, missing information, an offline attempt and an edit to saved data. Write the expected result beside each case. For AI, include ambiguous requests and require review before an output is used.
Richcom’s current custom app pages show a one-month delivery period after required content and requests are supplied. Confirm the target platform, direct-installation method and agreed scope first. App-store publication is outside the listed packages. A change to platforms, shared data or integrations can change the work required.
Frequently asked questions
Does an AI add-on include unlimited usage?
No. The current offer separates the development add-on from LLM/API usage charges, which the client pays separately.
Can the app run completely offline?
That depends on the agreed functions. Connected catalogues and cloud AI require internet; fully device-only AI needs a separately agreed model and scope.
What should I send with my enquiry?
Send the workflow, intended devices, proposed sections, example inputs and outputs, and any integration requirements. Use sample data rather than account credentials.
Turn the plan into a practical next step.
Compare the current scope, requirements and delivery terms before choosing your package.