How to build an app for your business without wasting $50k

Most of the money wasted on business apps is spent before anyone writes a line of code. It goes into features nobody asked for, a scope nobody tested, and a launch date nobody planned slack around.

The process that avoids it is unglamorous and it works. Prove demand with something fake, cut the app to a single job, test a clickable prototype with five real people, then build in two-week slices you could stop at any point without losing your money. Everything below is that process, in order, with the dollar figures attached.

Phase 0: how do I know if anyone will use this?

Before you spend anything, you run a test that produces a yes or a no. There are three that work for small organizations, and none of them require a developer.

The landing page test. Build one page that describes the app as though it exists, with a single sign-up form. Send it to the people you think want it, whether that is your email list, your staff, a Facebook group, or the twelve clients you already talk to weekly. If forty people see it and two sign up, you have your answer. A page like this is a couple hundred dollars on Squarespace or a day of your own time, and it is the cheapest website money you will ever spend.

The concierge test. Do the thing manually for two weeks. If the app is supposed to book rides, book the rides yourself by phone. If it is supposed to send families a weekly progress note, write the notes and email them. You will learn what the workflow actually is, which is almost never what you assumed, and you will find out whether people engage at all.

The spreadsheet test. Put the data in a shared Google Sheet or Airtable base and give people access. A surprising number of app requests are a database problem wearing a costume. If a shared sheet plus a form solves 80% of it, stop there and keep your $40,000.

Validation method	Cost	Time	What it proves
Landing page + sign-up	$0 – $500	1 week	People will give you their email for this
Concierge (do it by hand)	$0	2 – 3 weeks	The real workflow, and whether demand repeats
Shared spreadsheet or Airtable	$0 – $50/mo	1 – 2 weeks	Whether you need software at all, or just structure
Clickable prototype	$3,000 – $8,000	2 – 4 weeks	Whether people can actually use your design

Here is the part that costs me work. If the spreadsheet test solves your problem, do not hire us. A home care office in Bloomington that wants shift checklists, or a charter school that wants a field trip permission tracker, can often run on Airtable, Google Forms, and a no-code app layer for a few hundred dollars a year. That is a legitimate finished answer, not a stepping stone. Come back when you hit a wall you can name.

Phase 1: what is the one job this app does?

Write it as a single sentence with a subject and a verb. Not “a platform for our clients,” which is not a job. Something like “a caregiver marks a visit complete and adds a note in under thirty seconds while standing in a client’s kitchen.”

Now score everything else against it. Take your feature list and give each item three marks.

Question	Scoring
Does the core job fail without it?	Yes = keep. No = candidate to cut.
What share of users need it in week one?	Under 50% = cut to version two.
How long does it take to build?	Over two weeks = it needs its own justification.

The rule that does the work: if removing a feature does not break the one job, it does not ship in version one. Most feature lists we get handed shrink by roughly half under that rule, and nobody misses the removed half after launch.

The features that survive on a typical first version come to three to six screens. A sign-in, a list, a detail view, an action, and a confirmation. That is a real product. Admin dashboards, in-app chat, a notification center, a settings page with twelve toggles, gamification, and a referral system are all version two, and half of them will be version never once you see how people actually use the thing.

Every feature you add is not a one-time cost. It is build time, plus testing surface, plus store review risk, plus a maintenance obligation every year for as long as the app exists. That is why feature creep is the second most expensive mistake on this list.

Phase 2: why test with five users before writing code?

Because fixing a screen in a prototype takes an hour and fixing it in a shipped app takes a sprint. A clickable prototype costs $3,000 to $8,000, looks and behaves like the real app, and can be in front of users three weeks after kickoff.

Five testers is not a made-up number. Jakob Nielsen’s usability research at Nielsen Norman Group found that testing with about five people surfaces the large majority of usability problems in a given design, and that additional testers past that point mostly repeat what the first five already told you. For a small business app, five is plenty for round one.

