RATES CURRENT 8/2026 The wages employers in Pakistan post, role by role See the rates
PAKISTAN GUIDE

How to vet a Pakistani dev shop before you sign

Updated 8/2026

Screen on four things before you commit a budget: communication responsiveness across a real time-zone gap, a payment-milestone structure that ties release to working code, a portfolio you can verify against a live product rather than a case-study PDF, and a plain answer to who owns the source code if the engagement ends early. A shop that stalls on any one of these is telling you something before the contract even starts.

Start from a real list rather than a search result: the provider registry carries 899 Pakistani software firms by city, sourced from public listings and labeled as a data display rather than an endorsement. Screening is still yours to run, and this page is how.

The failure pattern that should worry you most

The sharpest documented case in outsourcing communities isn't a scam in the classic sense. It's an agency that dissolved mid-engagement and walked away with the client's source code, leaving the buyer with a shipped product they'd paid for but couldn't maintain, extend, or even access the repository for. We've seen this pattern described in outsourcing community discussion, including on Hacker News, but haven't traced it to one specific thread with a confirmed dollar figure we'd put our name behind, so we're not citing a number here. The lesson isn't "avoid small shops." It's that source-code and repository access has to be contractually guaranteed and technically verified during the engagement, not assumed to follow naturally from payment. Ask for direct repository access, not a zip export at the end, from week one, and confirm you can clone and run the project independently before the engagement is a month old.

Payment-milestone structure that protects you

Don't pay a dev shop the way you'd pay for a finished good. Structure payment against working, demonstrable milestones:

  • Discovery/spec milestone: a written scope and technical plan, paid on delivery of the document, not the idea of one.
  • First working build: a milestone tied to something you can run, click through, or test, not a percentage of elapsed time.
  • Mid-project checkpoint: repository access confirmed working, core features demonstrable, before you release the next tranche.
  • Final delivery: full repository handoff, documentation, and a defined support or warranty window, paid on confirmed handoff, not on the shop's word that it's done.

This mirrors the deposit discipline that works on the goods side of Pakistan sourcing: no large payment ahead of demonstrated progress, and never the full contract value paid before you can independently verify what you're getting. A shop that resists structuring payment this way, or insists on 50%+ upfront with no interim deliverable, is asking you to accept the source-code-walkaway risk above without any of the checkpoints that would catch it early.

Communication screening: the real filter hiring managers use

Buyers researching outsourced teams consistently cite communication and async responsiveness, not skill, as the actual reason they filtered out a shop or a candidate. That's a legitimate operational concern and a fixable one, not a reason to filter by nationality (see below). Screen for it directly:

  • Response latency during a trial task. Give a small, real, time-boxed task before any contract discussion. How fast and how clearly the shop responds tells you more about day-to-day working reality than a sales call does.
  • Written English quality in technical contexts, not conversational fluency. A shop that writes clear technical documentation and clear async updates will work fine across a time-zone gap even if a live call has an accent or a lag. Ask for a writing sample: a past project's technical spec or a bug report.
  • Overlap-hours commitment, stated explicitly. Ask exactly which hours the team commits to being live and responsive relative to your time zone, and hold them to it in the trial task.

Why filtering by nationality doesn't solve the problem it's aimed at

Some outsourcing-facing listing platforms and job boards have been observed, per community reporting, explicitly excluding Pakistan, along with India, Nigeria, and Bangladesh, by name from certain service categories. We haven't audited platform policies ourselves to confirm which specific platforms and categories currently apply this, so treat this as a reported pattern worth checking against the platform you're actually using, not a confirmed universal rule. We'd argue blanket nationality filtering is a blunt substitute for the screening problem it's meant to solve, and a worse one. It filters out the shops with strong English documentation, tight payment-milestone discipline, and verifiable portfolios along with the ones that would fail those checks anyway, and it does nothing to catch a bad actor who happens to be based somewhere the filter allows. The structural alternative is the screening above: run the trial task, check the writing sample, verify the portfolio against a live product, structure payment against milestones. That catches the actual risk (unreliable delivery, poor communication, an engagement that goes sideways) regardless of where the shop is based, and it doesn't cost you strong candidates who happen to share a country with weaker ones. Filter on the behavior, not the passport.

Two contract clauses that do more work than the rest

IP assignment, written explicitly. Do not assume the code you paid for is yours. Pakistani copyright law does not deliver an overseas client automatic ownership the way a US work-for-hire arrangement might, and absent a written present-tense assignment the author can retain rights. Say plainly that all work product and its intellectual property transfer to you on creation, and make the clause cover any pre-existing or third-party components the shop incorporates, with a license for anything it will not assign. This pairs directly with the repository-access discipline above: contractual ownership plus technical access is the combination that survives a shop dissolving mid-engagement.

Named-team substitution. Agencies rotate staff, and the senior engineer who impressed you in the sales call is a common casualty. Name the specific people in the contract, require written approval before any substitution, and tie a milestone to the named team actually doing the work. A shop confident in its bench agrees to this readily. A shop that resists is telling you the people you met are not the people you are getting.

Registry checks that take ten minutes

Three public sources confirm a shop is what it claims before you spend real diligence time. SECP's public company search confirms the entity is registered under the name on your contract. P@SHA, the Pakistan Software Houses Association, publishes its membership. PSEB, the Pakistan Software Export Board, maintains a registration that IT exporters generally hold because it qualifies them for the software-export tax exemption, so an exporting shop of any scale usually appears there.

None of these prove capability, and none replaces the screening above. They establish that the entity exists, is registered under the name it gave you, and is visible to its own regulators. That is the floor. A shop that fails these checks is not worth the trial task.

Verifying a portfolio for real

A portfolio PDF or case-study page proves a shop can write a case study. Verify the actual work:

  1. Ask for the live product, not a screenshot. If the shop built it, it should still be running somewhere you can visit.
  2. Ask who on the current team worked on it. Agencies rotate staff; the portfolio piece you're impressed by may have been built by people no longer there.
  3. Check the repository history if the client will share it, or ask the shop directly what tooling and practices show up in their own process (code review, testing, deployment pipeline) rather than accepting a general claim of quality.
  4. Cross-reference against LinkedIn. A shop's stated team size and specialization should roughly match what's visible on LinkedIn for the company and its listed employees. A mismatch is a question to ask directly, not an automatic disqualifier.

This is the same screening we apply before we would put our name next to a shop. When you engage us to build your team, we meet the shop in their office and run this checklist in person before you sign, not over a video call. Connect with our team about building yours if you would rather not run it cold.

Where to go next

What we don't know yet

We haven't confirmed the exact dollar figure and thread details of the source-code- walkaway case referenced above; it's a documented pattern in outsourcing community discussion, and we're flagging the specific figures for verification rather than asserting them as confirmed facts. We also haven't audited which specific listing platforms currently apply nationality-based filtering, or in which categories; that's based on community-reported observation, not our own platform review. We don't vet or certify individual dev shops ourselves; the checklist above is designed for you to run, not a service we perform on your behalf.

Sources: SourceGrowth community-question corpus (source-code walkaway case and nationality-filtering observation, 52-question mining, 8/2026 lane memo, sourced from Hacker News, TeamBlind, and outsourcing-facing forums).

Data status: wages-v0, last pulled 8/2026 CURRENT (refresh cadence: every 31 days)
Public job-posting wage layer (posted salaries only, PKR). Wages are what employers pay locally - not billed outsourcing rates.

See if Pakistan fits what you're building.

The guide above is the market. Our people on the ground turn it into a plan for your team or your product, and tell you straight if the fit is wrong.

Get a straight fit-check