Hiring Your First Developer When You Cannot Evaluate Code

Hiring an engineer when you cannot read the output is a genuine information problem, and most hiring advice ignores it. You cannot assess the code, you cannot judge the architecture, and the candidate knows both. What you can assess is whether someone explains their work clearly, whether their claims survive a paid trial, and whether the arrangement leaves you able to recover if it does not work.

Write down the first three things this person will ship

"A developer" is not a role. Someone who builds and maintains a customer-facing web product, someone who integrates and automates internal systems, and someone who does data and reporting work are three different hires with very little overlap in skill or temperament. Write down the first three things this person will ship in their first two months, with dates. If you cannot write that list, you are not ready to hire, and paying a contractor for those three specific things is the cheaper move.

The list also does work at the offer stage. A candidate who reads it and says "the second one is the hard one, and here is why" has told you more than an hour of interviewing would. If the list is really a product plan rather than a set of deliverables, cut it back first, the way you would when scoping an MVP.

Should the first one be an employee at all?

Often not. A salaried first engineer is the highest-commitment, highest-variance option available to you, and it is rarely the fastest. Three routes are worth pricing before you commit to any of them.

• A fixed-scope project with an agency. You get a working thing against a written scope, with someone else carrying the delivery risk. As a starting point, a marketing site is from around Rs 65,000 (about $900) over three to five weeks; software with logins, payments and dashboards starts from around Rs 320,000 (about $4,200) over six to twelve weeks. Those are starting points against a scope document, never quotes.
• A dedicated engineer on a monthly retainer. Around $2,200 a month with a three-month minimum, which is what our outsourcing arrangement costs. You get continuity without recruitment, payroll or a laptop budget, and you can stop at the end of a term.
• A salaried hire. Cheapest per hour in Nepal and the most expensive to get wrong: you carry recruitment, equipment, review capacity you may not have, and no cover when that person is ill or leaves.

The honest test is whether you have enough work to keep one engineer busy and enough judgement to review them. If either answer is no, hire the work rather than the person, which is the same decision teams weigh when they outsource to Nepal.

Test explanation and judgement, not code

You are fully qualified to evaluate how someone thinks out loud, so make that the interview. Ask a candidate to walk you through something they built: what the problem was, what they chose, what they would do differently now. Strong engineers describe trade-offs and mistakes without being prompted. Weaker ones describe technologies. You do not need to understand the stack to notice which of those two conversations you are in.

• Ask what they would remove from a past project, and why. An engineer who has never removed anything has never maintained anything.
• Ask how they would find out whether a change worked after it shipped. The answer should involve a number, not a feeling.
• Ask what they do when a requirement is ambiguous. The correct answer involves asking you, early, in writing.
• Notice whether they translate to your level without either condescending or hiding behind jargon.

The engineer who says "I do not know, here is how I would find out" is usually the one you want.

Ask directly how they use AI coding tools. The answer you want is specific and slightly bored, describing where the tools help and where their output was reviewed and thrown away. Either total dependence or total refusal is a flag, for the reasons in our piece on coding agents in a small team.

Pay for a real trial, at their normal rate

Skip the unpaid take-home puzzle. Pay for two or three days on a real item from your backlog, at whatever they normally charge. You learn how they scope, how they communicate mid-task, whether they ask the right questions on day one rather than day three, and whether the thing works at the end. They learn whether they want the job. At a few days of contractor rate it is the cheapest insurance you will buy all year.

Give the trial a written brief, a deadline and a definition of done. If you cannot write those for a two-day task, that is information about how the role will go.

The contract points that matter

Most first-hire contracts in Nepal are thin, and the gaps only show up when the relationship ends badly. You do not need an elaborate agreement, but you do need these clauses, and you should have a lawyer look at the final version rather than copying one from the internet.

• IP assignment. All work product created for the company is assigned to the company, on creation, whether or not the final invoice has been paid, with a clause covering pre-existing material they bring in. Without this, ownership of your product is genuinely arguable.
• Confidentiality. Mutual, with a defined term, covering customer data specifically and not just "business information".
• Notice period. One month either way is normal for a salaried role in Nepal; anything longer is unenforceable in practice. For contractors, set thirty days and use it.
• Handover obligations. Named in the contract: repository access, deployment credentials, environment variables, a written handover document, and two weeks of availability for questions after the last day.
• Outside work. Not a blanket ban, which people ignore, but a written declaration of anything competing.

Ownership is not negotiable. On every tier of work we do, the client owns the code, the domain and the hosting from day one, and your first hire should be held to the same standard: nothing important registered to a personal Gmail address.

Plan around the Nepali working week

The standard week here runs Sunday to Friday with Saturday as the single weekly holiday, which is a genuine advantage if your customers or investors are in the United States, Australia or Europe: Nepali Sunday covers their Monday morning before it starts. It also means Friday is a normal working day, so a Friday deploy is a Friday deploy, with the weekend arriving for you and your client at different times. Teams working mainly for Western clients often move to Monday to Friday instead. Decide which, write it into the offer, and do not leave it as an assumption.

Then put the holidays in the plan honestly. Dashain and Tihar fall between late September and mid-November and shift each year with the lunar calendar. Dashain typically closes offices for a week to ten days, with Tihar two to three weeks later for another three to five days. People travel, and mobile data in the hills is unreliable. Nothing large should launch in the fortnight before Dashain, and clients should hear about that in July, not October.

Reduce what a bad outcome costs

You will not catch technical problems early, so make the downside small. This is not distrust; a good candidate reads it as a company that has its house in order.

• Every account registered to a company email address you control: domain registrar, hosting, repository, analytics, app store listings, payment gateway.
• Code in your repository from the first day, with your billing on it, not on a personal account.
• A short written update every week: shipped, in progress, blocked, and what they need from you.
• Deployment that does not need one specific person awake; a basic pipeline on a small budget is enough.
• A named second technical person, even a paid advisor doing a quarterly review, who can look at the work and tell you the truth.

Set the first ninety days before the start date

Agree three concrete deliverables and a check-in schedule before day one, and write them down. At ninety days you should be able to point at working software that your customers are using. If you cannot, and the explanation is about groundwork, refactoring or infrastructure rather than outcomes, that is the signal. Acting on it at ninety days is cheaper for both of you than acting on it at nine months, and in a small company the difference is often the company.

If you would rather not carry that risk alone for the first year, an outsourced team is a reasonable interim step: working software plus someone who can review it, while you learn enough to hire well. That is most of what we do for founders in this position, and it is a smaller decision than a salaried hire in every direction.