Mobile Apps

Questions to Ask Before You Sign an App Development Contract (and Red Flags to Walk Away From)

By Daniyal Hassan · · 11 min read

This is for the founder, marketing head, or small-business owner in Lahore, Karachi, or Islamabad who is about to commit PKR 8 lakh to PKR 40 lakh on an app and wants to not get burned. I have built and rescued apps for Pakistani clients since 2009, and the single biggest predictor of a disaster is not the price — it is the contract. Below is a pointed interview script: the exact questions to ask app developer teams before you sign, what a good answer sounds like, and the clauses that should make you stand up and leave.

Read this before your next meeting. If a vendor squirms on three or more of these, that is your answer. The same set of questions to ask app developer candidates works whether you are hiring a freelancer on a project basis or an established agency.

Start With Ownership: Who Owns the App Source Code?

This is the question that catches the most people, and it is the one I would lead with. Plenty of buyers assume that because they paid for the app, they own everything. That is not automatically true in a software contract. If the agreement is silent, the developer may legally retain copyright in the code they wrote, licensing it to you — which means you can use the app but cannot freely move it, resell it, or hand it to a different team.

The exact phrasing to use

  • “On final payment, is the source code assigned to me outright, or licensed?” — you want assigned, in writing, as a work-for-hire / IP assignment clause.
  • “Does that assignment include the full Git history, build scripts, and configuration — not just a zip of files?”
  • “Who holds the Apple Developer and Google Play accounts — my company or yours?” The correct answer is that they live under your accounts, with your billing. If the app is published under the agency’s account, they control your store listing and can hold it hostage.
  • “Are there any third-party libraries with licenses that restrict commercial use or require ongoing fees?”

So when someone asks me who owns app source code after a build, the honest answer is: whoever the contract says owns it — and if it does not say, assume you do not. Get the IP assignment in writing, triggered on full payment, covering source, history, and design assets. No exceptions.

Pin Down the Money: Fixed Price, Milestones, and What “Done” Means

Pakistani buyers love a single fixed number because it feels safe. It is only safe if the scope is nailed down. A fixed price against a vague scope is how you end up paying twice — once for the build, once for every “that wasn’t in the agreement” change request.

Ask these before you agree to any figure

  • “What exactly is in scope, screen by screen, and what is explicitly out?” Get a feature list as an annex, not a paragraph.
  • “How are payments tied to milestones?” Avoid paying 50% or more upfront. A healthier split for a mid-size app is something like 20% to start, then milestone payments tied to working, demonstrable deliverables, with a final 10–15% held until acceptance.
  • “What is your change-request process and hourly rate?” A real shop has one. Typical mid-market Pakistani agency rates run roughly PKR 2,500–6,000/hour depending on seniority — know the number before you need it.
  • “Does the quote include payment-gateway integration?” If you need JazzCash, Easypaisa, or a card processor, integration and the bank’s own KYC/onboarding take real time. Confirm it is costed in, not assumed.

A vendor who cannot define “done” cannot be held to it. If acceptance criteria are missing, that is a soft red flag — push until they exist.

The Exit Terms: How Do You Leave If It Goes Wrong?

Nobody negotiates the breakup at the wedding, and that is exactly why you should. The exit clauses tell you more about a vendor’s confidence than any portfolio. Strong teams write fair exit terms because they do not expect you to use them. Weak ones build a cage.

  • “If I terminate, do I get all work completed to date, in usable form, with the source?” The answer must be yes — you paid for it.
  • “Is there a notice period and a transition/handover obligation?” You want a documented handover: credentials, code, deployment steps, and a short knowledge-transfer window.
  • “Is there a lock-in via proprietary tooling?” Apps built on a closed no-code platform you do not control are portable only as long as you keep paying that platform. Know what you are signing up for.
  • “After launch, am I free to take maintenance to another team?” If the contract forces you to use them for all future work, walk.

This is the heart of any sane app development agreement checklist: ownership on payment, a clean handover, and no artificial lock-in. If those three are present, most other problems are survivable.

Maintenance, Warranty, and the Bugs You Haven’t Seen Yet

Launch day is the start, not the finish. iOS and Android push breaking OS updates yearly; a payment SDK changes its API; a server certificate expires. Who fixes that, and on whose dime?

Questions that separate pros from order-takers

  • “Is there a warranty period where you fix defects free?” 30–90 days post-launch for bugs in delivered features is standard and reasonable.
  • “What does a maintenance retainer cost and cover?” Get the monthly PKR figure and a clear line between “bug fix” (their cost during warranty) and “new feature” (billable).
  • “What are the response and resolution times for a production-down issue?” A crashed checkout on a Friday night needs an answer, not a Monday ticket.
  • “Will you support the app on mid-range Android, not just the latest flagship?” Most of your Pakistani users are on devices with limited RAM and patchy 4G. Performance on a 3-year-old Android phone is the real test.

People and Process: Who Actually Builds It?

