20 Questions to Ask Any App Development Company

Ask an app development company 20 questions grouped by risk: ownership, price, timeline, technology, support, compliance and exit. The pattern in good answers is the same each time: a document, a number or a date, written into the contract. The pattern in bad answers is trust, adjectives and "we will sort that out later". Below are the questions, what a good and a bad answer sound like, and how we answer the ones that apply to a ready-made ReelShort clone and the platforms we sell.

This guide is about the company and the contract. If you are comparing demos, our guide to evaluating a white-label platform covers what to click in the product. If you are still choosing between buying, building and renting, start with white label vs custom build vs SaaS.

How to use this list

Send the list in writing before the sales call. Ask for answers in writing too. Written answers give you something to compare across companies and something to attach to the contract. A company that answers a question in a call but will not put it in an email has told you something.

1. Send all 20 to every shortlisted company. Do not tailor them. Comparison needs the same questions.
2. Score each answer 0, 1 or 2. Zero is evasive or absent, one is plausible but unwritten, two is specific and documented.
3. Weight ownership and exit. A weak answer on price is negotiable. A weak answer on who owns the accounts is not.
4. Turn answers into clauses. Anything a company promised should end up in the statement of work. If it will not go in, assume it will not happen.
5. Ask the follow-up. The second question reveals more than the first. "Can you show me where that is written?" is the most useful follow-up there is.

Ownership questions

Ownership problems surface at the worst time: when you want to change vendor, sell the business or fix an urgent bug. Settle them first.

1. Who owns the source code, and under what license?

Good: "You receive the complete source code, for every client and service, and you may modify, host and rebrand it. The license has no per-seat fee, no revenue share and no domain limit, and the contract says so." Bad: "You get a license to use the app." That is a rental, and the same words can describe code you can never move. Ask whether any part is obfuscated, encrypted or compiled so that you cannot read it, and whether any component is licensed separately by a third party. Our guide to what a clone script is and what source code gives you lists the license traps.

2. In whose name are the app store developer accounts registered?

Good: "Yours, and we ask you to open them. We prepare the builds and help with submission." Bad: "We publish under our account to save you time." An app published under the vendor's account belongs, in practice, to the vendor's account. Both stores allow transfers, but with conditions. Apple states that the Account Holder of the current owner starts an app transfer and the recipient's Account Holder accepts it, and that some items, such as APNs certificates and Apple Pay merchant IDs, do not transfer. Google lists items that do not transfer, such as orders created before the transfer and integrated service permissions. Read the Apple app transfer overview and the Google Play transfer guide, and avoid needing either.

For a company, register the accounts as an organization. Apple's enrollment page says organization enrollment needs a D-U-N-S number and that the person enrolling becomes the Account Holder, who must have legal authority to bind the organization. Google Play also requires a D-U-N-S number for organization accounts. Start the paperwork early; it is the slowest part of a launch and it sits outside any vendor's schedule.

3. Who holds the domain, DNS and SSL certificates?

Good: "You register the domain with your own registrar account and give us delegated access during the project." Bad: "We manage the domain for you." A vendor who controls your domain controls your product and your email. Registrar and DNS logins should be yours, with the vendor given scoped access that you can remove.

4. Whose payment accounts are connected, and who can see the keys?

Good: "Your merchant account, your processor onboarding, your keys, entered by your team or in front of you. We never receive settlement money." Bad: "Payments go through our account and we pay you out." That makes the vendor a payment intermediary, with legal, tax and trust consequences, and it ties your revenue to their solvency. For our platforms, you provide the merchant accounts and approval is between you and the processor.

5. Who owns and can export the data?

Good: "The database is yours, in an account you control. You can export it at any time in a standard format, and our contract says the data is yours." Bad: "The data lives in our system and we give you reports." Ask where the data lives, in which country and under whose cloud account, and whether the vendor's staff keep standing access after handover. Our companion article on data ownership and hosting choices goes through this in detail.

Price and scope questions

6. What exactly does the price include?

Good: A deliverables list: web app, mobile apps, admin panel, deployment, documentation, support period, updates. Bad: "Everything you need." Ask for the list and compare it line by line with other quotes. Our ReelShort clone development cost page shows how we separate the one-time price from the running costs.

7. What is excluded, and who pays for it?

Good: An explicit exclusion list that names the usual items: hosting and bandwidth, payment and processor fees, third-party provider fees, developer account fees, content and catalog rights, moderation staff, legal documents. Bad: A quote that does not mention them. Our guide to hidden running costs lists the lines that surprise new operators.

8. How are change requests priced and approved?

Good: "Every change is written up with scope, time and price, and you approve it before work starts. Small tweaks within a stated allowance are free." Bad: "We are flexible." Flexibility without a written process becomes a dispute over the invoice. Ask for a sample change request and the rate card.

9. When do I pay, and what do I get at each payment?

Good: Payments tied to inspectable deliverables, with a final part due after handover and acceptance. Bad: Most of the money up front for work you cannot see. For a ready-made platform, the milestone is usually delivery and deployment; ask what happens if acceptance fails.

Timeline questions

10. What starts the clock?

