How to Turn a Business Process Into an App Without Writing a Technical Specification

Start with the business outcome, not a list of features

A request such as “we need an app for stock problems” is understandable but too broad to verify. A better starting point is: “When Shopify stock disagrees with our ERP, show the mismatch to the catalogue team, explain which system owns the value and require approval before changing the store.” That sentence identifies the event, user, information, decision and safety boundary.

This outcome-first approach prevents a project becoming a collection of screens that do not solve the original problem. GOV.UK service guidance similarly recommends understanding users and the problem they are trying to solve in its full context. The practical lesson for any business is to observe the current work before deciding what software should replace or support it.

Write a one-page process brief in plain English

The first brief should be short enough for the people doing the work to challenge. Record the trigger, the current steps, the people involved, the information used, the decision points, the desired result and the important exceptions. Avoid prescribing databases, frameworks or screen layouts unless a real constraint makes them necessary.

Separate facts from preferences. “Orders must retain the Shopify order ID” is an identity and reconciliation requirement. “The button should be blue” is a presentation preference. Both may matter, but confusing them makes it harder to judge whether the application is operationally correct.

• Trigger: what starts the process?
• User: who completes, reviews or receives the work?
• Inputs: which records, documents or customer details are needed?
• Rules: what must the application calculate, compare or decide?
• Outcome: what should be true when the process is complete?
• Exceptions: what needs a human decision instead of automation?
• Evidence: what must be logged so the result can be checked later?

Turn uncertainty into focused clarification questions

Clarification should expose decisions that would materially change the application. Ask one question at a time and explain why the answer matters. If a booking application could serve hair appointments or cottage stays, duration cannot be assumed: one needs minutes, the other may need nights, availability rules and check-in boundaries.

Good questions offer real alternatives. Who owns the stock value: Shopify or NetSuite? Should an exception pause the whole run or only the affected record? Can a team member approve a price change, or must it be an administrator? Each answer becomes an acceptance condition rather than disappearing into meeting notes.

1. Describe the outcome in the language used by the business.
2. Ask only questions that change data, behaviour, access or risk.
3. Summarise the agreed process and unresolved assumptions.
4. Confirm the acceptance conditions with the people who do the work.
5. Build the smallest complete path that can prove the outcome.

Define data ownership before connecting systems

Connected applications need an explicit source of truth for every important field. A product title may be maintained in Shopify, while available stock comes from Sage 200 and financial status remains in NetSuite. The application should carry stable provider identifiers through exports, imports and audit records so an editable title, handle or SKU cannot accidentally point an update at the wrong record.

Authentication and permission boundaries belong in the requirement, not as an afterthought. Shopify’s official documentation explains that access tokens carry scopes that determine what an app can read and write. Ask for the narrowest permissions needed, bind credentials to the correct organisation and store, and make connection status visible before a user can run a data operation.

Build controls into the normal workflow

A useful business app makes the safe action the easy action. Preview bulk changes, show differences before confirmation, prevent duplicate submissions and put exceptions in a visible queue. A successful API response is not the same as a reconciled business result, so completion should include record counts, failures and a traceable run status.

NIST’s Secure Software Development Framework is outcome-based and intended to align secure development activities with business requirements and risk tolerance. For a small operational app, that principle translates into concrete controls: protect credentials, isolate customer data, review high-impact changes, test expected failures and keep enough evidence to investigate a problem.

• Use least-privilege access and organisation-scoped credentials
• Preview imports, deletions and bulk updates before applying them
• Require explicit confirmation for destructive actions
• Use stable external IDs for updates and reconciliation
• Record who approved an action, when it ran and what changed
• Fail visibly and preserve unaffected records when safe to do so

A concrete example: resolving stock mismatches

Imagine a wholesaler selling through Shopify while NetSuite controls inventory. The current process is a daily spreadsheet comparison. Staff copy SKUs, investigate discrepancies and manually adjust the store. The business outcome is not “make a dashboard”; it is “identify genuine stock mismatches quickly and correct approved records without changing the wrong product.”

The first application path connects the authorised Shopify and NetSuite accounts, compares records using their stable IDs, shows the owning system and current values, and lets an authorised user approve selected corrections. It logs skipped records and connection errors. Later versions might add schedules or notifications, but the initial build is already valuable because it completes one controlled outcome.

How to judge whether the application is ready

Test with realistic examples, including missing data, duplicate identifiers, expired access, conflicting edits and a user without approval rights. Ask the operational team to complete the process without explanation. If they cannot tell what happened, what needs attention or whether the final result is correct, the application is not finished.

Measure the business result rather than the amount of software produced. Useful measures include minutes of re-entry removed, exceptions resolved, incorrect updates prevented, completion time and the proportion of runs reconciled successfully. Keep the original outcome visible so future changes improve the same process instead of gradually turning the app into an unrelated collection of features.