Questions to Ask an App Development Company

Every app development company will tell you they are experienced, professional and affordable. The pitch deck is not where the differences show. They show in the answers to precise questions, and especially in the questions the company asks you back.

This article gives you the questions, organised so that you can work through them in one or two meetings, and for each group describes what a good answer sounds like and what should worry you. It is written for Nigerian business owners and founders evaluating agencies; if you are hiring an individual developer, the related article on finding a developer covers the personal vetting steps. Use it alongside a written brief, because the quality of a company's answers depends on the quality of your questions about your own project.

Before the meeting: what to prepare

Companies can only answer well if you ask well. Bring:

• A one-page brief: what the business does, who the users are, the Must features, the preferred app form, integrations and a budget band.
• Rough screen sketches if you have them.
• Your own list of unknowns ("we are not sure whether to build for iOS yet").
• A note of which questions below matter most for your project (payments, data, offline use).

Send the brief in advance. A company that reads it and arrives with questions is already telling you something.

Questions about understanding your business

1. What do you understand our app needs to do, in your own words?
2. Who do you think the primary user is, and what is the one thing they must be able to do?
3. What in our brief is unclear, risky or likely to change?
4. Have you built for businesses like ours (same industry or same type of user)? Show us.
5. What would you cut from our feature list for a first version, and why?

Good answers restate your business accurately, identify a specific risk you had not mentioned, and suggest cutting something. Worrying answers repeat your brief back to you, praise the idea, and add features.

Questions about process and communication

1. Walk us through your process from signing to launch. What are the stages and what do we receive at each?
2. How often will we see working software, and on what devices?
3. Who is our single point of contact, and how quickly do you respond to messages?
4. How do you handle a change we request mid-project? What does it cost and how is it approved?
5. What do you need from us, and by when, for the project to stay on schedule?
6. What happens if we are slow to give feedback or content?
7. How do you test? On what phones? On slow connections?

Good answers describe a repeatable process with demos every one or two weeks on real devices, a named contact, a written change-request procedure, and a candid list of what they need from you. Worrying answers promise a finished app in an unrealistic time with no interim demos, or say changes are "no problem" without a process.

Questions about the team

1. Who exactly will work on our project: names, roles, and how much of their time?
2. Are any of them contractors or subcontractors? Where are they based?
3. Who is the most senior technical person reviewing the work?
4. What happens if a team member leaves mid-project?
5. How many projects is the team running at the same time?

Good answers name people, explain roles honestly (including subcontractors), and describe how knowledge is shared so one departure does not stall the project. Worrying answers are vague about who does the work, or the salesperson cannot say who the developers are.

Questions about technology

1. What technology do you recommend for our app and why? What are the trade-offs?
2. Will the app work well on low-end Android devices and on poor connections?
3. Which Nigerian payment gateway do you recommend, and have you integrated it before? How do you handle bank-transfer confirmation delays and failed transactions?
4. How will you handle notifications (push, SMS, WhatsApp) and what do they cost to run?
5. Where will the app be hosted, in whose account, and what will it cost per month in naira terms?
6. How do you secure user data, and how does your approach fit the Nigeria Data Protection Act 2023?
7. Will there be an admin dashboard, and what can we do in it without calling you?
8. How is the code structured so that another developer could take it over?

Good answers justify the recommendation in terms of your users and budget, admit trade-offs, describe specific experience with local gateways and their edge cases, and put hosting in your name with an estimated naira running cost and a note about exchange-rate exposure. Worrying answers recommend whatever they always use without reference to your needs, or cannot explain what happens when a transfer is debited but not confirmed.

Questions about cost and payment

1. What exactly is included in the quote, and what is excluded?
2. Can you itemise the quote by design, front-end, back-end, integrations, testing and launch?
3. What third-party costs will we pay separately (hosting, domain, store accounts, SMS, gateway fees)?
4. What is the payment schedule, and what is delivered at each milestone?
5. What is your rate for work outside the scope after launch?
6. What is the warranty period, and what does it cover?
7. If the project runs late for reasons on your side, what happens to the price?

