--- title: What Do I Need to Develop an App? description: Planning an app? Discover the key requirements to make an app work, from validated ideas and budgets to platforms, legal checks and post-launch planning. image: https://weareaffective.com/hubfs/learning-centre-images/what-do-i-need-to-develop-an-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-do-i-need-to-develop-an-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What Do I Need to Develop an App? Table of Contents A client came to us with a well funded plan for a sports club app. It would handle finances, games, schedules and players, across several sports at once. We advised launching with one sport, on one platform, as a small first release, and building out from there. They said no to all of it. Nothing was going live until everything was ready. > Budget, sign-off and scope decide more app projects than the quality of the idea. That conversation is where most people meet the real requirements to make an app. The idea is rarely the difficult part. The difficult part is everything sitting around it, including who can sign things off, what your budget honestly buys, which rules apply to your category, and what you're willing to drop when the first estimate lands. So this isn't a list of software and skills. It's the set of things we've watched make or break projects we've worked on, from a baby monitor built across a consortium of countries to a currency exchange app that Apple refused to approve. Some of these you can sort out in an afternoon. Others take months, and they're the ones people leave until it's too late to change them cheaply. ## A Validated Problem, Not Just an Idea We worked on a product aimed at African communities living abroad, designed to help people keep a close connection with their home communities. Technically it was fairly straightforward and we were comfortable building it. Before any of that, we ran focus groups with the target market, and the answer came back plainly. There just wasn't the desire for that kind of product. Those focus groups cost a fraction of the build they prevented. Research of that sort is the cheapest money anyone spends on an app, and it's the money people skip first, usually because they already know what they want to hear. According to [CB Insights](https://www.techqware.com/blog/10-common-mistakes-founders-make-before-starting-app-development), 42% of startups fail because there's no market need for what they built. #### Requirements to make an app worth building Validation means talking to the people you intend to charge, in enough depth that they can tell you no. A survey with friendly questions gives you a friendly answer. Sitting a group of real users down in a room gives you something you can act on. - What do these people do today instead of using your app? - How much effort does that cost them, honestly? - What would have to be true for them to switch? - Who's going to pay, the user or somebody else? ## Discovery Before Design A property developer came to us wanting a concierge app for their high-rise properties. They arrived with a suggested budget and a formed idea of the product, and what they really wanted was a quick validation rather than a full scoping. We persuaded them into a [proper discovery phase instead, with focus groups](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) and user workshops. What we found was that the product was going to be a lot simpler than they'd pictured. A good number of the planned features never made it in. We focused instead on creating a human connection with the product rather than replacing a whole load of systems the building already ran perfectly well. They got a better product for less money. Our discovery goes further than a feature list, because we're working out who the brand is as a person, what the product is as a person, and how it behaves towards people. That sounds soft until you see what happens without it. On a dating app built around verified profiles and keeping bots out, the client wanted to skip discovery on the messaging side and spend it all on onboarding. We ended up building a generic messaging feature that allowed automated and fake messages, which quietly undid all the verification work. Rewriting that section cost around £15,000 of extra budget and about two months of extra work. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## A Budget That Matches the Experience You Expect We worked on a football-focused social media app where the client wanted a lean first release, but had a budget that was a long way from the premium experience they pictured in their head. A lower budget means less flexibility and a tight focus on getting something launchable to market. This client wanted the low budget without the limitations that come with it. We had several conversations trying to line their expectations up with the financial reality. We did reach a finished product, with compromises on features, partly because they chose to spend budget on areas we'd rated as lower priority. > A smaller budget buys fewer things done properly, and choosing which things is the whole job. Design and research feel like the expensive part because they come first. Build is where the money actually goes, and [Create Anything, 2025](https://www.createanything.com/blog/mobile-app-development-cost) put development at 50 to 70 percent of total spend. That shape matters when you're deciding how many rounds of design iteration you can afford before anything gets written. Be straight with your partner about the number. A real figure lets us design to it. A number held back so we'll quote low only moves the pain to month four. ## A Decision-Maker Who Can Actually Sign Off On a [fitness and wellness product with two co-founders](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) who were new to app development, we went through the same loop more than once. We'd get sign-off on a design, start building, and then they'd walk the approval back, saying they hadn't understood that this was what would actually be built. There was no real consensus between the two of them. Approval was given to be polite rather than as a decision anyone meant. We kept warning them that budget was going on design iterations that wouldn't have a material impact on the product. That fell on deaf ears, and the project never got past design and research, because the money ran out there. Agree before kick-off which single person gives final sign-off, and what sign-off means. Write it down. "Approved" should mean we build it, not we quite like it. Two founders who disagree quietly are more expensive than two founders who argue openly. If your co-founders see the product differently, settle that between yourselves early, because a design review is a slow and costly place to have the conversation. One of the plainer app development requirements is a named person with the authority and the appetite to make unpopular calls on time. ## Platform and Device Decisions Platform choice gets treated as a technical detail and it's really a [app planning and strategy](https://weareaffective.com/app-planning-strategy) decision. It sets your audience, your cost and how fast you learn anything useful. [IBM](https://www.ibm.com/think/topics/mobile-application-development) put Android at around 70% of smartphones globally, which matters enormously in some markets and barely at all in others. | Choice | Fits when | Watch for | | --- | --- | --- | | iOS first | UK and US lifestyle audiences, paid products | Apple review risk sits on your critical path | | Android first | Global reach, wide device spread | Testing load across many handsets | | Both at launch | Funded, proven demand, mature team | Roughly double the build and double the bugs | | Mobile web first | Testing demand, no device features needed | No store presence, weaker re-engagement | Devices matter as much as platforms. On that product for African communities abroad, the second problem after the research was hardware. The capabilities of the phones commonly used in those countries at the time were very limited, and delivering half the intended experience on them would have been incredibly challenging. Work out the real device list for your real users before anyone designs a screen. Average phone age, storage, connection quality and screen size all change what's sensible to build. ## Scope You Are Willing to Cut Back to that sports club app. The client pushed back through the whole process, saying they wanted to launch everything. No launching with a single sport. No launching on a single platform first. No MVP. Everything, finished, together. That position is what sets up [runaway scope, because nothing is ever quite finished](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) and there's no date that forces a decision. Working with the development process, and listening to the people you hired for their experience of it, is one of the better predictors of whether an app ever reaches the store at all. #### Requirements to make an app launchable Write your feature list, then mark each item as launch, later or never. The "later" column is where the project lives or dies. [Agile Soft Labs](https://www.agilesoftlabs.com/blog/2026/03/how-to-build-minimum-viable-product-mvp), publishing their own project data, put a well-scoped MVP at eight to sixteen weeks, with three to five features at the short end. Cut features before you cut quality. A bad first experience makes people far less likely to come back, so three things done beautifully beat eight things done adequately. Offline support is a good test of this. It's worth building when it's genuinely central to how people use the product, and worth dropping when it's there because it sounded thorough in a planning meeting. ## Legal, Regulatory and App Store Constraints We worked on a currency exchange product that let people transfer leftover foreign currency to each other at an agreed rate, skipping the fees a bank or bureau would charge. Partway through the project we found out that legal regulation, and Apple's rules in particular, weren't going to allow [peer-to-peer transfers of that kind](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know). The product had to become location-based and in person, so users met up and physically exchanged currency. That's a pivot you'd rather discover in week two than week twenty. > Platform rules can change what your product is, sometimes halfway through the build. On a currency exchange app project, the client's product was rejected by Apple repeatedly even though it met every stated requirement. Each time we fixed the objection, a new one appeared. Apple eventually raised money laundering and criminal use, so we capped transactions at €150, which should have settled it. They rejected it again. The client ran out of budget and walked away. Apple Pay and other payment services launched shortly afterwards, and we believe the rejections were tied to that. Check the store guidelines and your regulatory position before design, not after. Payments, health data, age verification, gambling mechanics and user-generated content all carry rules that shape the product itself. ## A Team Structure and a Way of Working Together On the baby monitor project, the work was spread across a consortium of teams in the UK, elsewhere in Europe and further afield. Keeping everyone aligned on what each part could actually do, and what each part needed from the others, was the hardest ongoing job on the project. Nothing technical came close. Distributed work isn't the problem by itself. The problem is unclear ownership across time zones, where a question asked on Tuesday afternoon gets answered on Thursday morning and the build waits in between. So you need an agreed rhythm, a short list of people who speak for each team, and one place where decisions get recorded. On your side, three things matter more than the org chart. Someone who knows the business inside out and can answer domain questions quickly. Someone who can make the final call. Someone who can give feedback in a usable form, which means on the thing in front of them rather than on the idea of it. Among the things to consider when developing an app, this is the one people assume will sort itself out. It doesn't. Agree the working pattern in the first week and hold it. ## Hardware, Third Parties and Things You Do Not Control On that same baby monitor build, we had no access to the physical hardware or test devices. So we created our own version of the monitor to work against, tested everything we made against it, and handed the work over to the hardware team. It worked, and it added cost and time that nobody had planned for at the start. Most apps now depend on parts somebody else owns. Payment providers, maps, messaging, analytics, booking systems, loyalty platforms, delivery partners. Each one comes with its own rules, its own downtime and its own change schedule. The planning error we see most is treating integration like a small job. Connecting to an existing API is a different piece of work from building one, and the two get quoted as though they're the same thing. Documentation gets found to be out of date. Sandbox environments behave differently to live ones. Rate limits appear. Apple is a third party too, as that currency exchange client discovered. If your product depends on a platform's permission, build time and money into the plan for the possibility that permission takes several rounds. ## Testing Across Real Devices and Real Conditions Testing on the newest handset, on office wifi, with a clean account, tells you almost nothing about how your app behaves for the person who'll actually use it. Our baby monitor work only held together because we built a physical rig to test against rather than trusting a simulator and hoping. Real conditions mean an older phone with low storage, a patchy signal on a train, a half-charged battery, a user who's tired and distracted. That's when a two-second delay becomes a close-the-app moment. 1. Internal testing on the real device list for your audience, not the team's phones. 2. Edge cases and failure states, including no connection and a failed payment. 3. Accessibility checks with larger text, screen readers and one-handed use. 4. A closed beta with people from the target market who don't know you. 5. A staged rollout, so a problem reaches hundreds of users rather than thousands. Watch five real users open your app for the first time without helping them. Say nothing for the first thirty seconds, however uncomfortable that gets. You'll learn more than any report will tell you. Budget testing time properly. It's the line that gets squeezed when dates slip, and it's the one protecting everything else you've paid for. ## A Launch Plan and App Store Presence We worked on a gifting and wishlist platform where the client was very hesitant to do anything with App Store Optimisation. Their thinking was reasonable on the surface, because the product was social and group-based, so word of mouth would carry it. Referral still has to land somewhere, and where it lands is a store listing. Our view then and now is that the listing does a job no referral can do. People really need to understand what the product is about from the very first screen, which means the icon, the copy, the category and the screenshots all have to be immediately clear. > A good listing lets people rule themselves out before they download, which is a favour to everyone. We don't want people to download the app and then realise it isn't for them at all. Those users churn within a day, drag your ratings down and tell the store your product disappoints people. The ones who do download should already be sold. Plan the first four weeks in advance. Decide who gets told, in what order, and what you'll do with the first wave of reviews, because early ratings shape everything that follows. ## Budget for What Happens After Launch Launch is the point where costs start, rather than stop. Operating systems update twice a year and break things. Third parties change their terms. Users ask for the one feature you cut. Reviews arrive and need answering. The money for all of that has to exist on day one. That currency exchange client ran out of budget while still fighting to get approved, and the product was abandoned with the build essentially finished. Our dating app rewrite came out of a contingency that thankfully existed, at roughly £15,000 and two months. - Hosting, licences and third party fees, which scale with usage - Store compliance work for each new OS release - Support for users, including the slow drip of odd edge cases - A development retainer for fixes and small improvements - A contingency for the thing nobody predicted A sensible rule is to hold back a meaningful share of your total budget for the first year of life after launch. Spending every penny getting to the store leaves you with a product you can't maintain, and an app that stops working on new phones disappears faster than one that was never launched. ## Conclusion The requirements to make an app are mostly decisions, and most of them get made before any code exists. A validated problem rather than a comfortable assumption. Discovery that's allowed to change the plan. A budget that matches what you picture. One person who can genuinely sign off. Platform and device choices made for your users rather than your own phone. Scope you're prepared to cut. Rules checked early. Testing on real handsets in real conditions. Money held back for the year after launch. The projects we've seen go wrong rarely went wrong on the technology. The sports club app stalled on an all-or-nothing launch. The fitness product ran out of money in design because nobody could decide. The currency exchange app died waiting for Apple. The concierge app for that property developer went well because the client let research change their mind, and they got a simpler product for less money. If you're weighing up the things to consider when developing an app and you want a straight read on what your budget buys and what you'd need to cut, we're happy to go through it with you. [Let's talk about your app project](https://weareaffective.com/get-started). ## Frequently Asked Questions What do I actually need before I start developing an app? You need a validated problem, a clear decision-maker who can sign things off, an honest budget and a scope you are willing to cut. The idea itself is rarely the hard part, it is everything surrounding it that decides whether the project succeeds. Why should I launch with a small first release rather than the full product? A smaller first release gets you real feedback from real users before you spend the bulk of your budget. Waiting until everything is ready usually means you spend more money building features nobody asked for, and you learn nothing until it is too late to change cheaply. How do I validate my idea properly? Talk to the people you intend to charge, in enough depth that they can comfortably tell you no. Focus groups and in-person conversations give you something you can act on, whereas a survey full of friendly questions will simply give you a friendly answer. Is market research really worth the cost? It is the cheapest money you will spend on an app and it is usually the first thing people cut. Research costs a fraction of a build, and CB Insights found that 42% of startups fail because there was no market need for what they built. What is a discovery phase and do I need one if I already know what I want? Discovery is a structured research phase that tests your assumptions before anyone designs or builds anything. Even clients who arrive with a formed idea often find the product should be far simpler than they pictured, which means a better result for less money. What questions should I be asking potential users? Ask what they do today instead of using your app, how much effort that genuinely costs them, and what would have to be true for them to switch. Also establish who is going to pay, the user or somebody else, because that shapes the whole commercial model. Can I skip discovery on parts of the product to save budget? You can, but you tend to pay for it later. On a dating app project, skipping discovery on the messaging side to focus spend on onboarding resulted in a generic experience that had to be reworked. What tends to derail app projects most often? Budget, sign-off and scope decide more app projects than the quality of the idea. Issues like regulatory rules for your category and app store approval can take months to resolve, so leaving them late makes them expensive to fix. ## Related Articles [![](https://weareaffective.com/hubfs/learning-centre-images/how-long-does-it-take-to-develop-an-app.webp)](https://weareaffective.com/learning-centre/how-long-does-it-take-to-develop-an-app) ### [How Long Does It Take To Develop An App?](https://weareaffective.com/learning-centre/how-long-does-it-take-to-develop-an-app) If you're reading this guide, you're probably wondering exactly how long it will take to bring... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How Do You Price Your App Without Losing Money?](https://weareaffective.com/hubfs/learning-centre-images/how-do-you-price-your-app-without-losing-money-featured-1.webp)](https://weareaffective.com/learning-centre/how-do-you-price-your-app-without-losing-money) ### [How Do You Price Your App Without Losing Money?](https://weareaffective.com/learning-centre/how-do-you-price-your-app-without-losing-money) Most app creators lose money on their first app—not because their idea was bad, but because they... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![how-much-does-it-really-cost-to-develop-a-mobile-game](https://weareaffective.com/hubfs/learning-centre-images/how-much-does-it-really-cost-to-develop-a-mobile-game.webp)](https://weareaffective.com/learning-centre/how-much-does-it-really-cost-to-develop-a-mobile-game) ### [How Much Does It Really Cost To Develop A Mobile Game?](https://weareaffective.com/learning-centre/how-much-does-it-really-cost-to-develop-a-mobile-game) Here's a fact that stops most people in their tracks: our [mobile game development costs breakdown](https://weareaffective.com/app-development-cost)... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.