You have an idea, a problem to solve, or a product that needs to exist. You don't have an engineering team. So you need a programmer — or a small team of them — and the search is harder than most other hiring you've done. Programmers are expensive, the field is full of mismatched titles, and the cost of picking wrong is months of wasted runway.
This is a practical guide written from the other side of the table — by people who get hired this way for a living. We'll cover the four real options for finding a programmer, how to compare them, what to look for in each, and the specific questions that consistently separate good fits from expensive lessons.
Start with what you're actually buying
Before you talk to anyone, get clear on which of these you need. They look similar in a job description and produce wildly different outcomes:
- A builder — someone who can take a vague idea and turn it into working software end to end. Designs, ships, makes judgment calls. Best for a first version of something new.
- A specialist — deep expertise in one thing (iOS, machine learning, payments, security). Best for a hard piece inside a larger system.
- An implementer — takes a clear spec and executes against it. Best when you already know exactly what you want.
- A team — a multi-person group that can sustain a project longer than any one person could. Best for anything past the proof-of-concept stage.
Most startups think they need a builder when they actually need a team, or hire an implementer when they actually need a builder. Get the type right and the search narrows by an order of magnitude.
The four real options
1. Hire a full-time employee
Best for: long-running products where you'll need an engineer indefinitely.
Worst for: pre-revenue startups still validating the idea.
You're looking at $130k–$220k all-in for a strong mid-level engineer in the US, more for senior, less in lower-cost markets. Add three to six months of search time and a 30–40% miss rate on first hires. The advantage is permanence: a full-time engineer accumulates context that contractors never will.
The mismatch most founders make here is timing. Hiring an FTE when you don't yet have product-market fit means you spend most of their first year either re-scoping or wishing you'd hired someone different. Wait until you have a stable problem before committing to a stable solution.
2. Hire a freelance or contract programmer
Best for: well-defined projects with a known endpoint.
Worst for: anything where the spec will keep changing.
Marketplaces (Upwork, Toptal, Arc, Contra) work but the variance is brutal. The same job posting attracts $25/hour freelancers and $250/hour ones, and the higher rate doesn't always correlate with better outcomes. References and a paid trial project — a small bounded piece of real work — beat any portfolio.
Freelancers are great for self-contained pieces of work: a checkout flow, an integration, a one-off automation. They become risky when you ask them to own something that lives past the engagement. Code without context decays fast.
3. Hire an agency or custom software firm
Best for: first versions of bigger projects, when you need design, engineering, project management, and QA in one place.
Worst for: cases where you already have most of those functions and just need execution.
Agencies trade per-hour cost for institutional capability. You get continuity if one person leaves, documented processes, and someone whose job it is to keep the project on track. The good ones charge $80–$200/hour blended. The bad ones charge the same but invoice for hours where almost nothing got delivered.
The interview question that matters most is: who specifically writes the code. Some agencies sell you senior engineers and assign juniors. Some staff you with full-time employees, others with subcontractors who'll disappear mid-project. Ask names and tenures, and ask what happens if those specific people leave.
4. Use a build partner with flexible engagement models
Best for: founders who want a partner who'll stick around past launch.
Worst for: cases where you genuinely want to own everything from day one and never hear from them again.
This is the model we use at SoftProgrammer, so I'll be transparent that I'm describing it from the inside. You can pay upfront and own the code (a one-time fee), pay monthly with hosting and support included (subscription), or share revenue once the product is generating it. Each shape fits a different stage of company.
The reason this exists is that custom software is rarely a one-and-done. Even a clean handoff comes back with questions in month three. A build partner is structured for the long arc, where a freelancer is structured for the engagement and an FTE is structured for the company. Pick the structure that matches your actual horizon.
How to compare options apples-to-apples
The five-year cost is the only honest way to compare. Don't compare an agency's $80k build quote to a freelancer's $40k quote — compare the total expected spend over the time you'll actually need software.
A rough model: take the upfront build cost, add hosting (typically $200–$2,000/month), add maintenance (typically 15–25% of build cost per year), add the cost of the inevitable Phase 2 work, and add the cost of finding a replacement when the original person moves on. Now you're comparing real numbers.
FTEs look expensive on year one and cheap by year five. Agencies look expensive on year one and stay expensive. Freelancers look cheap on year one and get expensive when you have to re-hire repeatedly. Build partners with hosting models look mid-priced and stay there. There's no universally best answer — there's the answer that matches your actual time horizon.
10 questions that reveal a good programmer or team
These questions have a high signal-to-noise ratio. Ask all of them in some form, of every candidate:
- Show me one similar project and walk me through what went wrong. Anyone who says nothing went wrong is either lying or hasn't shipped enough to know better.
- What's your process when a feature ends up being twice as hard as you estimated? The answer tells you whether they communicate or hide.
- Who specifically will write the code? Are they full-time or contractors? Agencies often switch the answer between sales and delivery.
- Can I see code from a project you're proud of and code from a project that didn't go well? The second answer is more interesting than the first.
- How do you handle scope changes mid-project? Listen for "we adjust the plan together," not "we'll quote any change."
- What happens to the code, the design files, and the deployment environment from day one? The answer should be "you own them." If it isn't, walk.
- What's the smallest project you've turned down recently and why? Good builders turn down work that doesn't fit. People who say "we'd take anything" usually deliver accordingly.
- How often will I see working software, not status decks? The right cadence is weekly or every two weeks. Monthly demos are a warning sign.
- If we decided to part ways three months in, what would the handoff look like? A good answer is detailed and unflinching. A bad answer is "let's not worry about that."
- What do you do when you disagree with me on a technical decision? You want pushback, not capitulation. Listen for examples.
Red flags that consistently predict bad outcomes
- They never push back during the sales process. You want a partner who'll tell you when an idea won't work.
- The portfolio is all logos and no detail. Logos prove someone signed a contract, not that the project shipped or worked.
- The estimate arrives within hours, with no follow-up questions. Real estimates require real understanding.
- The team that demos you isn't the team that'll work on your project.
- Source code, design files, or deployment ownership is "to be discussed later."
- References are family, friends, or the agency's own employees rather than independent clients.
Setting up the first 30 days for success
Whichever option you pick, the first month determines the next twelve. Three things to put in place from day one:
Define what done looks like for the first milestone. Not a deliverable date — a description of what working software will let your users do that they can't today. Refer back to this sentence every week.
See working software, not slides. Insist on a deployed environment from week two, even if it's just a login screen. If your engineer can't get a "hello world" version of your product running in front of you in two weeks, that's signal.
Write down decisions. Architecture decisions, scope tradeoffs, deferrals — keep a running log. When you part ways with one engineer and hire the next, this document is worth ten times the code in helping the new person get up to speed.
What to do next
If you're early and validating, hire a freelancer or a build partner with a small bounded engagement. Don't commit to an FTE until you have a stable problem.
If you have a defined first version to build, get quotes from two or three build partners or agencies. Insist on the ten questions above. Compare on five-year cost, not upfront cost.
If you already know exactly what you want, an implementer or a small freelance team will be fastest. Just be honest with yourself about whether you really know what you want — most founders think they do, and most don't.
If you want a starting point for the comparison conversation, our free software development RFP template covers the 13 sections vendors actually need to respond accurately. Or if you want a transparent cost estimate before you talk to anyone, our cost calculator takes about two minutes.