How to hire a software house in Lahore: a checklist

Hire on four things: a written scope that says what is explicitly excluded, the names of the people who will actually build it, a contract stating you own the code and accounts, and at least one past client you can speak to directly. A studio that supplies all four is in a different category from one that supplies a portfolio and a price.

Lahore has a deep pool of genuinely good engineering talent and, like any large market, a long tail of outfits that sell well and deliver poorly. The difficulty for a non-technical buyer is that both look identical on a website. This checklist is about the questions that separate them before you have paid anything.

Before you contact anyone

Write down the three things the software must let someone do, and the one business outcome it exists to produce. Not a feature list — three actions and one outcome. This single page is what makes quotes comparable, and it is the thing most buyers skip.

Without it, every studio scopes something slightly different, you receive four quotes for four different projects, and the cheapest wins by having understood the least.

What to ask in the first conversation

• Who exactly will work on this, and what else are they on? You want names and a rough allocation. The pattern to watch for is a senior person in the meeting and juniors on the actual build — not automatically wrong, but you should know.
• What would you cut if my budget were 30% lower? A strong answer shows they understand which parts carry the value. A weak one proposes cutting testing.
• What has gone wrong on a recent project and how did you handle it? Everyone has one. A studio claiming otherwise is either new or not being straight with you.
• What do you need from me, and when? Projects stall on client-side content and approvals far more often than on engineering. A studio that names this up front has run real projects.
• What happens after launch, and what does it cost? Support terms vary more than build prices and are where the unpleasant surprises live.

What the proposal must contain

• An explicit out-of-scope list. More informative than the feature list, and its absence is the single most common cause of disputes later.
• Milestones with payment tied to delivery, not to dates. You should be paying for things that exist.
• A named revision policy. Structured rounds at agreed points, not a vague promise of flexibility that becomes a fight.
• Ownership. The code, the data, the domain and the hosting accounts are yours. In writing, before work begins.
• Who pays for third-party services, and whose accounts they sit in. Hosting, email, payment gateways, any paid libraries.

Verification that costs you nothing

Portfolios are the easiest thing to exaggerate. Three cheap checks change what you are looking at.

• Open their portfolio sites and check they are live and functioning. Sites that are down, parked or obviously rebuilt by someone else are a signal.
• Ask for one reference in a comparable industry and actually call them. Ask what went wrong and how it was handled — not whether they were happy.
• Ask to see code, or a repository, or a technical walkthrough of something they built. You do not need to read it. You are checking that a real one exists and that they are comfortable showing it.

The warning signs

• A fixed price quoted before anyone has asked what the software does. That number is a guess, and it will be defended later by reducing what you get.
• Reluctance to name the team, or a portfolio that cannot be attributed to identifiable people.
• No written scope — "we will work it out as we go" — which reliably means you will pay for that discovery twice.
• Pressure to sign quickly, or a discount that expires. Engineering capacity does not work that way.
• Refusing to confirm code ownership. This is disqualifying on its own, whatever else is on offer.
• A quote far below every other. Usually the backend, the testing or the post-launch relationship has quietly been excluded.

On price, and on rates

Rates in Lahore are lower than in North America, Western Europe or Australia, which is exactly why a lot of international clients build here. But a rate is not a cost. A cheaper team needing twice the hours, or delivering something that needs rebuilding, is more expensive than the quote it beat.

Compare total delivered cost, including what happens after launch, and treat any quote dramatically below the rest as a question rather than a bargain. Ask what it excludes; there is always an answer.

Judging communication before you commit

Most failed projects are not failures of engineering. They are failures of communication that were visible in the first fortnight and ignored because the proposal looked good.

Pay attention to how they behave before you are a client. Do they reply within a working day? Do they ask questions about your business, or only about features? When you describe something ambiguous, do they flag the ambiguity or quietly assume an interpretation? Do they tell you when an idea of yours is a bad one? A studio that agrees with everything during the sales conversation will agree with everything during the build, and you will discover the disagreements at the end.

Ask directly who your point of contact will be and how often you will hear from them. "You will deal with the team building it" is a better answer than an account manager relaying messages, because every layer between you and the work is a layer where detail gets lost.

How to structure the engagement

The lowest-risk arrangement is a small paid discovery phase that produces a written specification, followed by a fixed quote against that specification. Discovery is cheap relative to a build, it tells you how the studio thinks and communicates before you are committed, and the specification belongs to you — you can take it to someone else if the working relationship does not convince you.

If you want to see how one studio answers these questions before you ask them, our software development service sets out the scoping and architecture stages, what each produces, and what you receive at handover.