An app feasibility study answers one question before you spend real money: can this app be built, will it pay for itself, and will people actually use it? For a small business, that fits on one page. Five checks and a payback calculation catch most of the ideas that would have turned into expensive regrets.
Big companies commission formal studies with market research and financial models. USDA Rural Development even publishes a free feasibility study guide for people starting cooperatives. Strip away the formality and the question an owner needs answered is simpler: does this concept work technically, and does it work economically? You just don't need consultants to apply it.
Key Takeaways
- An app feasibility study for a small business is five checks: can it be built, does the money work, is it legal, will your people use it, and is the timing right.
- The money check is a payback number: build cost plus a year of upkeep, divided by what it saves or earns per year.
- A "no" or a "not yet" is a successful study. It's the cheapest outcome you'll get.
- Sol's free Honest Read gives you a verdict on the build side, including when the answer is "you don't need a developer yet."
The Five Checks in an App Feasibility Study
Systems-analysis courses often teach these as TELOS: technical, economic, legal, operational, and scheduling. The names matter less than asking each question honestly.
| Check | The question | Red flag |
|---|---|---|
| Technical | Can it be built with normal tools, and where are the hard parts? | It depends on a system that has no way to share data |
| Economic | Does it pay back in a reasonable time? | Payback longer than the app's likely life |
| Legal | Does it touch payments, health or financial records, or kids' data? | Nobody has asked what rules apply |
| Operational | Will the people who must use it actually change how they work? | The users weren't asked |
| Scheduling | Does it need to exist by a date that matters? | A hard date and an unscoped project |
Technical. Most small-business apps are technically ordinary: forms, lists, logins, photos, notifications. The risk hides in connections to other systems. If your idea needs data out of an old POS or a scheduling tool, find out whether that tool can export anything before you go further.
Economic. This is the check owners skip, and the one that kills the most ideas. Covered below.
Legal. I'm not a lawyer and this isn't legal advice, but write down every kind of sensitive data the app would hold. If the list includes card numbers, medical details or anything about minors, get advice before you build.
Operational. The best-built app fails if your crew leads keep texting photos anyway. Ask three of the people who'd use it daily. Then watch what they do, because what they say and what they do won't match.
Scheduling. A trade-show date or a season can make an otherwise fine project infeasible. Be honest about whether the date is real.
The Payback Test
Payback in years = (build cost + one year of upkeep) / yearly benefit.
Use a range for build cost, never a single number. If you don't have quotes yet, the project calculator or an Honest Read will give you a range to work with. For upkeep, budget hosting, fixes and small changes; we break that down in app maintenance cost per year. For benefit, count hours saved at the real loaded wage, or margin on new revenue, not total revenue.
If payback is under two years on your pessimistic numbers, keep going. Two to four years: it can work, but cut scope first. Over four years for a small internal app, the money is telling you something.
A Concrete Version
A plumbing company with 9 trucks wants an app to replace the dispatcher's whiteboard and the morning phone calls.
- Technical: jobs, techs, a map, status updates. Ordinary. One hard part: their billing tool. They called the vendor and learned it can import a CSV, so no live connection is needed for version one.
- Economic: the dispatcher spends about 10 hours a week on calls and whiteboard updates. At an assumed $28 an hour loaded cost, that's $280 a week, or $14,000 over 50 weeks. Techs lose maybe 15 minutes each per morning waiting for assignments; 9 techs x 0.25 hours x 250 days = 562 hours a year. Even counting half of that at $35 an hour adds about $9,800. Yearly benefit: roughly $23,800.
- Cost: two quotes put the build at $18,000 to $26,000. Assume $5,000 for the first year of upkeep.
- Payback: ($26,000 + $5,000) / $23,800 = 1.3 years on the pessimistic quote. ($18,000 + $5,000) / $23,800 = about 1 year on the optimistic one.
- Legal: customer names, addresses and job notes. No card data, because billing stays in the existing tool.
- Operational: two of three techs said yes. The third said no until he heard it would end the 7am phone calls.
Verdict: feasible. Build it, keep billing out of version one.
The Honest Counterpoint
A one-page study can't predict adoption, and adoption is where most small-business apps actually die. You can do every check above and still find that staff quietly return to the old way in week three.
Second, owners grade their own homework generously. The benefit side gets optimistic and the cost side gets the cheapest quote. Run the payback on the worst plausible numbers on purpose. If it only works with the best-case figures, it doesn't work.
And sometimes the honest answer is that you don't need an app. A shared spreadsheet, a form tool or an off-the-shelf product may cover most of it for a monthly fee. Compare those before building anything; we cover that choice in custom software vs off the shelf and how to turn a spreadsheet into an app.
Frequently Asked Questions
What is an app feasibility study?
A short assessment of whether an app can be built, whether it pays for itself, whether it's legal, whether people will use it, and whether the timing works. For a small business, it fits on one page.
How much does a feasibility study cost?
Done by an owner with this checklist, it costs an afternoon. Formal studies by consultants cost real money and suit large or regulated projects. A free Honest Read covers the build side: what it would take, the hard parts, and a verdict.
What if the feasibility study says no?
Then it did its job. Write down what would have to change (a cheaper build, a bigger benefit, a system that can share data) and revisit in six months.
The Bottom Line
Run the five checks, do the payback math on pessimistic numbers, and talk to the people who'd use it. For the build side, get an Honest Read from Sol: it ends in one of three verdicts, keep going with the tool, one developer for a few weeks, or a small team at a fixed price. Read what the Honest Read includes, and if the answer is "build it," see the software factory.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
