The expensive first decision#

You have an idea, some budget, and no way to judge the people who will build it. That information asymmetry is the real problem of a first engineering hire: every route - freelancer, agency, or employee - can produce a great product or an expensive rewrite, and from the outside the pitches look identical.

The fix is not learning to code. It is running a process that lets you compare candidates on evidence instead of confidence: a clear route decision, a paid trial task scored on a rubric, and ownership of every account from day one.

Your three routes (and option zero)#

Option zero is a technical co-founder. If someone in your network can fill that role, it beats every option below - YC's hiring guide calls personal networks the most effective source for a first hire by far. This article assumes that option is not available to you right now.

Route Best for Watch out for Commitment
Freelancer A scoped prototype or MVP with clear deliverables Continuity: one person, one point of failure Hourly or fixed, weeks
Agency A managed build - design, PM and dev bundled, with a deadline Cost, handover quality, the "senior in the pitch, juniors on the work" swap Fixed project price
First in-house engineer A product that is the company and will iterate for years You must manage technical decisions you cannot yet judge Salary, usually plus equity
Flowchart for choosing between freelancer, agency, and in-house first engineer based on timeline, budget, and whether the product is long-term
Which hiring route fits your situation

Two rules of thumb behind the flowchart:

  • The more the product will change after launch, the worse fixed-scope contracts fit. A fixed-price agency quote on a product that will iterate for years buys you the first chapter, not the book.
  • Nobody on any route is "yours" until the accounts are. A great freelancer with the repo under their personal account is a bigger risk than an average one with everything in yours.

How to evaluate when you can't read code#

You cannot judge code quality directly. You can absolutely judge behavior - and behavior predicts the engagement better than a portfolio does.

Red flags, on every route:

  • They quote a price before asking questions about your business, your users, or what "done" means.
  • They promise fixed price, fixed scope, and a fixed date, all up front.
  • They suggest building under their own accounts or infrastructure "and transferring it later."
  • They cannot show a single shipped product, public code, or a reference you can call.
  • No mention of version control, tests, staging, or documentation in their process.
  • (Agencies) The senior person sells, then disappears after the signature.

Green flags: they push back on your scope, propose a smaller first version, offer weekly demos, and insist - before you do - that everything lives in accounts you own.

The paid trial task#

The single best de-risking tool costs a few hundred dollars: a small, real, paid task.

  • Scope it to roughly 4-10 hours. Always pay, whatever the outcome - asking for free work filters for candidates with no other options.
  • Pick something real but off your critical path: a small feature, a spike on a risky integration, a one-page technical plan for your MVP.
  • Give every finalist the same task, so scores are comparable.
  • Score with a rubric, not a gut feeling. YC's advice for first hires is the same idea: write down your criteria in advance and mark each candidate against them.
Criterion (weight) A 1 looks like A 5 looks like
Communication (25%) Silent for days, then a delivery Sets expectations, flags blockers early, demo at the end
Code & output quality (25%) Does not run, no instructions Runs as described, README, sensible structure
Questions & judgment (20%) Builds exactly what you said, including the mistakes Challenges the brief where it was wrong, documents assumptions
Estimation honesty (15%) "Easy, two hours" - delivers late Gives a range, explains uncertainty, hits it
Business understanding (15%) Talks only about frameworks Connects the task to users, cost, and your next milestone

Score 1-5 per row, multiply by the weight, compare totals. A candidate who scores 5 on communication and 3 on code usually beats the reverse for a non-technical founder - you can get code reviewed; you cannot manage someone you cannot reach.

The ownership checklist#

Do this before anyone writes code. Each item is cheap on day one and expensive on day 100.

Checklist map of accounts a founder must own personally: code repository, domain, cloud account, payment gateway, app stores, password manager, and IP assignment
Own these from day one
  • The GitHub/GitLab organization is yours; the developer is a member or outside collaborator - never the other way around. Repos can be transferred later, but only by the owner.
  • The domain is registered in your name, to your email, with auto-renew on.
  • Cloud accounts (AWS, DigitalOcean, Vercel...) are created with your email and your card, billing alerts enabled; the developer gets scoped IAM access, not the root login.
  • Payment gateway, app store, analytics, and error-tracking accounts are registered to your company - they hold your money and your data.
  • A written contract with an IP assignment clause (work-for-hire where that exists). IP law varies by country; have a local lawyer review the template. Until this is signed, assume you do not own the code you are paying for.
  • Credentials live in a password manager you control, with 2FA on every account.
  • Weekly demos and code merged to a branch you can deploy. If your developer disappears tomorrow, you should lose a person, not the product.

Common mistakes#

Mistake Why it hurts Do instead
Letting the developer own the repo or accounts You can lose access to your own product and data Own every account from day one (checklist above)
Choosing on the lowest quote The cheapest build often becomes the most expensive rewrite Score finalists on the same paid trial task
Large upfront payment You lose all leverage the day it clears Milestone payments tied to working demos
No contract, or no IP clause You may legally not own what you paid for Lawyer-reviewed agreement before work starts
Building a huge "v1" Months of burn with zero user feedback Ship the smallest useful version, then iterate

Before you sign anything#

  • Route chosen deliberately (freelancer / agency / in-house), not by whoever replied first
  • At least two finalists completed the same paid trial task
  • Scorecards filled in, and the winner wins on the rubric, not on charm
  • Contract with IP assignment reviewed by a lawyer
  • Every account in the ownership checklist created under your name
  • First milestone defined small enough to demo within two weeks

Key takeaways#

  • The route matters less than the process: same task, same rubric, evidence over confidence.
  • Paying for trial tasks is the cheapest due diligence in the entire hiring process.
  • You cannot judge code, but you can judge communication, estimation honesty, and questions asked - and those predict the engagement.
  • Own the repo, the domain, the cloud account, the payment gateway, and the IP. Everything else is replaceable.

References#

Working through your first technical hire and want a second pair of eyes on your process? I mentor founders on exactly this - book a session.