Complete Guide
When you actually need an app, how to choose a developer, what it costs, what the process looks like start to finish, and the mistakes that kill projects before they launch.
In this guide
This is the question most developers won't ask you because the honest answer sometimes kills the engagement. Most small businesses don't need a native mobile app. They need a mobile-responsive website that works well on phones. Those are different things.
A mobile-responsive website loads in a browser. A native app gets downloaded from the App Store or Google Play and lives on the device. The distinction sounds simple but the implications are enormous. Your customers have to find your app, download it, create an account, and keep it installed. The average app loses 77% of its daily active users within the first three days. Getting discovered in the App Store is its own SEO problem.
When a mobile-responsive website is enough: Your business model is transactional — people visit, buy something or book something, leave. Your users don't need offline functionality. Push notifications aren't central to how you engage customers. You don't need access to device hardware like the camera, GPS, or NFC. In all these cases, a fast, well-built mobile website will serve you better than an app you have to convince people to download.
When an app actually adds value: Push notifications are core to your engagement model (appointment reminders, order updates, loyalty points). You need offline functionality — inspectors, delivery drivers, field workers who operate without reliable cell service. You're building something where the native experience genuinely matters: camera integrations, GPS tracking, NFC payments, AR features. Or you're building a product people use daily, where the friction of opening a browser is a real UX cost.
The App vs. Website comparison walks through the decision tree in more detail if you're on the fence.
If you've decided you need an app, the next question is how it gets built.
Native development means a separate codebase for each platform — Swift for iOS, Kotlin for Android. The advantages are maximum performance and full access to every platform API the moment Apple or Google releases it. The disadvantage: you're effectively building two apps. Cost is roughly double, maintenance is double, and finding a developer who's senior in both stacks is either very expensive or very rare.
Cross-platform development (React Native, Flutter) writes most of the app once and compiles it for both iOS and Android. Performance is very close to native for most use cases — close enough that you won't notice the difference unless you're building something computationally intensive. The major advantage is cost: one codebase, one developer, one maintenance cycle. This is what ArdinGate Studios uses for the same reason we use hand-coded PHP on the web side: one coherent codebase, owned and understood by the developer who built it, maintained by the same person through the app's lifecycle.
No-code builders (Bubble, Adalo, FlutterFlow, Thunkable) let you build app-like things without code. They've improved significantly and are genuinely useful for prototypes, internal tools, or simple consumer apps with a limited feature set. The ceiling hits fast. The moment you need a custom data flow, a specific native API, or a backend that doesn't conform to the builder's data model, you're stuck — and you're renting the platform, meaning price changes and deprecations are outside your control.
The Custom vs. No-Code comparison breaks down when the no-code ceiling is actually a problem vs. when it's fine for your use case.
For a US-based small business, the default answer is: build for both, using a cross-platform framework.
iOS users in the US represent roughly 55–60% of smartphone users, but that number varies significantly by demographic. iPhone users tend to skew higher-income, which matters if your product has a purchase or subscription component. Android has more global market share, but for US small businesses targeting US customers, iOS penetration in income-bearing demographics is often higher.
Building for only one platform means leaving out a meaningful percentage of your potential users. Native builds for each would roughly double the budget. Cross-platform covers both without doubling the cost — which is the main reason it's the practical default for most small business apps.
Cases where you might consider one platform first: you're validating an idea and want to keep costs as low as possible, your user research shows overwhelming skew toward one platform, or you're building an enterprise tool where IT has standardized on one device type.
The iOS vs. Android comparison covers the US market split, revenue per user differences, and the technical implications of each choice in more detail.
App development pricing has the same confusing variance as web development — quotes for "an app" range from $2,000 to $200,000 for what sounds like similar scope. Here's why.
The honest drivers of cost:
The App Cost Estimator lets you build a rough estimate by selecting your platform, screen count, backend complexity, auth, and extras. Use it before getting quotes so you're calibrating what a realistic range looks like for your scope.
Typical ArdinGate Studios ranges: companion apps ($4,500–$6,500), standard utility apps ($6,500–$8,500), business apps with custom backend ($9,000–$14,000+). The Pricing page shows the full tier breakdown.
Hidden costs nobody mentions: Apple Developer Program ($99/year), Google Play Developer account ($25 one-time), post-launch bug fixes from user feedback, and annual OS compatibility updates — iOS and Android both release major versions every year and things break. Budget for at least one compatibility update per year after launch.
Understanding the build process sets expectations and prevents the most common client frustrations.
Discovery (1–2 weeks): You and the developer agree on scope — exactly what features, what the data model looks like, how authentication works, what the backend architecture is. This is where misaligned expectations get caught before any code is written. A good discovery phase produces a documented feature list and a timeline with milestones.
Design (2–3 weeks): Screen layouts and UI design in Figma or a similar tool. You review and approve before development starts. Changes are cheap in design; expensive in code.
Development (4–8 weeks depending on scope): The app gets built screen by screen, backend first, then UI. You should see a testable build (TestFlight for iOS, Firebase App Distribution or direct APK for Android) at regular intervals — not just at the end when there's no time to course-correct.
QA and testing (1–2 weeks): Functional testing on real devices, edge case testing, and App Store submission readiness review (Apple has specific requirements that will get you rejected if not addressed in advance).
App Store submission: Apple takes 1–3 business days for review. Google Play is typically a few hours to 24 hours. First submissions usually get rejected for something minor — missing privacy policy link, insufficient test credentials, a small UI issue. This is normal; plan for one revision round.
See the Process page for how ArdinGate Studios approaches each phase of a build.
App developers are harder to evaluate than web developers because the output lives in an App Store, not just on a website.
Find their published apps. Ask for App Store and Google Play links. Download them. Use them. If a developer can't point to live, published apps in the store, that's a significant red flag. A portfolio of Figma mockups is not a portfolio of shipped apps.
Check the ratings and reviews. Not as a strict pass/fail — every app gets some bad reviews — but as a signal of how the developer responds to problems and how stable the app was post-launch.
Look at the last update date. If a developer's most recent published app hasn't been updated in 2+ years, it probably means they're not maintaining it. Apps that go unmaintained eventually stop working as iOS and Android release new OS versions.
Ask about their App Store submission track record. First-submission approval rates are a proxy for how well they know Apple's and Google's guidelines. Experienced app developers know what gets rejected before they submit.
Ask for architecture reasoning. You're looking for a developer who can explain why they made specific decisions. "I chose Flutter because it gives us one codebase for both platforms, the performance is native-quality for your use case, and it's faster to iterate on when you want to add features later" is a better answer than "I know Flutter."
Most small business owners are surprised by the App Store approval process. Here's what to expect before you build, not after.
Apple Developer Program costs $99/year. Apple reviews every app and every update — there's no deploy-and-publish like a website. Review time is typically 1–3 business days.
Common Apple rejection reasons:
Google Play Developer costs $25 one-time. The review process is faster (usually a few hours to 24 hours) and the guidelines are slightly more permissive, but Google has significantly tightened review in recent years.
Account ownership: You can submit under the developer's accounts (managed) or under your own. With ArdinGate Studios' managed plans, we handle store listings under our developer accounts — which simplifies submission and updates. If you want to own the listings from day one, that's also an option. This decision should be made before development starts. See the Ownership page for how this works.
Annual OS updates: Apple and Google release major platform versions every year. Each release can introduce breaking changes, deprecated APIs, or new requirements. Plan for at least one compatibility update per year — it's maintenance, not a rebuild.
Launch day is not the finish line. Here's what happens in the weeks and months after.
Post-launch bugs. Real users hit edge cases your testing didn't catch. The contract should include a post-launch bug fix window (typically 30–90 days). This isn't scope creep — it's specifically for bugs from real-world usage that weren't caught in QA. Define it clearly upfront.
Annual OS compatibility. iOS and Android drop backward compatibility faster than most businesses expect. iOS in particular can break things that were working. Budget for at least one compatibility update pass per year — usually $500–$1,500 depending on what changed.
App Store maintenance. Listings need to stay current — updated screenshots when the UI changes, updated descriptions as your offering evolves, responses to user reviews. Managed listing maintenance is included in ArdinGate Studios' ongoing plans.
What you own. You own the code — full delivery on project completion. The App Store listings are either under your accounts or ours per the agreement. Backend infrastructure is typically under your accounts or migrated on handoff. The Ownership page explains how ArdinGate Studios handles this explicitly so there are no surprises.
Build focused, then iterate. Most small businesses make the mistake of launching with too many features and then having no budget for the post-launch learnings. A focused v1.0 that gets real user feedback is more valuable than a kitchen-sink build that runs out of money before launch.
A few patterns come up repeatedly — and they're all avoidable.
Building before validating. Spending $10,000 on an app before knowing if users will actually use it is an expensive mistake. Before building, validate the core use case: can you get 10 people who aren't friends or family to say they would download and use this? If not, the app concept needs work before it needs code.
Scope creep. "While you're in there, can you add..." is the budget killer of app development. Every feature added mid-build is more expensive than it would have been if planned upfront, because the developer has to fit it into existing architecture. Define scope upfront, add a clear change order process, and treat mid-build additions as budget items, not freebies.
Choosing the cheapest bid. There are app shops charging $2,000 for a "complete app." These typically produce something that crashes, gets rejected from the App Store, or is built on a template that can't be extended. If the quote is substantially below market, ask why. The economics are real: an experienced developer can't build a 10-screen app with a custom backend for $2,000 and stay in business.
Ignoring App Store guidelines until submission day. Apple's review guidelines are public. If your app collects personal data, you need a privacy policy before you submit. If you're doing in-app purchases, Apple takes 30% and you must use their payment system. Experienced developers build with these rules in mind from day one.
No analytics from launch. Without analytics (Firebase Analytics, Mixpanel, or similar), you have no idea what users do in the app, where they drop off, or what features are actually being used. Build analytics in from the start — it costs $300–$700 and the data is essential for deciding what to build next.
If you've read this far and you're ready to move, here's what to do before you call anyone.
Define the one thing your app does better than a website. If you can't articulate it, the app isn't the right tool. Push notifications? Real-time GPS tracking? Offline job management for field workers? Write it down in a sentence.
Write a 1-page feature list. Not a formal spec — just a list. What does the app do? What are the main screens? Does it connect to an existing system? Who are the users? This takes 30 minutes and dramatically improves every developer conversation you'll have.
Calibrate your budget with the cost estimator. Run your feature list through the App Cost Estimator before any calls. If your budget is $3,000 and the estimate is $9,000, that's important to know before you schedule discovery conversations.
Decide on account ownership upfront. Do you want App Store listings under your own accounts from launch day, or are you starting managed and doing a handoff later? Both are fine — just decide before development starts.
When you're ready, get in touch to start a conversation. The first step is a 20-minute discovery call to understand your use case, identify scope, and give you an honest read on what it'll take to build — no obligation, no pitch deck.
