How to hire a software developer: freelancer, agency or in-house
Hiring the right builder is the decision that matters most when you need software and aren't technical yourself. The four routes compared honestly, where to find each, and how to assess them without reading code.
If you need software built and you're not technical yourself, hiring the right developer is the decision that matters most. There are four main routes: a freelancer, an agency or studio, an in-house hire, or doing it yourself with no-code or AI tools. Each fits a different situation. This guide compares them honestly, explains where to find each, and gives you the questions and checks that separate good builders from risky ones, even if you can't read code.
What the research says
- Good developers are in demand. The US Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow 10% from 2025 to 2035, much faster than the 3% average for all occupations. (US Bureau of Labor Statistics) Expect competition for good people, and be wary of anyone who seems too available and too cheap.
- Most projects that miss their goals fail on requirements, not code. PMI's 2014 Pulse of the Profession in-depth report found that inaccurate requirements management is the primary cause almost half the time (47%) when projects don't meet their goals. (PMI) The developer who asks the best questions about your business is often a safer bet than the one with the most impressive technical CV.
- The downside risk is large. In Flyvbjerg and Budzier's study of 1,471 IT projects, one in six had an average cost overrun of 200%. (Flyvbjerg and Budzier, Harvard Business Review / arXiv) Choosing a builder is mostly about managing that risk.
Your four options
1. A freelancer
How it works: you hire an individual developer, often found through platforms like Upwork, Toptal or Fiverr, or through a referral, to build the whole thing or part of it.
Good for: well-defined, smaller pieces of work, or adding a skill to an existing team.
Watch out for: one person is a single point of failure. If they're ill, busy or move on, the project stops. You'll be managing the project yourself, including design, testing and deciding what to build next. Make sure the code lives in an account you own.
2. An agency or studio
How it works: a company with a team, usually covering scoping, design, development and testing, builds the software and often supports it afterwards. Review sites such as Clutch publish client reviews of agencies.
Good for: businesses that want a complete result without managing developers, and projects that need several skills.
Watch out for: large agencies can put junior staff on small clients. Some keep ownership of the code or tie you into their platform. Check who will actually do the work, and who owns what.
3. An in-house developer
How it works: you employ a developer, or a small team, as staff.
Good for: businesses where software is core and ongoing, with enough work to keep someone fully busy for years.
Watch out for: hiring is slow and competitive. A single developer has no one to review their work, and if you can't assess technical skill, a bad hire is hard to spot. It often works best once something is already built and needs a long-term owner.
4. Do it yourself: no-code and AI app builders
How it works: tools like Airtable, Glide, Softr and AI app builders let a non-developer assemble simple tools, and they're getting more capable quickly.
Good for: prototypes, simple internal tools and testing an idea before you spend real money.
Watch out for: you become the maintainer. Anything involving money, personal data or connections to your core systems needs proper testing and security, and many platforms don't let you take your app with you if you leave. See AI coding agents: what they change when you commission software.
How to choose
- A small, clearly defined task, and you're happy to manage it: a freelancer.
- A complete business tool, with design, connections to your systems and support afterwards: an agency or studio.
- Software is your product, and there's years of full-time work: an in-house hire, possibly after a studio builds the first version.
- You want to test an idea cheaply first: no-code or an AI builder, then bring in help for the real version.
Where to find good builders
- Referrals from other business owners in your industry. This is still the best source.
- Platforms such as Upwork and Toptal for freelancers, with reviews and some vetting.
- Review sites such as Clutch for agencies.
- Case studies on builders' own sites. Look for work similar to yours, described honestly.
- Local business networks and chambers of commerce.
How to assess a builder when you can't read code
- Do they ask about your business before they talk about technology? They should want to understand how the work happens today.
- Can they explain things plainly? If you don't understand them now, you won't later.
- Do they push back? A good builder will suggest a smaller first version, or tell you when you don't need custom software at all.
- Can you see similar work, and speak to a past client?
- Is the proposal specific? Look for a written scope, what's excluded, milestones and how changes are handled.
- How do they test? Ask what happens before you see something, and how you'll check it yourself.
- How do they use AI tools? Most developers now do. You want to hear that a person reviews and tests everything.
- What happens after launch? Fixes, hosting, support and how they're charged.
Contract essentials
Whoever you hire, put these in writing:
- You own the code and data once paid for, and the code lives in an account you control, or is handed over regularly.
- A clear scope, with exclusions and a change process.
- Milestones tied to working software, not just dates.
- Confidentiality and data protection terms.
- What happens after launch, and if you part ways.
Our software development contract checklist goes through each one.
Red flags
- A price before they understand what you need.
- Reluctance to put the scope in writing.
- "We keep the code" or "it only runs on our platform", without a clear reason and exit plan.
- No questions about your existing systems or data.
- No mention of testing.
- Pressure to sign quickly.
- Every answer is "yes".
How we work at Lephlo
We're a small studio that builds internal tools, customer portals and integrations for growing businesses, built around how you work and connected to the tools you already pay for. We start with a free consultation about how the work happens today, and we'll tell you if you don't need us. For a clear project we send a fixed price for the agreed scope. For a less certain one, we suggest a short paid Scoping Sprint first.
You own the code, fixes are free during the fix period after launch, and we stay on hand as it grows. We build with AI coding agents, and every change is reviewed and tested by a person before it reaches you.
To see the kind of work we do, look at our case studies. To size a first version, try the Build Scope Planner, or book a free consultation.
Frequently asked questions
Should I hire a freelancer or an agency? A freelancer suits small, well-defined tasks you're happy to manage. An agency or studio suits complete business tools that need design, testing, connections to your systems and support afterwards.
How do I know if a developer is any good if I'm not technical? Judge how they understand your business, how clearly they explain things, how specific their proposal is, how they test, and what past clients say. A second opinion on the proposal from someone technical can help too.
Do I need a technical co-founder? If software is your core product and you're building a company around it, possibly. If you need software to run an existing business better, usually not. A good studio can build it and support it.
Who should own the code? You should, once it's paid for, with the code kept in an account you control.
Sources
- US Bureau of Labor Statistics, Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers
- Project Management Institute, Pulse of the Profession In-Depth Report: Requirements Management (2014)
- Bent Flyvbjerg and Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review (2011)