I have seen polished sales decks backed by a single overworked junior. Ask who does the work, not who pitches it.

  • “Who are the actual developers on my project, and are they in-house or subcontracted?” Subcontracting is not automatically bad, but you deserve to know — it affects accountability and IP.
  • “How will I see progress?” You want demo builds (TestFlight / internal Android tracks) every sprint, not a big reveal at the end.
  • “Can I talk to two recent clients directly?” A confident team connects you. Also check their public Google reviews yourself — patterns there are honest signal.
  • “Who is my single point of contact when something breaks?”

These hiring app developer questions are not about distrust — they are about making accountability concrete before money changes hands. Clear ownership of communication prevents the silent two-week gaps that kill projects. If you are also planning a marketing push around launch, it is worth understanding how the build connects to your app store and search visibility strategy early, rather than bolting it on later.

The Red Flags: When to Walk Away

Some answers are not negotiation points — they are exits. Here are the app development contract red flags I tell clients to treat as non-starters.

  1. They won’t assign you the source code on payment. Any “we keep the code, you license it” arrangement for a custom build you funded is a hard no.
  2. They publish the app under their own store accounts. This hands them your live listing, reviews, and update pipeline. Refuse.
  3. They demand 50%+ upfront with no milestone structure. Cash-flow desperation or a flight risk — either way, your money is exposed.
  4. No written scope, just verbal promises. “Don’t worry, we’ll handle everything” is the most expensive sentence in this business.
  5. The contract has no termination or handover clause. They are designing for lock-in.
  6. They can’t or won’t name the developers or show real, reachable references.
  7. Confidentiality is one-directional — you must protect their secrets but they bear no NDA toward your idea and data.
  8. The price is dramatically below market. A quote at a third of everyone else’s is not a deal; it is scope you will pay for later, or a team that disappears mid-build.

Two or three of these together? Thank them and move on. There are plenty of capable teams in Pakistan; you do not need to gamble on a bad app development agreement checklist to save a week.

Data, Security, and Compliance Clauses You Cannot Skip

If your app touches user accounts, payments, or personal data, the contract must address it. This protects you legally and reputationally.

  • “Who owns the user data, and where is it hosted?” You own it; confirm the hosting region and that you get database access and backups.
  • “What security practices are in place?” At minimum: encrypted data in transit, no hardcoded secrets, secure handling of payment tokens (you do not want raw card data on your servers).
  • “What happens to data and credentials at handover?” Full transfer to you, and deletion from their side after.
  • “Is there an indemnity if a breach is caused by their negligence?”

These are core app dev contract terms that buyers routinely forget until something leaks. Write them in while you have leverage — before you sign — not after an incident.

Frequently Asked Questions

Is a freelancer cheaper than an agency for an app?

Often, yes — a solo developer in Pakistan may quote 30–50% less. The tradeoff is continuity and accountability: if a freelancer gets sick, gets a job, or vanishes, your project stalls with no backup. For anything business-critical, the same questions to ask app developer teams apply, but weigh the freelancer’s lower price against single-point-of-failure risk.

Should I pay everything through a milestone escrow?

Milestone-based payments tied to demonstrable deliverables are the safest structure. You do not need a formal escrow service for most local engagements, but you should never pay a large lump sum upfront. Release each tranche only after you have seen and accepted that milestone’s working build.

What if the developer used open-source code in my app?

That is normal and fine — almost every app uses open-source libraries. What matters is the license. Ask for a list of third-party components and confirm none carry copyleft or commercial-use restrictions that conflict with you owning and selling your app.

How long should a typical app take to build?

A focused MVP with login, a few core screens, and a payment integration is realistically 8–16 weeks. Anyone promising a full-featured app in two weeks is either reusing a template (fine, if disclosed) or about to disappoint you. Insist on a sprint-by-sprint timeline in the contract.

Do I really need the contract in writing if I trust the person?

Yes. A written agreement protects both sides and forces clarity on scope, ownership, and exit. Trust is wonderful until there is a disagreement about what “finished” means — at that point only the document matters.

Can I change developers halfway and keep my code?

Only if your contract gives you ownership and a handover obligation. With a proper IP assignment and access to the Git history, switching teams is annoying but doable. Without those clauses, you may have to rebuild — which is exactly why who owns app source code belongs at the top of your list.

Talk to One Source Soft Before You Sign Anything

If you are holding a contract right now and unsure about the ownership, exit, or maintenance terms, send it over. We will give you a free, no-obligation review and a straight read on whether the clauses protect you — even if you do not end up building with us. Our mobile app development team writes contracts the way we would want as buyers: source assigned on payment, your store accounts, clean handover, no lock-in.

We have delivered apps for Pakistani businesses since 2009, our process is transparent sprint by sprint, and you are welcome to read our public Google reviews before you ever talk to us. When you are ready, book a free consultation and we will walk through your scope, your budget in PKR, and the exact terms you should hold any vendor to — including the ones competing with us.

Related reading

Keep reading