Good: "The clock starts when we have the kickoff kit: brand assets, domain access, server access and the accounts we need." Bad: A date with no stated preconditions. A six-day delivery is meaningful only if the vendor says what you must supply and by when. Our published delivery plan for the micro drama platform is six working days, with the days split into kickoff, branding and settings, server deployment, account connection, a catalog and test pass, and handover, and a line on what you supply each day.

11. What is outside your control, and how do you plan for it?

Good: A direct list: app store review, payment account approval, developer account verification, content licensing. Bad: A guarantee of a store launch date. No vendor controls Apple or Google, and any promise that they will approve an app by a fixed date is a red flag. Read the creator platform launch week guide for what sits inside and outside the clock.

12. What happens if you miss the date?

Good: A written remedy, such as a credit, a fee reduction or a right to terminate, and a named person who escalates. Bad: "That will not happen." Ask also what happens when you are the cause of delay, because a fair contract handles both directions.

Technical questions

13. What is the stack, and could any competent team take it over?

Good: A named, ordinary stack that you can hire for. For example, our ReelShort platform runs Node and Express with MongoDB, a Next.js operator console and a Flutter app, and the OnlyFans-style platform runs Laravel with MySQL. Bad: A proprietary framework or "our own engine". Ask how many engineers outside the vendor could work on it, and whether the build is reproducible from the repository.

14. Where can I host it, and can I move?

Good: "Any server or cloud you choose. We deploy to your account and document the setup. Moving means copying the database and media and changing configuration." Bad: "Hosting is included with us." Included hosting is convenient and creates a dependency. If the vendor hosts, ask for the exit terms in writing.

15. What documentation do I get, and what are the scalability limits?

Good: Setup, configuration, deployment and operations documents, a database schema, and an honest statement of where the architecture will need work as volume grows, such as queue workers, a CDN in front of storage and database indexes. Bad: "It scales infinitely." Ask what load the system was tested at and what the first bottleneck would be.

Support and update questions

16. How long is support, what does it cover and how fast do you respond?

Good: A fixed period, a scope and a response target. Ours is 60 days of technical support after delivery, plus 1 year of free updates. Bad: "Lifetime support" with no definition. Ask what counts as a bug, what counts as a change, and what happens when the support period ends. Ask who answers on a weekend or at 2 a.m., and whether response times apply outside business hours.

17. What is your update policy?

Good: A described release cadence, a changelog you can read, and a rule for security patches. Bad: No release history. Ask whether updates are applied for you or delivered as code that your team merges, because a customized codebase can make merging hard. Ask what happens to your own modifications when an update arrives.

Compliance and payments questions

18. What do you configure, and what do I carry?

Good: A clear split: the vendor supplies tooling such as reporting, takedown workflows, age gating and logs, and the operator carries the legal duty, the policy and the people. Bad: "The platform is fully compliant." Compliance depends on your market, content and conduct, and no software can promise it. Our guide to whether launching a clone is legal explains the split. This is general information, not legal advice.

19. Will you help me with processor and store applications?

Good: "We prepare builds, documents and demo accounts, and we help with submissions. Acceptance is decided by the processor or the store and cannot be guaranteed." Bad: "We guarantee approval." A vendor who promises it will not be there when the application fails. The honest answer includes what you must supply: policies, verification procedures, a business entity.

Exit questions

20. How do I leave, and what does it cost?

Good: A handover list in the contract: repository, build scripts, credentials, documentation, database export, and an agreed transition period. Ask about escrow if the vendor keeps any part of the code. Bad: "You will not want to leave." The test of a vendor's confidence is how plainly they describe the day you do. For a platform you have the code for and host yourself, exit is simple: your engineers or another company can take over, and the vendor has no lever. See our ReelShort clone development company page for how we describe delivery and handover.

The answer-quality table

Print this and score each answer during the call.

Turn the answers into a contract

When the answers are good, the contract is where you keep them. This checklist is a starting point for the conversation with your lawyer.

• A deliverables list and an exclusions list attached to the agreement.
• Clear intellectual property terms: who owns the code, who owns modifications, which third-party components carry their own licenses.
• Account registration in your name, with the vendor's access recorded and revocable.
• Payment milestones tied to deliverables and acceptance criteria for each.
• A timeline with stated dependencies on you and on third parties.
• The support period, scope, response targets and what happens after it.
• Confidentiality and data protection terms, including where data is stored and who may access it.
• Liability limits, governing law and the place where disputes are settled.
• Termination rights and a handover list.

How we answer, in brief

Since we are a vendor too, here is where we stand, as of October 2026 and drawn from the published product pages. You receive full source code with no per-seat fee and no revenue share. You host on your own server or cloud account. Merchant, developer and ad accounts are yours, and approval from processors and stores is not ours to guarantee. On the white-label ReelShort clone platform, delivery is about six working days from the point we have your kickoff items. Technical support lasts 60 days and free updates 1 year. Tailored work for your build typically takes 2 to 8 weeks, and we confirm the scope with you at kickoff. The one-time price is the published price on the pricing page. We use the same approach on the OnlyFans clone and the TikTok clone platforms, with a different stack for each. Check every claim against the contract, ours included.

What to do next

Pick three companies and send them all 20 questions in writing. Score the answers with the table. Eliminate any company that fails the ownership or exit questions, whatever its price. Take the best two answers into a demo, using the white-label evaluation guide. Open your developer accounts and domain in your own name while you decide, because those take time. Have a lawyer review the final contract against the checklist above.