Search for a development partner in this city and you will get more results than you can meaningfully read, and their websites are close to identical: the same stock photography, the same nine services, the same sentence about being a leading provider of end-to-end digital solutions. Choosing between them on that evidence is impossible, so most buyers end up choosing on price, and a good share of them regret it.
This is a guide to choosing a software house in Islamabad on better evidence than a homepage. It is written by one, which you should factor in — so everything below is a question you can put to any firm, ours included, alongside a description of what a good answer sounds like. If a competitor answers them better than we do, hire the competitor. That is the honest use of a page like this.
First, the word itself
"Software house" is local vernacular. In Britain or the United States the same business is called a software development company or a development agency; in India it would be an IT services firm. The label carries no information about size, quality or legal structure. A two-person operation working from a bedroom and a ninety-person company with a floor in Blue Area both use it, and both are entitled to.
That matters for one practical reason: you cannot filter a shortlist by what a firm calls itself, and you should not try. A team advertising as a software house is not more established than one advertising as a studio or an agency. Every distinction that actually predicts whether your project finishes is below, and none of it is visible from a search result.
It is almost never the code
Projects here fail regularly, and when they do, the post-mortem almost never finds a technical cause. Three non-technical failures account for most of it, and you can screen for all three before you pay anything.
Scope agreed in voice notes. A recording of an enthusiastic conversation is not a specification. It feels like progress because it is fast and friendly, and it is the single most expensive thing you can do at the start of a project. When nobody has written down what finished means, the last fifth of the build becomes a negotiation instead of a task — you believe the login screen was included, the firm believes it was discussed, and both of you are remembering the same call correctly. That argument is then billed by the hour, or it ends the relationship.
One developer wearing five hats. A capable freelancer covers one discipline properly. A working store needs design, front-end, a payment integration that actually clears in rupees, someone who has fought Play Store review before, and somebody reachable eighteen months later when it breaks. One person can learn all of that. One person cannot do all of it at once, on your deadline, while also doing it for two other clients.
No handover. This is the one that costs the most and gets checked the least. Projects arrive with us regularly carrying no repository access, no admin login, no hosting credentials and no documentation, because the previous team kept them deliberately. Nothing about that is technically necessary. It is leverage, and it is entirely preventable by a paragraph in a contract.
The five questions to ask before money changes hands
Ask these in the first meeting, before a deposit and before any design work. The answers are more informative than any portfolio, and hesitation on any of them is itself the answer.
1. "Can I see the written scope before I pay the deposit?"
A good answer is yes, with a document that lists every screen and names every integration. A bad answer is that the scope will be finalised after the advance, which means the price you agreed was for a project neither of you has defined yet.
2. "Which of these portfolio projects can I open right now, and which client can I phone?"
A good answer is a live URL and a name. A bad answer is that the work is under NDA, that the client has since redesigned, or a folder of screenshots. Some of those excuses are occasionally true. All three at once is not.
3. "Whose name is on the repository, the hosting and the domain?"
The only good answer is yours, from day one. Anything else is a subscription you did not know you were signing.
4. "Who specifically is working on this, and what happens if they leave?"
A good answer names people and describes how the work is documented so it survives one of them resigning. A bad answer is a headcount and a promise of resources.
5. "What does month thirteen cost me?"
Software is not a purchase, it is a thing that needs hosting, updates, a broken payment gateway fixed on a Sunday, and an operating system upgrade every year that quietly breaks something. A firm that has never raised maintenance before you did has either not thought about year two or is hoping you will not.
How to read a portfolio you cannot verify
Borrowed portfolios are common enough here to assume nothing. Screenshots are trivial to lift, and a grid of logos proves only that someone downloaded some logos. Four checks cut through most of it.
- Ask for URLs, not images. Then open them. A site that is down, parked or four years out of date tells you something about the relationship as well as the work.
- Ask for a project like yours, not their best one. The showreel piece is the outlier by definition. What you want to see is the third-best version of your own project, because that is closer to what you are actually buying.
- Ask for one phone number. A firm with genuinely happy clients can produce one within a day. This single request eliminates more candidates than every other check combined.
- Read the case study for a constraint. Real write-ups name what was hard — a migration that had to happen without downtime, a catalogue that arrived as a spreadsheet with duplicates in it. Fabricated ones only ever describe success. Ours are collected on the portfolio page with the client named on every one, which is the standard you should hold any shortlist to.
Who owns the code when it ends
If you read one section of this guide, read this one. Ownership is the most routinely abused thing in this market and the easiest to settle in advance, and buyers skip it because it feels adversarial to raise at the start. It is far more adversarial to raise at the end.
Six things should be in your name, and it costs nothing to put them there on the first day:
- The repository — your account, your organisation, with the agency added as a collaborator rather than as the owner.
- The hosting account, billed to your card. Not a slice of the agency's reseller plan.
- The domain, at a registrar you can log into. Check this today, even if your site was built years ago.
- The Apple Developer and Google Play accounts, if there is an app. Enrolled under your company, not the agency's. Moving a published app between developer accounts afterwards is genuinely painful, and it is a common reason people feel stuck.
- Every third-party account — payment gateway, analytics, email sending, SMS, maps. Each one created with your email address.
- Documentation good enough that a different team could pick the project up without phoning the last one.
Get it written into the contract rather than agreed on a call. A firm that resists is telling you precisely how the relationship ends.
What a real scope document looks like
You are not really comparing prices between firms. You are comparing how completely each one has understood what you asked for, and the document is the only visible evidence of that. A number arriving without one is not a quote, it is an opening position.
A scope worth signing contains: every screen or page, listed; every integration named specifically, including which payment gateway and which courier; what happens to your existing data; who writes the content and supplies the images, because that assumption sinks more timelines than any technical problem; what is explicitly excluded; what "done" means for each milestone, in terms you could check yourself; and a written process for changing your mind, because you will, and the time to agree how a change gets priced is before you want one.
On money, the structure tells you more than the figure. Payments should attach to milestones you can see with your own eyes — a staging URL, an approved design, a store review submission — rather than to dates on a calendar. And the price should move only when the scope moves. If you can find a published per-hour rate for custom software anywhere, treat it with suspicion: it is either wrong for your project or padded enough to be right for every project, and both cost you. What should be fixed in advance is the process, not a rate card.
The local details an outside team gets wrong
This is the part of the decision where being in Pakistan genuinely changes the output rather than just the invoice. A team that has not shipped here will build the first eighty per cent competently and then discover the rest.
Rupee card processing behaves differently from what the international tutorials assume, and which gateway you choose constrains your checkout, not the other way round. Cash on delivery is not a checkbox — it is a reconciliation problem, a returns problem and a fraud problem, and it needs screens that most themes do not ship with. Courier integration means real status webhooks and a tracking page customers will actually use. Bank transfer as a payment method needs somebody in your office to verify a receipt, which means an admin screen someone thought about. Urdu content needs fonts that render correctly at small sizes on cheap Android phones, which is where a large share of your traffic will come from.
None of this is exotic. It is simply the difference between a store built for a buyer in Islamabad and the same store built for one in Manchester, and the difference lives almost entirely in the last few screens — the ones that get built last, when the budget is gone. Ask any shortlisted firm to walk you through checkout on a Pakistani store they have already shipped. It is a two-minute question with a very informative answer.
Freelancer, small team, or a full house
The honest answer is that all three are correct for someone, and paying for more than you need is as much a mistake as paying for less.
A freelancer is right for one well-specified piece of work: a landing page, a fix, a theme customisation you can describe in a paragraph. It is the cheapest correct answer to a narrow question, and buying an agency for it is waste.
A small team is right when the work crosses two or three disciplines but stays inside one project, and when you are prepared to be the project manager yourself.
A full house earns its cost in exactly two situations: when the work spans disciplines that have to hand off cleanly — design into build into payments into search — and when the thing has to still work in three years. The real question is never headcount. It is whether the project survives one specific person deciding to leave, and you can ask that directly.
If your project is a store, an app or an internal system respectively, the pages on Shopify work in Islamabad, app development here and custom systems describe how we scope each one, which will at least give you a shape to compare other proposals against.
If you are already halfway into a bad build
Roughly a third of the work that comes through our door is a recovery: a build that stalled, a developer who stopped replying, a site that went down with nobody holding the login. If that is you, this is ordinary rather than shameful, and it is recoverable more often than a new agency will tell you.
Before you speak to anyone, collect whatever exists: the live URL, any repository access, the hosting and registrar logins, the designs, and the last written thing anybody agreed. Even a URL and nothing else is enough to start from.
Then ask for a written continue-or-restart assessment, and read it with one bias in mind. A rebuild is the easier and more profitable sale, so any firm recommending one has an incentive you should make them argue against. Ask them to justify restarting against the actual code rather than in general. In our experience continuing is the right call more often than the industry admits — and where it is not, the reason should be specific enough that you can repeat it to someone else.
Red flags, roughly in order of what they cost you
- A deposit requested before a written scope exists. Everything else on this list is a consequence of this one.
- The domain or hosting registered in the agency's name. Check now, not at handover.
- No client you are allowed to phone.
- A quote that arrives as a single number. No document behind it means no shared understanding of what you bought.
- An office that cannot be visited. A meeting request is free to accept and instantly clarifying.
- A price far below every other quote. It is not generosity. It is either a scope that will be revised after your deposit, or a junior learning on your project.
- Communication only through one salesperson. You want to meet whoever is actually building it, once, before you sign.
- Silence about maintenance. Year two exists whether or not it was quoted.
Take this into the meeting
Whatever else you take from this, take the list. Choosing a software house in Islamabad is not a judgement about talent — there is plenty of it here — it is a judgement about process, and process is visible in advance if you ask for it. Six things to leave with, in writing, from any firm you are considering:
- A scope document listing every screen, integration and exclusion.
- A fixed price against that scope, with a stated process for changes.
- Milestones tied to something you can see, not to dates.
- One contactable reference and two live URLs.
- A clause putting the code, hosting, domain and every account in your name.
- An answer about what support costs after launch.
A firm that supplies all six is worth serious consideration whatever it calls itself. A firm that supplies none is worth avoiding no matter how good the portfolio looks, because the portfolio is not what you are buying — the process is.
If you want to see how we answer the six, our Islamabad page sets out the process, the office you can visit and the work shipped from it. And if you would rather test the answers than read them, send us whatever you have and we will return a free written teardown inside 48 hours: what you have, what it actually needs, and whether the thing you described needs building at all. It is yours to keep and to take to whichever firm you choose, including one of our competitors.
