We are a software studio in Pakistan writing a guide to vetting software studios in Pakistan, which is a conflict of interest we should name up front. We are writing it anyway, because the questions below are the ones that protect clients — including from us — and because a market where buyers know what to ask is a better market for the people doing careful work.
The short version
- Ask for repository access from day one and a written IP assignment. If either is refused, walk away.
- Register the domain, hosting, app store and cloud accounts in your own company's name. This is the most common way clients get trapped.
- Pay by milestone against demonstrable output, never by calendar date, and never more than 30% up front.
- The best signal in a sales call is whether they tell you something you did not want to hear.
- Reference calls with past clients are worth more than any portfolio. Ask for one where something went wrong.
What you are actually buying
Pakistan has a large, genuinely capable software workforce, strong English, and rates well below Western Europe or North America. The variance in quality, however, is very wide — wider than the price range would suggest. The same brief can produce a well-architected, documented, tested system or a pile of screens that stops working when the original developer leaves.
Cost is therefore the wrong primary filter. The right filter is whether this team will still be useful to you in eighteen months, which is a question about process, ownership and communication rather than about code.
Vetting: what to ask, and what the answers tell you
Ask about a project that went wrong
"Tell me about a project that did not go well and what you changed afterwards." A studio with real delivery history has one and will describe it specifically — a scope misjudged, an integration that stalled, a hire that did not work. A studio that claims a perfect record is either new or not being straight with you. This single question separates candidates faster than any other.
Ask who specifically will do the work
You want names, seniority, and the percentage of their week you get. The common failure mode is meeting a senior architect during the sales process and receiving a team of juniors afterwards. Ask directly: "Will the person in this call write or review my code?" Then put the named team in the contract.
Ask them to critique your brief
Hand over your requirements and ask what is missing or risky. A good team comes back with uncomfortable questions — about roles you have not defined, edge cases, the integration that will be difficult, the feature that costs three times what you think. A team that says "no problem, all clear" has either not read it or will discover the problems on your budget. Our requirements guide shows the level of detail worth expecting.
Ask for a reference call, not a portfolio
Portfolios are curated and occasionally borrowed. Ask to speak to two past clients, ideally one whose project had difficulties. Then ask those clients three things: did the estimate hold, how were changes handled, and would you use them again for something larger?
Ask to see code
Even if you cannot read it, ask for a sample repository or a walkthrough. Have any technical person you trust glance at it. You are not auditing algorithms; you are checking for commit history, tests, a README, and consistent structure. Their absence tells you about habits.
The soft signal that predicts the most
Did they push back on anything? Every genuinely useful development partner we know has told a client "that feature is not worth building" or "your timeline is not realistic" during the sales process. A team that agrees with everything in order to win the work will keep agreeing with everything, and you will find out in month three that agreement was not the same as capability.
The contract terms that actually matter
You do not need a complicated agreement. You need these seven things stated plainly.
- Intellectual property assignment. All work product, including source code, designs and documentation, is assigned to you on payment. If the studio uses its own reusable libraries, that should be disclosed and licensed to you perpetually and irrevocably. Never accept an arrangement where you licence your own product back.
- Repository ownership from day one. The Git repository lives in your organisation's account, and you are an admin from the first commit. This is the single most important clause in the agreement. Code you cannot see is leverage against you, and "we will transfer it at the end" is where disputes come from.
- Milestone payments tied to output. Each payment releases against something you can inspect — a deployed build, a completed module, a passed test cycle. Not "end of month two". Up to 30% up front is normal; more than that transfers all the risk to you.
- A named scope document, referenced by version. The contract should point to a specific dated version of the requirements, including the out-of-scope list.
- A change request process. How changes are requested, estimated, approved and priced. Agree the hourly or daily rate for changes in the contract, before you need it.
- Warranty period. 30 to 90 days after launch during which defects in delivered scope are fixed at no cost. Define what counts as a defect versus a new requirement.
- Exit terms. What happens if either side stops. What you receive, in what state, within how many days. This clause costs nothing while things are going well and is priceless when they are not.
Own your accounts — the trap that catches most people
This has nothing to do with code and causes more genuine harm than any technical decision. Every one of the following must be registered in your company's name, with credentials you hold, from the beginning:
- Domain registration
- Hosting and cloud accounts (AWS, DigitalOcean, cPanel)
- Apple Developer and Google Play Console accounts
- Payment gateway merchant accounts
- Google Analytics, Search Console, Tag Manager, Ads
- Business email and any transactional email service
- The Git repository organisation
- Database backups, in storage you control
- Any third-party API keys purchased for the project
The reason this matters is simple: an app published under a vendor's Apple account cannot be moved to yours without their cooperation, and a domain registered in a vendor's name is not yours. We have been called to help clients who owned their code and could not deploy it. Do not let convenience during setup become dependence later. Our hosting guide has the full pre-launch ownership checklist.
Eight red flags worth walking away from
- A quote in under an hour from a one-page brief. They quoted their guess. The real number arrives as change requests.
- Reluctance to give repository access before final payment. There is no legitimate reason for this.
- No questions about edge cases, roles or error states. Either they have not read the brief or they have not built anything complex.
- A price 60–70% below every other quote. The scope is smaller, or the plan is to make it up on changes. Ask what is excluded and compare exclusion lists, not prices.
- Pressure to sign quickly — a discount expiring, a slot about to be filled. Good studios have pipelines, not urgency tactics.
- Portfolio work they cannot discuss in detail. Ask about a specific project's hardest technical problem. Vagueness about work you supposedly did is diagnostic.
- No QA in the proposal. Testing is 15–25% of a professional build. Its absence means your users are the QA team.
- A single point of contact who is also the only developer. Fine for a small site, dangerous for anything you will depend on. One illness becomes your outage.
Making the engagement work once it starts
Half of project outcomes are determined on the client side. The best clients we work with — the ones whose projects go smoothly and cost what we said — do these things:
- They name one decision-maker and let that person decide.
- They protect 3–5 hours a week for the project and actually spend them.
- They give feedback on builds, not on descriptions. Clicking the thing produces better feedback than reading about it.
- They answer questions within 48 hours. A blocked team is an expensive team.
- They deliver content and test data on time — the most common cause of slippage that has nothing to do with engineering.
- They accept that changing their mind has a price, and budget 10–15% for it rather than pretending the first spec was perfect.
Fixed price, retainer, or dedicated team?
| Model | Best when | Watch out for |
|---|---|---|
| Fixed price | Scope is genuinely clear and stable | 20–30% risk premium; strict change control |
| Time & materials | Product will evolve; you can stay engaged | Needs your attention weekly or costs drift |
| Monthly retainer | Ongoing maintenance and small improvements | Define included hours and response times |
| Dedicated team | Long-term roadmap, 6+ months of work | You are effectively managing them; needs your own product owner |
For a first engagement with a new studio, our honest recommendation is to start small: a paid discovery phase, or one well-defined module, before committing the full budget. It costs you a few weeks and tells you more about how they work than any amount of reference checking. If they resist a small first engagement, that is itself information.
The best due diligence is a small paid project. Contracts describe intentions; a delivered module describes reality.
Using this against us too
Every question above applies to us. Ask us who will actually write your code. Ask us about a project that went badly. Ask for repository access on day one — you will get it, because that is how we work. And if our answer to "should we build this?" is that an off-the-shelf product would serve you better, we will say so; we have lost work that way and it remains the right answer.
If you want to test all of this in a conversation rather than a document, start there. It costs nothing, and you will learn more about how we think in thirty minutes than from any page on this site. You may also want our cost breakdown to sense-check the quotes you receive, and our list of the nine ways projects fail to know what to watch for once work begins.