Write the brief before you contact a single vendor
Nepal's software outsourcing market has grown quickly, and that growth means capability now varies widely between firms with similar-looking websites. Before requesting quotes, write a short brief covering the problem you are solving, the platforms involved, rough scope, target launch window and whether you need a dedicated team or a fixed-scope project. A vendor cannot give a meaningful estimate against a vague idea, and a vague brief makes every quote impossible to compare fairly.
Your brief should include specifics: if you need a mobile app, specify iOS only, Android only, or both; mention your target user base and expected scale; clarify whether you need ongoing maintenance included post-launch. For example, rather than 'build an e-commerce platform,' write 'build a React/Node.js marketplace for Nepali handicraft sellers, starting with 50 initial merchants, supporting card and mobile wallet payments, launching in 3 months, with 6 months of included post-launch support.'
Decide internally whether you are hiring for a one-time build, an extended product team, or ongoing maintenance after another company's handover. Each model changes who you should shortlist. A firm that excels at short fixed-price websites is not automatically equipped to run a multi-year product roadmap, and a staffing-style outsourcing shop is not the right fit for a tightly scoped MVP with a hard deadline.
Document any constraints upfront: budget ceiling, non-negotiable launch date, required technology stack, must-have integrations with existing tools. Share this brief with 3–5 shortlisted vendors and evaluate whether their proposals acknowledge and address each point, since a vendor that skips constraints in their response is likely to cause problems later.
Ask for proof, not a portfolio slideshow
A polished case study page tells you what a company wants to show, not what it can actually deliver under your constraints. Ask for a live product URL you can use yourself, a reference client you can contact directly, and the specific role the vendor played on a listed project, since some Kathmandu firms subcontract parts of delivery without disclosing it upfront.
For technical due diligence, request a short paid trial task or a code sample review rather than relying on a sales call alone. A 2–3 day paid proof-of-concept (POC) can reveal more about a team's speed, code quality, and communication than weeks of conversation. Example: ask them to build a basic API endpoint that integrates with your existing backend, then review the code for structure, error handling, and documentation. Pay them fairly for this work ($500–1000 is reasonable), since underpaid trial work often produces below-standard results.
Ask who will actually be assigned to your project, their experience level, and whether the senior engineer in the pitch meeting stays involved during execution or hands off to a more junior team once the contract is signed. Get names and LinkedIn profiles of the team that will work on your project, not just the sales contact. A common pattern is senior devs pitch, juniors execute—this creates quality and communication risk.
Request a reference client currently using the vendor for a similar project, and actually call them. Ask: Does the vendor hit deadlines? How do they handle scope creep? What was the quality of the handover? Would they hire them again? A reference client who hesitates or says 'mostly good' is a red flag.
Compare pricing models honestly
Kathmandu vendors typically quote fixed price, time and materials, or dedicated monthly team rates. Fixed price feels safer for a first engagement but only works when the scope is genuinely fixed; any ambiguity becomes a change-request negotiation later. Time and materials suits evolving products but requires more of your own oversight to control spend.
Example: A vendor quotes $50,000 fixed price for an MVP. That sounds clear until you discover 'cloud hosting' costs $2,000/month (surprise), 'security audit' is billed separately ($5,000), and 'training your team' is not included. The real cost becomes $60,000+. With time-and-materials, you might pay $6,000/month for 3 months ($18,000) but get transparency on every hour and can adjust scope weekly.
Whatever model you choose, ask what is excluded: third-party licenses, cloud hosting, QA time, project management overhead, bug fixes after 30 days, and post-launch support windows. Create a spreadsheet comparing total cost for each model under realistic assumptions, including these hidden costs. The lowest headline day rate ($30/hour) can still produce the highest total cost ($80,000) once exclusions surface midway through the project.
For fixed-price contracts, negotiate a change-request process that does not punish you for legitimate scope adjustments. Example: 'First 15% of scope change is included; beyond that, we quote together.' For time-and-materials, set a hard spend ceiling and require your approval for any month that approaches it.
Test communication before signing anything
Time zone overlap and communication habits matter more than most founders expect during vetting. Kathmandu is UTC+5:45; if you are in Europe or US, you have limited real-time overlap. Before committing, run a short paid discovery phase (1–2 weeks) and observe: Do they document decisions in writing? Do they flag risks proactively, or wait for you to discover problems? Do updates arrive on schedule without you chasing?
During the discovery phase, set up a daily standup and note whether attendance is consistent. Late standups, skipped meetings, or vague status updates are early warning signs. Example red flags: 'working on the API' (vague) vs. 'completed user login endpoint with JWT auth, now testing email verification' (specific).
Ask which tools they use for tracking work (GitHub, Jira, Monday?), code review, and deployment. Request read-only access during discovery so you can see actual commit history, pull request feedback quality, and deployment frequency. A vendor unwilling to give visibility before a contract is signed is unlikely to become more transparent once invoices are flowing.
Try a real-world scenario: Email a problem at 2am your time and see if they respond with a thoughtful answer by morning, or send a canned 'ticket created' response. Good vendors actually read and engage; bad ones have templated workflows that block communication.
Protect intellectual property and code ownership
Confirm in writing that source code, design files, credentials, and all documentation transfer fully to you upon final payment. Do not accept 'compiled build only' or 'we keep source code for support.' Insist your company or a neutral third party holds the GitHub repository as the single source of truth during development.
Example clause: 'All work product created under this agreement, including source code, design files, documentation, and any derivative works, shall be owned exclusively by [Your Company] upon payment in full. Vendor shall not use, reuse, or license any portion of this work for other clients without written consent.' This is non-negotiable.
Before development starts, sign a mutual non-disclosure agreement (NDA) covering your business model, customer data, and technical architecture. Many Kathmandu vendors have seen dozens of ideas; you do not want yours in their portfolio as a case study or pitched to a competitor.
Clarify how the vendor handles staff turnover. Example: If your primary engineer leaves mid-project, who takes over? Is there a onboarding cost? Get this in writing: 'If primary developer leaves, vendor shall assign a qualified replacement within 5 business days at no additional cost, and shall provide 1 week of overlap for knowledge transfer.'
Plan the handover from day one
Before the project starts, write a 'Definition of Done' that includes: source code in your repo with clear README, deployment documentation, credentials secured (no hardcoded keys), automated tests with >70% coverage, and a 30-minute onboarding call where the vendor walks your team through the codebase.
Ask specifically: How will environment variables be managed? (Should be in .env.example, never in code.) Where is the database schema? How do I deploy to production? What monitoring should I set up? Example: A vendor hands over code but no deployment guide; your team spends 3 weeks figuring out production setup, missing your launch date.
Agree on a post-launch support window in writing. Example: '30 days of free critical bug fixes, max 2 hours per week. Non-critical bugs: $150/hour. Beyond 30 days: $6,000/month for ongoing support.' Be specific about response time: 'Critical bugs: 4-hour response, 24-hour fix target. Non-critical: next business day response.'
Schedule a final retrospective call before handing over. Ask: What went well? What would we do differently? Any technical debt we should address before I take over? Document the answers and include them in your project archive for future developers.
