Pick one job for your first web app
“An app for my cleaning business” can grow into scheduling, invoices, stock, and customer messages. “A checklist I can finish without reception” is small enough to understand and test.
Describe one person doing one task
Write who uses it, where they use it, what they enter, and what they need at the end. For an illustrative checklist: one cleaner records completion of six rooms on a phone, then exports a dated job record.
Watch the current task first. If a paper sheet includes exceptions or handwritten notes, ask what they mean. Do not remove the useful parts just because they are messy.
Set the limits of the first version
Choose the fields and actions needed to finish the task. Include correction and recovery, not just entry. A completed checklist needs a way to fix a mistaken tick and tell one job from another.
Write what stays outside the app: payments, customer accounts, scheduling, and team sync, unless the task genuinely depends on them. An explicit boundary makes estimates and testing easier.
Agree on a success check
Use a concrete test: “The cleaner can finish the sample job offline, close the app, reopen it, and export the completed list.” Add the device and browser to the test record.
Also ask someone to use it without coaching. If they cannot find today’s job or tell whether it saved, the first version needs clearer feedback, not more features.
Budget for the whole life of the tool
Ask who owns the source files, domain, hosting account, and maintenance work. Include time for training and a tested export. A free hosting plan does not mean a tool has no ongoing responsibilities.
Use the one-job worksheet before commissioning the build. If two people disagree on the finish line, settle that while changes are still easy.
Your choice stays on this device. It is not sent to the site owner.