Test with the actual people. Not your board, not your spouse, not another developer. If it is a scheduling app for direct support professionals, put it in front of five DSPs. Hand them the phone, give them a task in one sentence, and then say nothing while they struggle. The silence is the method. Every time you jump in to explain, you erase the finding.

Watch for three things: where they hesitate, where they tap something that is not a button, and where they ask “wait, what does this do?” Write those down verbatim. Then change the design and run it again with three more people.

Phase 3: native, cross-platform, or a web app?

This decision is usually made emotionally and it should be made from a table. Most organizations that ask us for a native mobile app are better served by a fast mobile web app, and I will keep saying that even though the native project bills more.

	Mobile web app / PWA	Cross-platform (React Native, Flutter)	Native (Swift + Kotlin)
Typical first version	$6,000 – $25,000	$20,000 – $75,000	Highest, roughly two builds
Timeline	4 – 10 weeks	12 – 28 weeks	16 – 36 weeks
Store listing	No	Yes, both stores	Yes, both stores
Push notifications	Limited on iOS, and only after the user adds it to their home screen	Full	Full
Offline use	Basic caching	Yes	Yes
Camera, GPS, Bluetooth	Partial	Nearly all	All, first day of a new OS feature
Updating it	Instant, you deploy	Store review for most changes	Store review for most changes
Choose it when	People use it occasionally, on a link you send them	You need the stores and one codebase	Heavy hardware use or platform-specific design

The question that decides it: does someone need to find this app in the App Store, or will you always be the one handing them the link? Internal tools for your own staff almost never need a store listing. Customer-facing products with repeat weekly use usually do. Our longer breakdown of native versus cross-platform covers the engineering trade-offs, and web app vs website vs mobile app covers the category confusion that causes most bad decisions here.

One Minnesota-specific note. If you run a 245D or HCBS agency and the app you have in mind is visit tracking, stop and check the state requirements first. Minnesota’s Medicaid program has electronic visit verification rules and an approved path for meeting them, and paying a developer to build a parallel system you then have to reconcile is a genuinely expensive way to solve a problem the state already solved.

Phase 4: how should the build actually run?

In slices, with working software every two weeks. Not “design phase, then a four-month silence, then a demo.”

A slice is a thin vertical cut through the whole product. Week two might be sign-in working against the real backend. Week four might be the list screen pulling real records. Week six might be the core action writing back to the database. Each one is something you can open on your own phone and press.

This matters for a reason that has nothing to do with software philosophy. If you can see working software every two weeks, you can stop the project at any point and still own something. If the first thing you see is at month four, you have handed over half the money on faith. Ask any developer you are considering whether you will have a running build on your device in the first month. The answer tells you a lot.

Three practical rules for this phase:

• You need one decision-maker on your side. Not a committee. Every extra approver adds days per question, and app builds run on dozens of questions.
• Say no in writing when you defer a feature. “Not in version one” is a decision, and it should be recorded, or it will come back in week ten as a surprise.
• Get test builds on real devices. TestFlight for iOS, an internal track on Google Play for Android. A simulator on a developer’s laptop is not a test.

Phase 5: what actually happens at app store submission?

This is where first-time app owners lose weeks they did not plan for. Two facts to start with. The Apple Developer Program costs $99 per year, and a Google Play developer account is a one-time $25 registration fee. Neither store will publish your app just because you paid.

Apple’s review is a human reading your app against published guidelines. The rejections that hit small business apps most often:

• Guideline 4.2, minimum functionality. If your app is essentially your website in a wrapper, it gets rejected. This is the single most common rejection for small business apps, and it is the reason “just turn our site into an app” is not a project.
• Guideline 5.1.1, account deletion. If users can create an account in your app, they must be able to delete it from inside the app. Not by emailing you.
• Guideline 3.1.1, in-app purchase. Selling digital content or subscriptions consumed in the app generally has to go through Apple’s payment system, with the platform commission that comes with it.
• Broken or incomplete builds. Placeholder text, a crash on a specific device, a login that reviewers cannot get past because you did not give them a demo account.

