Ask them to explain your workflow back to you
Bring an example form, spreadsheet, report, or prototype. Ask the team to identify the main user, the task, and the likely exceptions. Their questions should help you make the scope clearer, including what is not yet known.
Look for a proposed first release with a concrete outcome. A promise to build everything immediately is harder to assess than a delivery plan that explains the first useful workflow and how it will be checked.
Compare evidence and delivery practice
Request relevant examples and ask what the team actually contributed. If a project is confidential, discuss the methods and responsibilities they can explain without exposing a client's information. Do not assume a screenshot proves they built or maintain the whole system.
Ask how staff will try the software during development, who consolidates feedback, and what happens when a requirement changes. Agree the acceptance checks before the final handover rather than relying on a demonstration alone.
Use the same evaluation questions for every company
A structured comparison prevents a polished presentation from outweighing delivery details. Share the same context with each shortlisted partner and let them state what they still need to learn. Strong answers are specific to your workflow and identify tradeoffs; they do not need to promise that every request is simple.
| Ask about | A useful answer explains | Warning sign |
|---|---|---|
| First release | One valuable outcome, its boundaries, and how users will test it | A promise to deliver the complete wish list without prioritization |
| Team and evidence | Who will do the work and what the referenced example proves | Screenshots with no clear contribution, role, or maintainership |
| Delivery | Review cadence, feedback responsibility, risks, and change handling | No access to working software until the final demonstration |
| Ownership and support | Accounts, code, data, deployment, documentation, and response scope | Important access remains personal or handover is left undefined |
Clarify ownership and ongoing support
Make account access, source code handover, and deployment responsibilities explicit in the agreement. Ask which recurring services you will pay for and who is responsible for updates, backups where applicable, and incident handling.
If another team may maintain the application later, discuss the documentation and access they would receive. For an existing system, expect a review before a new provider commits to maintaining it.
- Written scope, assumptions, exclusions, and milestones
- Named responsibilities for decisions and feedback
- A method for testing real workflows before release
- Access and handover arrangements
- Maintenance scope and response expectations
Match the working relationship to the project
Searching for a software engineer in Bhaktapur or Kathmandu may help you find an individual contributor. A company engagement should also make product decisions, delivery coordination, and support responsibilities clear. Decide which of those responsibilities your own team can carry.
Kabeli is based in Kathmandu and works with organizations in Bhaktapur, Kathmandu Valley, and across Nepal. A first conversation can start with the process you want to improve, your current tools, and your budget or deadline.
Run a small paid engagement when uncertainty is high
For a complex or inherited system, consider starting with discovery, a technical review, or a small vertical slice. The deliverable should reduce a named uncertainty: a workflow map, data assessment, integration test, prioritized release scope, or working end-to-end feature.
A trial should not become unpaid speculative work or an indefinite planning phase. Agree its questions, outputs, access, fee, and decision point. The result should be useful even if you choose a different company for the larger implementation.