Part of our guide hub: Custom software development
Most failed software projects in Pakistan were not failed by bad code. They failed because the wrong partner was chosen for the wrong reason, usually price, and the problems were visible in the first meeting to anyone who knew what to look for.
Here is what to look for.
The eight questions that actually separate them
1. Show me something you built two years ago that is still running
The most useful question in the entire evaluation. Anyone can show a portfolio of launches. Very few can show software that survived two years of real use, changes and maintenance.
Ask what it cost to build and what it has cost to keep running. An agency that has maintained enough work will know. One that cannot answer has been launching and leaving.
2. Who exactly will work on this, and what else are they on
The classic agency problem is that the senior people appear in the sales meeting and juniors do the work. Ask for names, ask to meet them, and ask how many other projects they are on. Being on three simultaneously is normal; being on six is a warning.
3. What will you deliver in the first two weeks
A good answer is specific: wireframes for the main flow, a working environment, a scoped backlog. A vague answer about requirement gathering means the first month will produce documents rather than progress.
4. What happens when I want to change something halfway
The answer reveals their process. Anyone who says changes are free is either lying or planning to absorb the cost by cutting quality elsewhere. You want a clear, unemotional change process with a price attached.
5. Who owns the code, and where does it live
The code should be in a repository you own, from day one, with your team having access. Agencies that keep the code on their own machines and hand over a zip file at the end have you locked in, and that is exactly when the maintenance quotes get expensive.
6. What is not included
The most revealing question and almost never asked. Content, hosting, third party licences, payment gateway onboarding, data migration, training, post launch support. A quote that includes everything is usually a quote that has not been thought through.
7. What does support look like after launch
Response times, what counts as a bug versus a new request, and what it costs. Software is never finished; the only question is whether the arrangement is agreed in advance or negotiated during an outage.
8. Can I speak to a client who had a difficult project with you
Anyone can supply a happy reference. Asking for a difficult one tests honesty. The best answer is a candid story about something that went wrong and how it was handled. An agency that claims nothing has ever gone wrong has not done enough work.
Four warning signs that predict failure
- A fixed price quoted in the first meeting, before anyone understood the requirement. It is either padded heavily or it will be recovered through change requests later.
- Agreement with everything. A partner who never pushes back on scope, timeline or a bad idea is selling, not consulting. You want the person who says a feature is not worth building.
- No questions about your business. If the conversation is entirely about technology and never about how you make money, the software will reflect that.
- A price far below the others. Usually means fewer people, less experienced people, no QA, or a plan to recover margin through variations. Software has a floor cost, and quotes below it get paid eventually.
How to compare quotes that are not comparable
Quotes for the same brief routinely vary by five times. Before comparing numbers, normalise them:
- Does each include design, or is one assuming you supply it?
- How many revision rounds are included?
- Is QA a line item, or assumed?
- Is data migration in scope?
- Is there a support period after launch, and how long?
- Are third party costs included or passed through?
Rebuild each quote to cover the same list and the spread usually narrows dramatically. Our breakdowns of website costs and app costs in Pakistan explain what should be inside each band.
What to put in the contract
- Scope, written as a list of what is included and what is not.
- Payment tied to milestones, not to dates. You pay for delivered things.
- Code ownership and repository access from day one.
- A named decision maker on each side with authority to answer within 24 hours. This clause prevents more delay than any other.
- Revision rounds, with a price for additional ones.
- A support period after launch, typically 30 to 90 days for bug fixes at no charge.
- An exit clause. What you receive if the relationship ends early: code, credentials, documentation, data.
Freelancer, small agency or software house
- Freelancer: right for a template website, a small tool, or a well defined piece of work. Risk is availability and what happens if they stop answering.
- Small agency: good value for business websites and standard applications. Check that they have QA and more than one person who knows your project.
- Established software house: worth the premium for anything touching payments, customer data, compliance, or systems the business cannot operate without. You are paying for process and for someone answering in year three.
Frequently asked questions
How much should I pay for a software project in Pakistan?
It depends entirely on scope. Rather than a number, get three quotes normalised to the same inclusions and treat any quote far below the others as a risk rather than a saving.
Should I pay in advance?
Partial advance is standard and reasonable. Full payment before delivery is not. Tie payments to milestones you can inspect.
Who should own the source code?
You should, in your own repository, from the first commit. This is non negotiable and any resistance to it is itself the answer.
How do I know if a quote is realistic?
Check that it has line items for discovery, QA, data migration and post launch support. A quote weighted almost entirely to build is incomplete rather than cheap.
Ezitech has delivered 650 or more projects across 42 countries in more than ten years, and will tell you when a smaller partner or an off the shelf product is the better answer. See how we work or describe your project.
