Figuring out how to hire a developer when you cannot read code yourself is one of the most stressful decisions a non-technical founder makes. You are about to hand someone money and trust to build something you cannot personally inspect, in a language you do not speak. The fear is rational. I have spent over a decade hiring, managing, and occasionally firing developers, and I have also been the developer called in to rescue projects after a bad hire burned through the budget.
Here is the good news: you do not need to judge code to judge a developer. You need to judge output, communication, and honesty. Those three signals are visible to anyone paying attention, and this guide shows you exactly where to look.
The single biggest mistake is hiring on credentials and confidence. Certificates, years of experience, and smooth talk correlate weakly with the ability to ship working software. What correlates strongly is a track record of finished things and the way someone behaves when given a small, real task.
Stop Interviewing, Start Testing
A traditional interview measures how well someone interviews. For developers, that is nearly useless to you, because the best builders are often mediocre talkers and the worst builders are often excellent talkers.
Replace most of the interview with a small paid trial project:
- Scope it to 3 to 5 days of work. Something real but contained. A landing page connected to a form. A simple report pulled from your sales spreadsheet. A small fix to your existing website.
- Pay for it. For the Indonesian market in early 2022, budget roughly Rp1 to 3 million depending on seniority. This is the cheapest insurance you will ever buy. A Rp2 million trial that saves you from a Rp60 million failed project is a bargain.
- Give deliberately imperfect instructions. Do not polish the brief. Real work arrives messy. What you are testing is whether they ask clarifying questions before starting, or whether they charge ahead and build the wrong thing.
The trial tells you in one week what three interviews never will.
What to Watch During the Trial
You cannot evaluate the code, so evaluate everything around the code. These signals are readable by anyone:
- Questions before work. A good developer reads your brief and comes back with two to five sharp questions. Silence followed by a deliverable is a red flag, even if the deliverable looks fine. It means they guess instead of confirm, and guesses get expensive at scale.
- A realistic estimate, with reasoning. Ask how long the trial will take. "Two days" with no explanation is worth less than "About four days: one for setup, two for the main feature, one for testing, and it could slip if your hosting access is slow." The second answer shows they have done this before.
- Progress communication without prompting. Did you get a short update midway, or did you have to chase them? The behavior you see during a paid trial, when they are on best behavior, is the best you will ever get.
- How they handle a change. Midway through, ask for one small change. A professional says "sure, that adds about half a day" or "we can, but it conflicts with X, here is a simpler option." A talker says yes to everything and delivers none of it.
- A working handover. At the end, can they show you the thing running, explain what they built in plain language, and hand over all access and files? If the handover is vague, the ownership of your own project is vague.
Interview Questions That Separate Talkers From Builders
Keep the interview short and use it for signals the trial cannot give you. These questions work even if you understand none of the technical answers:
- "Tell me about a project that went badly. What happened?" Builders have war stories and own their share of the blame. Talkers claim every project succeeded, which means they are either lying or have never done anything hard.
- "What would you do in the first week if we hired you?" Good answer: understand the business, read what exists, ship something small. Bad answer: rewrite everything with a new framework. Rewriting is how developers entertain themselves at your expense. I have written before about why boring choices win in The Case for Boring Technology.
- "Explain to me, like I am a customer, what happens when I click 'buy' on a website." You are not testing accuracy. You are testing whether they can translate technical work into plain language, because you will need that translation every week for the entire engagement.
- "What should I NOT build yet?" The most valuable developers push back on scope. Anyone who agrees your entire five-feature dream can ship in one month is telling you what you want to hear.
What to Pay, and the Trap of Cheap
Rough monthly benchmarks for Indonesia in early 2022, full-time equivalent:
| Level | Monthly range (IDR) | What you get |
|---|---|---|
| Junior (0 to 2 years) | 5 to 9 million | Needs direction and review, risky as a solo first hire |
| Mid (2 to 5 years) | 9 to 18 million | Can own a small product end to end, the sweet spot for a first hire |
| Senior (5+ years) | 18 to 35 million+ | Overkill full-time for most SMEs, excellent part-time or as an advisor |
Freelance day rates run roughly Rp300 thousand to Rp1.5 million across that same range.
The trap: hiring the cheapest junior as your only technical person. A junior developer with nobody senior to review their work is not a bargain, it is deferred cost. The rescue projects I get called into almost always start this way. If budget is tight, a better structure is a mid-level developer part-time, or a freelancer paired with a few hours a month of senior review.
Structure the Engagement to Protect Yourself
- Milestones, not lump sums. Pay 20 to 30% upfront at most, then per delivered milestone. Every milestone must end with something you can see working, not "backend progress."
- You own the accounts. Domain, hosting, source code repository, all registered under your email, from day one. This is non-negotiable. Losing access to your own product because a freelancer disappeared is a story I have heard dozens of times.
- Weekly demos. Fifteen minutes, they show you the actual product running. Not slides, not "almost done." Working software or a clear explanation of the blocker.
- Write down what "done" means. One page describing what the finished thing does, agreed before work starts. Most disputes are not about bad code, they are about two people who imagined different products.
Hiring a developer is one decision inside a bigger question of where technology fits your business at all, which I covered in Why Your Business Needs a Technology Strategy, Not Just a Website.
The Practical Takeaway
You do not need technical knowledge to hire well. You need a process that makes competence visible: a small paid trial, attention to questions and communication, milestone payments, and ownership of your own accounts. Credentials and confidence are cheap. Finished work and honest scoping are the real currency.
If the project is bigger than one developer can carry, or you want someone senior evaluating the work on your behalf, that is exactly the kind of engagement I take on selectively through my partnership page. Either way: test output, not talk.