Keep a spreadsheet when the people using it can finish the job safely and consistently. An app becomes worth investigating when a specific workflow or access requirement is hard to meet with your present arrangement—and someone can own the resulting system.
Overskill lets you describe an app you want to build. This optional Part 1 decision exercise helps you decide whether to build one at all. You will leave with a short decision record: what is failing, which smaller change to try, what evidence would justify a prototype, and what would make you stop.
There is no row-count threshold or points score that makes this decision for you. The three businesses below are fictional. Their examples illustrate the reasoning, not measured customer results.
Start with one failure you can observe
Write the job as an action: “the coordinator assigns a request and the next person knows what to do.” Then describe the last time it failed. Separate a tool limitation from a missing rule.
| What you observe | What to investigate first |
|---|---|
| Someone overwrote a formula | Who should edit which cells, and what recovery is available? |
| Every request has a different interpretation of “ready” | Agree on the handoff rule and owner before choosing software. |
| A client must see only their own records | Verify the actual access boundary with separate test accounts. A filtered or hidden view alone is not proof. |
| Staff enter the same information in several places | Identify the authoritative record and why each copy exists. |
| Nobody will maintain a custom system | Keep a simpler process or evaluate a maintained product before building. |
For example, Google Sheets supports restricting edits to ranges and sheets, but Google warns that this protection is not a security boundary. Hiding a tab also does not prevent people with spreadsheet access from finding its content. Google's protection and hiding documentation explains the distinction. Do not use these controls as evidence of private records for different clients.
Version history is another capability to check before declaring the current tool inadequate. Google documents viewing and restoring earlier versions, with edit permission needed to browse history. That is useful recovery behavior; it is not proof that a particular business workflow has passed an approval or audit requirement. Google's version-history documentation.
Case 1: Keep the sheet
Lantern Ceramics has two trusted staff members who count 40 display items every Friday. Both are allowed to see the entire inventory. One person enters counts; the other checks differences before the next order. There is no customer login, reservation promise or live checkout in this workflow.
The owner dislikes how the sheet looks, but cannot name a missed handoff or access requirement it fails. Building an app would introduce another interface to maintain without changing the weekly job.
Decision: keep the sheet. Document who enters the count and who checks it. Confirm that the existing recovery process works on a harmless copy. Do not add customer accounts or automated stock promises merely to make an app feel useful.
Evidence that would reopen the decision: the team introduces item reservations shared with customers, or another role needs a different access boundary. That would be a changed requirement, not proof that 40 items became too many.
Case 2: Improve the process first
Cobalt Studio's eight staff handle client requests in a shared sheet. In a fictional sample of 20 requests, six sit in a “ready” column. The coordinator means “we received the files.” The designer means “the client approved the files.” Neither definition names who takes the next action.
Moving those same columns into an app would preserve the ambiguity. Before prototyping, the team writes two distinct states, names an owner for each handoff, and agrees what evidence permits a request to move forward.
Decision: try the clarified process on the next five suitable requests in the existing setup. Record whether a person still has to ask who owns the next action. Five is this team's small pilot, not a statistical benchmark or universal minimum.
Evidence that would reopen the decision: the agreed rule works, but staff still repeatedly miss a handoff because the present tool cannot present or enforce it suitably. The app requirement can then describe that exact failure. If the rule itself keeps changing, continue learning before encoding it.
Case 3: Prototype one app journey
Copper Installations coordinates work across 12 customer sites. Its current arrangement copies status updates into separate customer messages. The proposed requirement is specific: a customer opens their own job, sends a question, and sees the assigned coordinator's response without gaining access to another customer's job.
This is an access and communication workflow, not simply a larger spreadsheet. The team should evaluate whether an existing maintained product already meets it. A custom prototype is one option if the available products do not fit the demonstrated requirement.
Decision: prototype only that customer-question journey with fictional records. Name a maintainer and an operating budget before adding scheduling, payments or inventory. Use two customer test accounts and a staff account to check permitted and rejected reads, edits and exports. A convincing screen is not the finish condition.
Evidence that would stop the prototype: it cannot demonstrate the access rule, the team cannot maintain it, or a maintained product meets the need with less ongoing work. Keep the present working process until the replacement passes its checks.
The private-record access guide provides a concrete test matrix. The client portal guide is a relevant next step if this is the workflow you actually need. Those are methods to implement and test; they do not certify any generated app's permissions.
Compare the work after launch
Put all three options on the same worksheet: keep the current setup, improve its process, or adopt/build a different system. Include a maintained product as a candidate when it fits. Compare the actual requirement and the work each option creates.
| Decision field | Write a concrete answer |
|---|---|
| Access | Who may read and change each kind of record? What test proves it? |
| Ownership | Who maintains rules, answers questions and reviews changes? |
| Recovery | How will you detect a failed update and recover a useful record? |
| Change cost | Which people must learn a different process or move information? |
| Operating cost | Which prices or usage assumptions are known, and which remain unknown? |
| Exit | What usable information must you be able to take out? |
| Reconsideration | Which observed result would change today's decision? |
Do not assign a zero to an unknown operating cost. The running-cost planner keeps missing prices visible while comparing your assumptions. It does not supply current vendor prices or guarantee savings.
Leave with a decision, not another feature list
Download the decision worksheet. Complete one real workflow, choose the smallest next experiment, name its owner and set a review date. Keep a record of what would make you choose differently.
If the evidence supports an app, first validate the customer task. Then map the spreadsheet's records before copying its columns into a new interface. Use the app brief to state the journey, access rules and acceptance checks, then choose Start build in the brief builder. Account access and normal build-credit requirements apply.
If the evidence supports keeping the sheet, the exercise has still done its job. Revisit it when the requirement changes or the next observation contradicts your decision.