Roshana Ghemoshu
software engineer
Roshana Ghemoshu has a keen interest in the evolving world of technology and its impact on everyday business. She enjoys exploring new trends, innovative ideas, and the ways digital advancements are shaping how businesses operate and connect with people.
Choosing a software partner is a multi-year commitment. A weak selection process leads to missed deadlines, rising costs, and a system nobody can maintain. This guide gives you a structured way to compare vendors, including us.
It is written for procurement and IT heads at banks, cooperatives, hospitals, manufacturers, and other large organisations who are shortlisting a software company in Nepal and want to run a fair RFP.
Buyer's checklist
| Area | What to ask | Good sign | Warning sign |
|---|---|---|---|
| Relevant experience | Similar projects, with references you can call | Willing to share contactable references | Only generic claims |
| Team | Who will actually work on your project? | Named people and roles | "We'll assign someone" |
| Process | How do they plan, build, test, and report? | Regular demos and written updates | Report only at the end |
| Quality | How do they test? | Test plans and a review process | "We test at the end" |
| Security | Access control, data handling, confidentiality | Clear written practices | Vague answers |
| Code and IP | Who owns the code and documents? | You own it, in writing | Unclear or retained by vendor |
| Pricing | Fixed price, T&M, or retainer? | Clear scope and change process | Low price with open-ended changes |
| Support | What happens after launch? | Defined support terms | No post-launch plan |
| Communication | Who is your contact, and how fast do they reply? | A named lead with a response time | Many hand-offs |
| Subcontractors | Will any work be outsourced? | Disclosed up front, with the same standards | Found out later |
| Local presence | Can they meet you and support you on site? | Clear support hours and escalation path | One contact, no backup |
RFP template outline
Background: Briefly explain who you are, what your organisation does, and why you need this project.
Objectives: Define what success looks like, including measurable goals, expected outcomes, and performance targets.
Scope: Outline the required features, intended users, integrations, and any items that are outside the project scope.
Technical Needs: Specify the preferred platforms, existing systems, hosting requirements, security standards, and data management rules.
Timeline: Provide key dates, project milestones, expected delivery deadlines, and testing and launch schedules.
Vendor Questions: Ask about the vendor’s relevant experience, team expertise, development process, client references, and use of subcontractors.
Pricing Format: Provide a standard pricing table to compare proposals, with separate costs for development, hosting, maintenance, support, and future change requests.
Evaluation Criteria: Define how proposals will be assessed based on experience, technical approach, team capabilities, price, and project risks, with clear weights assigned to each criterion.
Terms: Clarify payment schedules, intellectual property ownership, confidentiality requirements, warranty coverage, ongoing support, and project exit arrangements.
Submission Rules: State the proposal deadline, required submission format, contact person, process for asking questions, and final date for submitting queries.
Public-sector buyers: if you are a public body, your process is set by the Public Procurement Act and Regulations. Use the standard bidding documents and the PPMO's e-GP system rather than a custom RFP format.
Scoring tip: Use a simple matrix. Score each vendor 1 to 5 per criterion, multiply by the weight, and total it. Have at least two evaluators score independently, then compare.
Before you sign
- Call two references.
- Ask for a paid discovery or small pilot if the project is large.
- Agree how changes are priced.
- Agree who owns code, documentation, and data, and what handover looks like.
- Set milestones tied to working software, not just calendar dates.
Risks: Choosing on price alone, vague scope, and no exit plan.
How Quark Infotech can help
You are welcome to send your RFP to Quark Infotech. We will review it, help you tighten the scope and requirements, and tell you honestly if we are not the right fit for your needs.
If you have not written an RFP yet, we can also help you scope your project requirements before you invite vendors. You get a clearer brief and fairer proposals to compare.
FAQs
Should we always run a tender?
For large or long projects, yes. For small ones, a structured comparison of two or three vendors is enough.
Fixed price or time and materials?
Fixed price suits clear scope. Flexible models suit evolving products.
How many vendors should we invite?
Three to five is usually enough to compare options without overloading your evaluators.
Should we pay for a pilot?
For a large project, a paid discovery or small pilot shows how a vendor really works before you commit to the full contract.
What should we do if the cheapest bid is far below the others?
Ask the vendor to explain what is and is not included. A very low price often hides open-ended change costs.
Need help integrating payments? Book a free 30-minute call with our team.
Enjoying this read? Help others find it too.
