What Do App Developers Need From Me to Start?
Projects stall on missing decisions and missing words far more often than on missing technical detail.
Short answer
A developer needs four things from you before code starts: a clear statement of what the app must do at launch, the decisions only you can make, the accounts and access the work depends on, and one person who answers questions within a day. Everything else, wireframes, specifications, technical opinions, is optional and often unhelpful. Projects stall on missing decisions and missing content far more often than on missing technical detail.
The one page that starts a project well
Before anything else, write a page containing five things.
The problem, stated as a situation someone is in rather than as a feature. Who has it, how often, and what they do today instead.
The three things the app must do at launch. Not the roadmap, the launch. Everything else goes on a second list titled “later”, which is the most useful document in the project because it lets people say yes to good ideas without disturbing the schedule.
Who the user is, specifically enough to picture. A shift manager at a logistics depot behaves differently from a consumer browsing at home, and interface decisions follow from that.
What success looks like six months after launch, in a number you would actually check.
Any constraint that is not negotiable: a launch date tied to an event, a regulatory requirement, an existing system the app must talk to, a budget ceiling.
That page takes two hours and is worth more than a fifty-page specification, because it lets a competent team make a hundred small decisions in the direction you would have chosen.
| What clients often prepare | What developers actually need |
|---|---|
| A long feature list | The three launch features and a “later” list |
| Wireframes drawn in a slide tool | The problem and the user, in plain words |
| Technical suggestions | Constraints that are genuinely fixed |
| A competitor to copy | What your users do today instead |
| A deadline with no reason | The reason behind the deadline |
The decisions only you can make
A good team will ask, and a project moves at the speed of these answers.
Which flow, when two are reasonable. Sign-in before or after browsing, one long form or three short screens, a list or a map as the default view. These are business decisions in technical clothing and the person who knows the customer should make them.
What to cut when the estimate comes back higher than the budget. Providers can advise and cannot decide, because only you know what the business needs to prove next.
What happens in the awkward cases: a user with no data yet, an order that fails halfway, a person who deletes their account and comes back. Every one of these becomes a screen, and someone must decide what it says.
How money works, if the app takes payments. Prices, trial length, what happens when a subscription lapses, refund policy.
Access and accounts, gathered before week one
The list is short and each item can block work for days if it appears late.
An Apple Developer account under your company, which requires a legal entity and a verification step that takes time, and the Apple Developer Program membership at 99 US dollars per year. This blocks TestFlight as well as submission, so it belongs in week one.
Access to any system the app must integrate with: API credentials, a sandbox environment, a technical contact who answers.
Brand assets, if they exist: logo files, fonts and their licences, colour definitions. If they do not exist, say so early, because designing a brand mid-build is a separate project.
Legal text: privacy policy, terms of service, and any regulated disclosures. These are needed before submission and often before design, since onboarding screens reference them.
Content: the words in the app. Onboarding copy, empty-state messages, error text, notification text and the App Store description. This is the single most underestimated client deliverable, and it is needed during design rather than at the end.
Privacy answers. Apple requires an accurate declaration of what data the app collects and how it is used, and only you know why you want a phone number or a birth date. Deciding this early is easier than reverse-engineering it the week before submission.
| Item | Needed by | Blocks if late |
|---|---|---|
| Apple Developer account | Week 1 | TestFlight and submission |
| Integration credentials and sandbox | Before backend work | Whole feature areas |
| Brand assets or a decision to create them | Before design | Design cannot start properly |
| Privacy policy and terms | Before design finalises | Onboarding screens, submission |
| App copy and empty-state text | During design | Screens ship with placeholder text |
| Test users for TestFlight | Week 8 or so | The most useful feedback round |
What a developer will ask that you may not expect
Four questions come up on almost every project and catch clients unprepared, so they are worth thinking about now.
What happens to a user’s data when they delete their account? Apple requires in-app account deletion for apps that create accounts, and the interesting part is what deletion means for your business: orders you must keep for tax purposes, content other people replied to, a subscription still running. Somebody has to decide, and the decision has legal and product consequences.
Who are the roles? Almost every business app has more than one kind of user, a customer and a staff member, an owner and a team, and the moment there are two, permissions exist. Sketching the roles on paper takes ten minutes and prevents a data model built for one kind of person.
What is the worst case if something goes wrong? A wrong price shown, a duplicate booking, a notification sent twice. Your tolerance decides how much validation and how many safeguards the build needs, and it varies enormously by business.
What already exists that this must not break? An old website, an existing customer list, a booking system, a spreadsheet somebody depends on. These are usually discovered late and always matter.
How to be a good client during the build
Answer within a day, or say when you will. A named decision-maker with authority is worth more to a timeline than any amount of process.
Give feedback on behaviour, not taste, and be specific. “The list feels slow when I scroll fast on my old phone” is actionable; “it feels a bit off” is a puzzle. Screen recordings are the highest-bandwidth feedback available and take thirty seconds.
Install every build. If the team ships a TestFlight build each week and nobody opens it, feedback arrives at the end when changes are expensive rather than in the middle when they are cheap.
Keep new ideas on the “later” list rather than in the build. Good ideas arrive constantly during a project and almost none of them need to ship at launch.
Trust the technical decisions and interrogate the product ones. Which database, which architecture, how to structure the code, these are the team’s to make. What the app should do, who it serves and what ships first are yours.
The kickoff meeting, and what to bring to it
One meeting decides the tone of a project, and it works best with an agenda rather than a presentation.
Bring the one page and read it aloud. Reading it out loud catches vagueness that reading silently does not, and the team’s questions in the following ten minutes tell you how carefully they are listening.
Bring your three worst-case worries. Cost overrun, a missed date, an app nobody uses. Naming them lets the team say how their process handles each, and a team with no answer for any of the three is telling you something.
Agree the mechanics before the work: who is the decision-maker, how often builds arrive, where questions get asked, what the weekly rhythm is, and how scope changes are handled. Ten minutes here prevents most of the friction later.
Leave with three dates: when discovery ends, when the first installable build arrives, and when submission is planned. Those three are enough to know whether a project is on track without a project plan nobody reads.
What developers should give you in return
The exchange runs both ways, and a team that asks for everything above should also provide a screen inventory the estimate is built from, a weekly build you can install, a written change process for scope, source code in a repository you own from the start, and a plain answer when something is going wrong. Any of those missing is worth asking about early rather than after it becomes a pattern.
Where this does not apply
If you are hiring a developer to work inside your existing engineering team, most of this belongs to your product manager instead, and the developer needs tickets rather than a founder’s page. If the app is a straight port of an existing product, the current app is the specification and the questions shift to what should change rather than what to build. And if you genuinely do not know what the app should do yet, the honest first step is a discovery engagement rather than a build, because paying a development team to figure out your product is the most expensive way to answer that question.
If you have the one page and want it turned into a screen inventory and a real estimate, book a free app idea call and we will go through it with you.
FAQ
What do app developers need from me to get started?
A one-page brief with the problem, the user, the three things the app must do at launch, what success looks like and any fixed constraint. Then the decisions only you can make, the accounts and access the work depends on, including an Apple Developer account and any integration credentials, and one named person who answers questions within a day. Detailed specifications and wireframes are optional.
Do I need wireframes before hiring a developer?
No, and homemade wireframes often cost more than they save, because they encode interface decisions before anyone has thought about the flows and a team then has to unpick them politely. What genuinely helps is a clear description of the problem, the user and the three launch features. If you have sketches, share them as thinking rather than as a specification.
What do clients most often forget to provide?
The words. Onboarding copy, empty-state messages, error text, notification wording, the App Store description and the legal pages. Clients assume these come at the end; in reality they are needed during design, because a screen cannot be finished around placeholder text. The second most forgotten item is the Apple Developer account, whose company verification can take days.
How involved do I need to be during development?
Enough to answer questions within a day and to install every build. That usually means a few hours a week rather than a full-time role. The two habits that make the biggest difference are giving specific feedback about behaviour rather than taste, ideally with a screen recording, and keeping new ideas on a later list instead of adding them to the current build.
What should a developer give me in return?
A screen inventory the estimate is built from, a weekly build you can install on your own device, a written process for handling scope changes, source code in a repository you own from the start, and a straight answer when something is going wrong. If any of those are missing, ask early rather than waiting to see whether it becomes a pattern.