To hire your first developer when you are not technical, define the problem and the outcome in plain words, choose the engagement type (employee, freelancer, agency or advisor-led), ask a trusted technical person to review the evidence, test with a small paid task, and set up ownership of code, accounts and data in writing from day one. You do not need to read code to judge communication, reliability and results.
Key takeaways
- Describe what the product must do for users, not which technology to use. Let the developer propose the technology.
- Pick the engagement type that fits the stage: freelancer for a defined build, employee for ongoing work, advisor for review.
- Use a technical reviewer, even for a few hours, to check evidence you cannot judge.
- Test with a small paid task and a short plan. Judge communication as well as code.
- Own your accounts: repository, hosting, domains and data must be in your name.
What is different when you are not technical
A technical founder can read code and ask sharp questions. A non-technical founder has three risks: not knowing if the work is good, not knowing if the price is fair and not knowing if the developer is honest about time. You can lower all three with a clear brief, a reviewer and small steps with checkpoints.
You can judge more than you think. You can judge whether the developer asks good questions, explains in plain words, delivers on small promises, shows progress in working software and respects your budget and deadlines. These are strong signals of a good hire. A technical reviewer can then check quality in a few hours.
Step 1: Define the problem, not the technology
Write a one-page brief. Use the structure from the one-page role brief.
| Part | Question | Example (fictional) |
|---|---|---|
| Users | Who will use it? | Clinic receptionists booking appointments |
| Problem | What is hard today? | Double bookings and phone calls take three hours a day |
| Outcome | What should be true in 3 months? | Booking page live; double bookings fall; receptionists use it daily |
| Must-haves | What must the first version do? | Show free slots; confirm by email; let staff edit bookings |
| Not now | What can wait? | Payments, mobile app, reports |
| Constraints | Budget, deadline, rules | Fixed budget; must handle personal data lawfully |
| Success measure | How will you know? | Number of bookings made online; fewer phone calls |
A good developer will ask questions about this brief and may suggest changes. That is a positive sign. A developer who agrees with everything without questions is a warning.
Step 2: Choose the engagement type
| Option | Fits when | Pros | Cons |
|---|---|---|---|
| Employee (full or part-time) | You have ongoing work and a roadmap for a year or more | Deep knowledge of your product; stable | Cost, notice and management time; hiring risk |
| Freelancer | A defined build or a set of features | Flexible; no long commitment | Availability; knowledge leaves when they leave; status rules apply |
| Agency or studio | You need a team (design, development, testing) for a project | Broad skills, process | Higher day rates; less control; handover risk |
| Technical co-founder or partner | Product is core to the business and you want shared ownership | Shared risk and commitment | Equity, legal and relationship complexity; take advice |
| Advisor plus junior developer | You want review by someone senior at low cost | Quality check at modest cost | Needs coordination |
If you choose a freelancer, check the status rules in employee or contractor. If you choose an employee, use the cost worksheet to plan the full cost.
Step 3: Find a technical reviewer
A reviewer is a senior developer or technical lead who is not applying for the job. They can be a friend, a former colleague, a mentor or a paid consultant for a few hours. Ask them to do three things: read the brief and say if it is realistic, review the candidate’s past work or a test result, and join one interview to ask technical questions. Pay them a fair fee, and tell them that they are not responsible for the hiring decision. Give them the same scoring sheet as other interviewers.
Step 4: Write the ad and screen
Describe the product, the outcome, the stack only if you already have one, the working style, the hours and the pay range. Do not list every technology you have heard of. Pick three to five must-haves such as “has built and launched a web application used by real users” and “writes clear documentation”. See how to write a job ad that attracts the right applicants.
For screening, use evidence from the CV and links: live products, public code, a portfolio or a description of a past project with the candidate’s role. Ask the technical reviewer to look at a sample. Use a screening sheet. See structured screening.
Step 5: Interview with questions you can judge
| Area | Question | What to listen for |
|---|---|---|
| Past work | Tell me about a product you built that real users used. What was your part? | Clear role, real users, honest account of problems |
| Communication | Explain to me, as if I am not technical, how you would build the booking page. | Plain words, steps, no jargon wall |
| Estimation | How would you estimate the time? What could make it slower? | Ranges, risks, questions |
| Trade-offs | What would you leave out of the first version, and why? | Focus, judgement |
| Quality | How do you test your work? How do you handle bugs? | A real method, such as tests and reviews |
| Collaboration | Tell me about a disagreement with a client or manager. How did it end? | Respect, facts |
| Maintenance | What happens after launch? Who fixes problems? | Awareness of ongoing work |
Ask your reviewer to add three or four technical questions that they score on the same scale. Do not ask about protected characteristics. See what you can and cannot ask.
Step 6: Test with a small paid task
A small paid task reduces risk for both sides. Choose a task that takes four to eight hours, uses a made-up or non-sensitive problem, and has a clear outcome, such as “build a simple page that lists free slots from a data file and write a short README”. Pay a fair rate for the time, and tell the candidate how you will score: working result, clarity of explanation, code organisation as judged by your reviewer, and communication during the task. See how to assess skills with a work sample test for rules on pay and fairness.
Step 7: Set up ownership and security
Before work starts, put these in writing. This protects you and the developer.
| Item | What to agree |
|---|---|
| Ownership of the work | Who owns the code and the designs. Employees often create work that belongs to the employer by default in many countries, but not everywhere. Freelancers usually need a written assignment or licence. Take legal advice for your country |
| Accounts | Repository, hosting, domain, app store accounts and analytics are created in your name or company name. The developer is added as a user |
| Access | Give the minimum access needed. Use separate logins, not shared passwords. Remove access when the work ends |
| Data protection | If the product handles personal data, agree the rules. In the UK and EU, GDPR applies. Check the ICO guidance and your national authority |
| Documentation | A README, set-up notes and a list of services used |
| Payment and milestones | Fee, milestones, review points and what counts as done |
| Ending | Notice, handover and return of access |
This is general information, not legal advice. A short review by a lawyer is worth the cost for a contract that covers your core product.
Red flags and green flags
| Red flag | Why it matters |
|---|---|
| Refuses to explain in plain words | You cannot manage what you do not understand |
| Promises very fast delivery for a low price without asking questions | Likely to miss scope |
| Wants all accounts in their own name | You could lose control |
| No examples of finished products | Cannot judge experience |
| Avoids a paid test but asks for full payment up front | Risk for you |
| Blames former clients for every problem | Pattern risk |
| Green flag | Why it matters |
|---|---|
| Asks many questions about users and goals | Cares about the outcome |
| Proposes a smaller first version | Understands risk |
| Shows working software early and often | Visible progress |
| Documents decisions | Reduces dependence on one person |
| Admits what they do not know | Honest |
A worked example (fictional)
This example is invented. A non-technical founder of a small tutoring company needs a booking tool. She writes a one-page brief, asks a former colleague who is a senior developer to act as reviewer for four hours, and posts the ad. She screens eight applicants with a sheet and interviews four with the same questions. Two do a six-hour paid task. The reviewer says both solutions work, and one is better organised. The founder’s own scoring shows that one candidate sent a progress note after three hours and explained a choice clearly. The other sent nothing until the end. She hires the first as a part-time freelancer for three months with an assignment of the work in writing, accounts in the company name and two-weekly demos. At the three-month review, the booking tool is live and used by teachers. She then decides whether to extend or hire a part-time employee.
Your first 90 days with the developer
| Period | Focus | Your actions |
|---|---|---|
| Days 1 to 14 | Set up accounts, agree the first milestone | Share brief; give access; schedule demo every two weeks |
| Days 15 to 45 | First version in test | Try it as a user; write down what is confusing; keep scope small |
| Days 46 to 90 | Launch and learn | Release to a few users; track the success measure; decide next steps |
Review progress with your technical reviewer once a month for the first quarter. Keep a log of decisions and changes. This record helps you if the developer leaves and a new person starts.
Questions to ask your technical reviewer
| Stage | Question for the reviewer |
|---|---|
| Before the ad | Is the brief realistic for the budget and time? What is missing? |
| Screening | Which of these portfolios show real, working products? Which look copied or thin? |
| After the paid task | Is the code organised and readable? Are there tests? Could another developer take it over? |
| Before the offer | Did the candidate answer your technical questions with sound reasoning? Any concerns? |
| After three months | Is the product maintainable? What are the largest risks? |
Ask for short written answers. Keep them with your decision record. Remember that the reviewer’s view is one input and that you decide.
What it may cost, and how to check
Rates for developers vary by country, skill and type of work. Do not rely on a single number from the internet. Ask for quotes from at least three people for the same written brief, and compare how they break down the work. A big difference between quotes often means the brief was understood differently, so ask each person to explain their assumptions. For employee costs, add employer taxes and contributions using the official sources for your country. See the cost of hiring an employee.
Official sources for this topic: GOV.UK: employing people, US Small Business Administration: hire and manage employees. These pages are maintained by the authorities and may change, so check them for the current text.
Frequently asked questions
Do I need a technical co-founder?
Not always. Many non-technical founders work with freelancers, agencies or employees and a technical reviewer. A co-founder involves equity and a long-term relationship, so decide carefully.
How do I know if the code is good?
Ask a trusted technical reviewer to check a sample. Also judge outcomes: working software, fewer bugs, clear documentation.
Should I hire a freelancer or an agency?
A freelancer suits a defined, small build. An agency suits a project that needs several skills. Compare cost, control and handover.
Who should own the code?
You or your company, by written agreement. Take legal advice for your country, especially for freelancers.
How much should I pay?
Compare local market sources and quotes for similar work. Do not accept the lowest or highest quote without a reason. Use the cost worksheet.
Related guides
- Hiring guides for small businesses and founders
- How to define a role before you hire: a one-page role brief
- Employee or contractor? How to choose for your first role
- How to assess skills with a work sample test
- All hiring guides for employers
This is general information, not legal advice.