US | Workflow | 2026-08-16

Turning a Business Workflow into a Mobile App

The clipboard, the group text, and the whiteboard already work — the job is to find the one step where they stop working and replace only that.

A pool service company in Arizona ran 140 accounts on a paper route sheet, a shared Google Sheet, and a group text. They asked for an app that would replace all three. What they actually needed replaced was one thing: the 20 minutes every evening the owner spent transcribing chemical readings from damp paper into the sheet so he could invoice on Friday. Everything else about their process was fine. Building the whole thing would have cost four times as much and been used less.

That gap — between the workflow people describe and the step that actually hurts — is where most workflow-to-app projects go wrong. Here is a method for closing it.

Step 1: Write down the process as it actually runs, not as it should

Follow one job end to end and record every handoff, with timestamps. Not a flowchart of the ideal process; a log of a real Tuesday. For a mobile service business it usually looks something like this:

1. Customer texts the owner's cell at 7:40am.
2. Owner writes it on a sticky note, later types it into Google Calendar.
3. Tech gets the day's list by screenshot at 6am.
4. Tech does the work, writes readings on a route sheet.
5. Tech texts "done" plus a photo.
6. Owner transcribes route sheets in the evening.
7. Friday: owner builds invoices in QuickBooks from the sheet.
8. Customer pays by check or Venmo, owner marks it paid manually.

Interview two people, not one. The owner will describe steps 1, 7 and 8. The tech will tell you that step 4 involves standing in the sun trying to write on a wet clipboard, and that step 5 fails constantly because there is no signal at half the properties. Those details determine whether the app needs offline write support, which is an architectural decision, not a feature request.

Step 2: Score each step on pain, frequency, and error cost

Give every step three numbers from 1 to 5: how much it hurts, how often it happens, and what it costs when it goes wrong. Multiply. The highest product is your first build target, and it is frequently not the step anyone complained about.

Transcription wins by a wide margin, and it wins because of frequency, not drama. Founders tend to fixate on the visible embarrassment — an ugly booking experience, a customer complaint — while the money is leaking from a step nobody mentions because they have done it 900 times.

Step 3: Decide what stays manual, deliberately

This is the part that gets skipped and it is the part that keeps budgets honest. Some steps should never be digitized:

• Steps where the existing tool is better than anything you would build. Text messaging has 98% open rates and zero onboarding. If customers book by text and that works, keep it and just pipe the confirmation into the app. Forcing customers to install something to book is how service businesses lose bookings.
• Steps that happen fewer than a few times a month. Annual license renewals, one-off custom quotes, the occasional refund. A screen used four times a year still needs design, testing, and maintenance forever.
• Steps that require judgement. "Decide whether this customer gets a discount" should be a button that notifies the owner, not a rules engine. Every rules engine I have seen for pricing exceptions ends up with a manual override that becomes the only path anyone uses.
• Steps already owned by a system of record. If the books live in QuickBooks, sync to QuickBooks. Do not rebuild accounting. The integration is cheaper and the accountant will not fight you.

Write the not-building list down and share it. It is more useful in a scoping conversation than the feature list, because it tells the client where the savings came from.

Step 4: Build a thin slice, not a prototype

A prototype is a picture of the whole product. A thin slice is a narrow strip of the real product that runs all the way through the stack — one workflow, real auth, real database writes, real deploy to a real phone. For the pool company the thin slice was: tech logs in, sees today's stops, taps a stop, enters four chemical readings and a photo, taps done. That is it. No invoicing, no customer accounts, no scheduling.

Why a slice beats a prototype:

• It surfaces the hard technical constraints in week two instead of month three. In this case: no cell signal at the properties. That means a local write queue with sync-on-reconnect and conflict handling, which is real engineering. A Figma prototype would never have found it.
• It gets used by an actual employee, and employees are honest in a way stakeholders are not. The tech's first note was that gloves do not work on capacitive screens, so the number inputs needed to be big steppers, not a keyboard.
• It creates a measurable before and after. Evening transcription went from 20 minutes to zero. That number funds the second phase without a debate.

A useful sizing rule: if the thin slice takes more than three weeks, the slice is too thick. Cut the scope, not the quality.

Step 5: Instrument the thing you claimed to fix

Before shipping the slice, record the baseline: minutes spent on the step, error rate, how many times per week someone calls the owner about it. After two weeks of real use, measure the same three. Two outcomes are both fine, and both are informative.

If the number moved, you have proof for the next phase and you know which step to attack next — probably invoicing, now that clean data exists. If it did not move, you spent three weeks instead of six months, and you learned something specific: usually that adoption failed, and adoption failed because the app added a step for the person doing the work while removing one for the person paying for it. That asymmetry is the single most common reason internal tools sit unused.

Then repeat. Rescore the workflow with the new step in place. The ranking will have changed, because removing the top-scoring friction almost always promotes a step nobody expected.