Good answers provide an itemised quote, a clear exclusions list, milestone payments tied to deliverables (for example 30/30/30/10), a stated post-launch rate, and a warranty of several weeks. Worrying answers ask for most of the money upfront, cannot itemise, or treat every exclusion as a surprise.

Questions about ownership and legal matters

1. Will we own the source code, designs and documentation outright on final payment? Will the contract say so?
2. Will all accounts (domain, hosting, app stores, payment gateway, third-party services) be registered in our business's name?
3. Do you use any licensed or third-party components we would need to keep paying for?
4. Do you sign a non-disclosure agreement before detailed discussions?
5. Which law governs the contract, and how are disputes resolved?

Good answers are an unhesitating yes on ownership and accounts, in writing, with any reusable libraries the company retains clearly identified and licensed to you. Worrying answers hedge on ownership, want accounts in their name "for convenience", or have no standard contract. A related article covers what the contract itself should contain.

Questions about launch, maintenance and support

1. Who handles app-store submission, and what do you need from us (developer accounts, listing assets, privacy policy)?
2. What does maintenance cost per month or year, and what does it include (OS updates, security patches, small changes, monitoring)?
3. How quickly do you respond if the app goes down or payments fail after launch?
4. Will you provide training on the admin panel and written documentation?
5. If we want to move to another developer later, what will you hand over and how?

Good answers describe a launch checklist, a maintenance plan with a stated indicative cost (often 15–25% of build cost per year, or a monthly retainer), response times for critical issues, and a handover package. Worrying answers treat post-launch as somebody else's problem or make handover sound difficult.

Questions to ask their previous clients

Ask the company for two client contacts and ask those clients:

• Did the project launch on time and on budget? If not, why?
• How did the company behave when something went wrong?
• Do you own your code and accounts?
• How is the app performing now, and who maintains it?
• Would you hire them again?

Do not ask companies for performance statistics or "results"; ask their clients about behaviour and outcomes in their own words.

The questions a good company will ask you

The strongest signal in any first meeting is what the company asks. Expect questions like:

• Who are your users, what phones do they use, and how do they pay today?
• What happens when a payment fails, a delivery is late or a user has no network?
• What have you validated already, and how?
• What is your budget band and your honest timeline?
• Who on your side will make decisions, and how fast?
• Is your business registered, and do you have a privacy notice?
• What does success look like three months after launch?

A company that asks none of these is planning to build what you said, not what you need.

Scoring the answers

Use a simple scorecard across the companies you interview. Score each area 0 (poor), 1 (adequate) or 2 (strong). This is a framework to organise judgement, not a formula.

A company scoring 0 on ownership should be excluded regardless of total. Among the rest, weigh the total against price; the cheapest company with a score of 9 is usually a worse buy than a mid-priced company with a score of 16.

What changes for Nigerian businesses

• Local payment experience is decisive. Ask about specific gateways, transfer confirmation, failed-but-debited transactions, and pay-on-delivery flows. A company that has only built for card-first foreign markets will learn these lessons at your expense.
• Device and network reality. Insist that testing covers low-end Android phones and poor connections; ask which phones they test on.
• Exchange-rate exposure. Hosting and services are USD-priced; ask for running costs in naira with an explanation of what moves with the dollar.
• Regulation. If your app touches payments, lending, health or transport, ask what the company knows about the relevant regulator's requirements. They should not give legal advice, but they should know where the lines are and advise you to verify with the regulator and a professional.
• Data protection. The NDPA 2023 makes you responsible for personal data; ask how the company builds for it and whether they can help with a privacy notice.
• Registration and accounts. Store accounts and gateways need a registered business; a good company will ask whether you are CAC-registered early.
• Trust signals. Ask to visit the office if they have one, or to meet the team on video. Companies exist on Instagram that do not exist anywhere else.

Example (hypothetical): two companies, same questions

This example is hypothetical and illustrates how the questions separate vendors; it does not describe real companies or Linestech clients.

A pharmacy chain in Lagos with six branches wants an app for prescription refills and delivery. It interviews two companies with the same brief.