Both stores also require privacy disclosures. Apple has privacy labels on the App Store listing, Google Play has a data safety section, and both must accurately describe what data you collect and share. Fill these out yourself with your developer, do not guess, and do not let anyone check boxes to make the form go away. Getting it wrong is a compliance problem, not just a listing problem.

You will also need a privacy policy at a public URL, an app icon, a set of screenshots at the sizes each store requires, a description, and a support URL. And if you are opening a brand new personal Google Play developer account, Google requires a closed testing period with a group of real testers over a stretch of days before you can apply for production release. That requirement alone has pushed launches back a month for people who found out about it the week they wanted to ship.

Plan two to four weeks of slack between “the app is done” and “the app is public.” Do not book a launch event before you are approved.

Phase 6: launch is where the cost starts

The app going live is the beginning of the spending, not the end of it. Budget 15% to 25% of the build cost per year, every year, and know what it buys.

Operating systems update annually and break things. Frameworks and dependencies need patching. Apple periodically requires apps to be rebuilt against a current SDK to stay in the store. Google Play raises its target API level requirement on a schedule. Servers, databases, push notification services, and error monitoring all have monthly bills. And people will find bugs you did not.

Skip two years of this and you are not maintaining an app anymore, you are planning a rebuild.

What should the budget actually look like?

Here is a realistic allocation for a $60,000 first-year app program, which is a mid-range cross-platform build plus a year of running it. The pattern matters more than the total. Scale it to your own number.

Line item	Share	On $60,000
Phase 0 validation	3%	$1,500
Prototype + user testing	8%	$5,000
UI design and design system	12%	$7,000
App build, front end	33%	$19,500
Backend, API, admin tools	17%	$10,000
QA, real devices, store submission	7%	$4,500
Analytics and instrumentation	2%	$1,500
First 12 months of maintenance	18%	$11,000

Two things people get wrong reading this table. The first is treating the last row as optional, which is how apps die eighteen months after launch. The second is assuming writing app code is most of the invoice. It is a third. The rest is deciding what to build, designing it, connecting it to other systems, testing it, and getting it past two review processes. Our app cost breakdown goes deeper on where each dollar lands, and the published ranges are on the pricing page.

What are the five most expensive mistakes?

1. Building before validating. The most expensive line in app development is a finished feature nobody opens. Phase 0 costs under $1,500 and routinely saves the whole budget.

2. Feature creep. Every “while we are in there” adds build cost now and maintenance cost forever. The defense is the one-job rule and a written deferred list.

3. A fixed-price contract on unclear scope. Fixed price is fine for discovery, a prototype, or a design phase, because those have defined outputs. On a vague full build, the developer prices in risk, then spends the project defending the scope line instead of solving your problem, and you spend it filing change orders. Fix the price on the early phases, then price the build from what those phases produced. The questions to ask before hiring a developer apply here almost word for word.

4. No analytics in version one. If you cannot see how many people finished onboarding, completed the core job, and came back in week two, every decision you make for the next six months is a guess. Instrument three events before launch, not after.

5. No maintenance budget. See Phase 6. This is the one that turns a $45,000 asset into a $45,000 write-off.

When should you not build an app at all?

If people interact with your organization a few times a year, you do not need an app, you need a fast website. Nobody installs software to check your hours, read a program description, or make one donation. A well-built nonprofit or small business site does those jobs better, costs a fraction of an app, and does not require anyone to download anything.

If the real problem is internal, look at a web app or internal tool before a mobile app. It skips both app stores entirely, updates instantly, and works on a laptop, which is where most of your staff already are.

And if your website is slow, hard to use on a phone, or invisible on Google, fix that first. Sending app traffic to a broken funnel is expensive. Why your website is slow and website or app are the two pieces to read before you commit a five-figure budget.

Where to start

Pick the validation test that fits your situation this week and run it. If it comes back yes, the next spend is a prototype, not a build.

If you want a second opinion on whether your idea needs an app at all, get in touch. We build mobile apps out of our Edina office, and we tell a fair number of people that a website or a spreadsheet is the better answer. That conversation is free either way.