Company A presents a portfolio, promises delivery in six weeks, quotes ₦4,500,000 with 60% upfront, and says all features are "no problem". Asked who will do the work, the account manager says "our developers". Asked about failed bank transfers, the answer is that the gateway "handles everything". Asked about ownership, they say the code is theirs but the client "can use it as long as they like".

Company B arrives having read the brief and asks how prescriptions will be verified, whether pharmacists need a separate interface, and what happens when a medicine is out of stock at the nearest branch. They recommend a web app for pharmacists and a cross-platform app for customers, suggest deferring delivery tracking, and quote ₦6,800,000 itemised, with 30/30/30/10 milestones and a six-week warranty. They name the designer, two developers and the project lead. They explain how they handle transfer confirmation with a pending state and a reconciliation view. Ownership of code and accounts is in the draft contract. They ask whether the chain has a privacy notice and note that health data needs particular care under the NDPA 2023.

Company B costs more. On the scorecard it scores 17 to Company A's 6, and Company A's ownership answer disqualifies it anyway. The pharmacy chooses B and cuts scope to bring the price down, which B had already suggested.

Mistakes to avoid in the evaluation

• Judging on the pitch deck. Portfolios show what was built, not how, or whether it launched on time.
• Skipping the ownership questions. They are the ones companies most hope you will not ask.
• Choosing the lowest price without reading exclusions. The cheap quote usually has the most exclusions.
• Not asking who will do the work. The salesperson is not the developer.
• Accepting "we handle everything" as an answer. Specifics or nothing.
• Not calling references. Five minutes with a previous client is worth an hour of presentation.
• Being flattered by agreement. The company that says your idea is perfect has not thought about it.
• Sending different briefs to different companies. Quotes will not be comparable.

Conclusion

The questions above are designed to move the conversation from claims to evidence: what the company understood, how it works, who does the work, why it recommends what it recommends, what the price covers, who owns the result and what happens after launch. Score the answers, call the references, weigh the questions they asked you, and exclude any company that hesitates on ownership. Do that and the choice usually becomes clear, and it is rarely the cheapest quote or the flashiest presentation.

If you would like to put these questions to Linestech, we are happy to answer them in writing against your brief, including an itemised quote, the team that would work on your project and our standard ownership terms.

Frequently asked questions

How many app development companies should I interview?

Two to four is usually enough. Fewer than two leaves you with nothing to compare; more than four consumes weeks and the extra information rarely changes the decision. Send the same brief to all of them and interview using the same questions so that the answers line up.

What is the single most important question to ask?

"Will we own the source code, designs and all accounts outright on final payment, and will the contract say so?" A hesitant answer to this question should end the conversation, because it affects everything you can do with the app afterwards, including changing developers.

Should I ask for a fixed price or hourly rates?

For a well-scoped first version, a fixed price with milestone payments is usually better for a business owner, because it caps the cost and ties payment to deliverables. Ask for a stated hourly or monthly rate as well, for changes and post-launch work. Time-and-materials suits projects whose scope genuinely cannot be fixed yet.

Is it a bad sign if a company suggests cutting my features?

It is one of the best signs available. A company that cuts scope is thinking about your budget and your launch, not their invoice. Ask them to explain each cut; the reasoning tells you how well they understand your users.

How do I check a company's client references honestly?

Ask for contacts, then ask those contacts about behaviour, not statistics: whether the project launched on time, what happened when problems arose, whether they own their code, and whether they would hire the company again. Do not rely on testimonials on the company's website; call people.

What if a company will not sign an NDA before discussing my idea?

Most reputable companies will sign a simple, reasonable NDA before detailed discussions, though some decline NDAs for very early conversations. A refusal to sign anything at any stage is a caution sign; an insistence on an extreme NDA from your side is also unhelpful. Keep the initial conversation general and sign before sharing the full brief.

Should the company be based in my city?

Not necessarily. Most app projects run well remotely with regular video demos. A local company helps if you want in-person workshops or need them to understand physical operations such as a warehouse or a clinic. Process, ownership terms and relevant experience matter more than the office address.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Corporate Affairs Commission (CAC)
• Nigeria Data Protection Act 2023 — NDPC
• Cloudflare Learning Center
• GitHub documentation