How to Choose a Developer or Agency for Your Business

Hiring a developer or agency is one of the highest-stakes decisions a business owner makes, and most people go into it with almost no framework for evaluation. You would not hire an accountant without checking their credentials, or a contractor without seeing their previous work. Yet I regularly meet business owners who hired the first developer they found on Upwork, paid 50% upfront with no contract, and ended up with a half-finished product they cannot use or maintain.

I am going to give you the insider perspective here — the things developers know about the industry that clients usually learn the hard way.

Freelancer vs. Agency vs. In-House: The Trade-Offs

Before you start evaluating individual candidates, you need to decide what type of engagement makes sense for your project.

Freelance Developers

Best for: Small to medium projects with well-defined scope, ongoing maintenance of existing products, adding specific features to an existing codebase.

Typical cost: $50-$200/hour depending on experience and location, or $3,000-$30,000 per project.

Advantages: Lower overhead means lower costs. You work directly with the person building your product — no project managers, account executives, or communication layers in between. Good freelancers are highly responsive because their reputation depends on each project.

Disadvantages: Single point of failure. If your freelancer gets sick, goes on vacation, or takes on too many projects, your timeline slips. Limited capacity for large projects. No built-in design, QA, or DevOps capabilities — you may need to hire multiple freelancers and coordinate them yourself.

The reality: The quality range among freelancers is enormous. The best freelancers are better than most agency teams and charge accordingly. The worst freelancers will take your money and deliver unusable code. Your job is to tell them apart (more on that below).

Agencies

Best for: Medium to large projects that require multiple disciplines (design, frontend, backend, mobile), businesses that need a team without hiring full-time employees, projects where you want a single point of accountability.

Typical cost: $100-$300/hour for the team, or $20,000-$200,000+ per project.

Advantages: You get a team — designer, developers, project manager, QA — without hiring any of them. Good agencies have established processes, quality standards, and accountability structures. They can handle larger projects and scale the team up or down as needed.

Disadvantages: Higher cost because you are paying for overhead (office space, management, sales, marketing). Communication often goes through a project manager, which adds a layer between you and the people doing the work. Some agencies prioritize revenue over quality and will recommend more work than you need.

The reality: Agency quality varies as much as freelancer quality, just at a higher price point. The best agencies deliver consistently excellent work with professional project management. The worst charge agency rates and then outsource the actual development to cheap subcontractors overseas without telling you. Ask who will actually be writing the code.

In-House Developers

Best for: Businesses where technology is the core product, companies with ongoing development needs that would cost more to outsource, organizations that need full-time dedicated attention.

Typical cost: $80,000-$180,000/year salary plus benefits, office space, equipment, and management overhead. True cost is usually 1.3-1.5x the salary.

Advantages: Full-time dedication to your project. Deep understanding of your business over time. No billing surprises. You own the relationship and the knowledge.

Disadvantages: Hiring takes 2-4 months. You need to know enough about technology to evaluate candidates and manage them effectively (or hire someone who does). You are responsible for their career development, keeping them engaged, and replacing them if they leave. A single developer cannot cover every technology — you may still need contractors for specialized work.

The reality: In-house only makes sense when your ongoing development needs are large enough to keep a developer fully utilized. If you need 20 hours of development work per month, hiring a full-time developer at $150,000/year means you are paying $625/hour for their utilized time. A freelancer at $150/hour would cost a fraction of that.

My Recommendation

For most small and medium businesses building their first digital product, start with a freelancer or small agency for the initial build. Transition to in-house only when your product is generating enough revenue to justify full-time salaries and your development needs are continuous (not project-based).

If your project is complex enough to need a team (mobile app + backend + web dashboard, for example), a small agency (5-15 people) usually provides the best balance of quality, coordination, and cost. Large agencies (50+ people) are best for enterprise-scale projects where you need deep benches in specialized areas.

How to Evaluate a Portfolio

A portfolio is the single most important evaluation tool you have, but most people look at it wrong. They see pretty screenshots and assume quality. Here is what to actually look for.

Visit the Live Sites

Do not just look at screenshots in a portfolio deck. Ask for URLs and actually visit the sites or download the apps. A surprising number of "portfolio pieces" are no longer online, which means either the client went out of business (fine, it happens), the project was never finished (red flag), or the quality deteriorated after launch because no one maintained it (questions about long-term quality).

When you visit a live site, pay attention to:

• Speed. Does it load quickly on your phone? Try it on a cellular connection, not your office Wi-Fi. If a developer's own portfolio piece is slow, what does that tell you about the standards they apply to client work?
• Mobile experience. Pull it up on your phone. Is it usable? Can you find information without struggling? Are buttons easy to tap?
• Polish. Do images load correctly? Are there broken links? Is the text well-formatted? These details reveal the care level the developer brings to a project.

Ask About Their Role

When a developer or agency shows you a project, ask: "What specifically did you build?" Many portfolios include projects where the developer built one small piece of a larger system, or where they customized a template rather than building from scratch. Neither of those is inherently bad, but you need to understand the scope of their contribution to evaluate whether their skills match your needs.

Look for Projects Similar to Yours

A developer who has built five e-commerce stores will build a better sixth one than a developer who has never built one before. Domain experience matters — not because the technology is different, but because experienced developers have already made and learned from the mistakes that inexperienced developers will make on your project.

This does not mean you should only hire someone who has built an exact replica of what you want. But if your project is a restaurant ordering system, a developer who has built food-tech products will understand the edge cases (menu customization, delivery zones, kitchen workflows, payment splitting) that a developer who has only built marketing websites will not.

Check the Dates

Ask when the portfolio projects were completed. Web development changes fast. A portfolio full of projects from 2019 that have not been updated since tells you something about the developer's current activity level and the long-term quality of their work. Recent projects (within the last 12-18 months) are more relevant to evaluating current skill levels.

Red Flags That Should Make You Walk Away

In my years of working in this industry, I have seen every variation of project gone wrong. These are the warning signs that, from my experience, consistently predict failure.

The Price Is Suspiciously Low

If one developer quotes $15,000, another quotes $12,000, and a third quotes $2,000 for the same project, the $2,000 developer is not more efficient — they are either cutting corners you cannot see yet, planning to hit you with change orders later, or simply do not understand the scope of what you are asking for.

The most expensive option is not always the best, but the cheapest option is almost never the best. Quality development takes time, and time costs money. When someone significantly undercuts the market, there is always a reason.

No Process or Methodology

A good developer or agency should be able to walk you through their process before you sign anything. What does discovery look like? How will they gather requirements? When will you see designs? How will you provide feedback? How often will you get progress updates? What happens when something needs to change?

If the answer is "just tell me what you want and I will build it," you are heading toward a project where expectations are misaligned, timelines are unclear, and conflicts are inevitable. Process is not bureaucracy — it is how experienced professionals manage complexity and deliver predictable results.

They Do Not Mention Testing

Ask how they test their work. If the answer is "I test it myself before I hand it over" with no mention of systematic testing, quality assurance processes, or testing on multiple devices and browsers, your product will ship with bugs. Every product has bugs, but the difference between a professional developer and an amateur is whether those bugs are caught before or after your customers find them.

Good developers write automated tests that verify their code works correctly. They test on multiple browsers and devices. They have someone other than the person who wrote the code verify it works. These practices cost time, which is part of why quality development costs more than amateur development.

Resistance to Contracts or Documentation

If a developer pushes back on having a written contract, that is a major red flag. Professionals welcome contracts because contracts protect both parties. A contract should cover: scope of work, timeline, payment schedule, intellectual property ownership, what happens if scope changes, and how either party can end the engagement.

Similarly, if they resist documenting technical decisions or creating any documentation about how your system works, you are building a dependency on that specific person. When they are unavailable (or you want to switch to a different developer), the lack of documentation means the next person has to reverse-engineer everything from scratch.

They Promise Unrealistic Timelines

"I can build your entire platform in two weeks." No, they cannot. Not well, anyway. Custom software development takes time because the hardest parts — understanding requirements, handling edge cases, testing, iterating based on feedback — cannot be compressed.

A developer who promises an aggressive timeline either plans to cut corners, does not understand the scope, or will come back in week two with a list of "complications" that extend the timeline (and the budget) significantly.

Contract Essentials: What Should Be in the Agreement

Whether you are hiring a freelancer or an agency, the written agreement should cover these areas.

Scope of Work

The scope should describe what will be built in enough detail that both parties can look at the finished product and agree whether it matches what was promised. Not so detailed that every pixel is specified (that level of rigidity makes projects fail), but detailed enough that "build me a website" does not become a disagreement about whether a booking system was included.

I recommend a scope document that describes features in terms of user outcomes: "A customer can browse the menu, add items to a cart, and place an order with credit card payment" is clearer than "e-commerce functionality."

Payment Structure

Never pay 100% upfront. A milestone-based payment structure aligns incentives and protects both parties.

A common structure that works well:

• 20-30% upfront to start the project (covers the developer's risk of beginning work)
• 30-40% at midpoint (typically after design approval or a functional prototype)
• 30-40% on completion (after final review and deployment)

For larger projects, you might have 4-5 milestones. The key is that each payment is tied to a deliverable you can evaluate. If the project stalls, you have only paid for the work completed so far.

Hourly vs. fixed price: Fixed-price contracts work well when the scope is clearly defined. Hourly contracts work better for projects where the scope will evolve or where you want flexibility to adjust priorities. Many experienced developers prefer hourly billing because it is more honest — fixed-price contracts often build in risk premiums that inflate the total cost.

Intellectual Property Ownership

This is the clause that most non-technical founders overlook and then regret. You should own the code that is written for your project. This should be explicit in the contract.

There are nuances. Most developers use open-source libraries, frameworks, and sometimes their own pre-built components in your project. You do not own those — they are licensed under their own terms. What you should own is the custom code written specifically for your project and the design assets created for you.

Without a clear IP clause, the developer technically owns the code and is licensing it to you. This creates dependency: if the relationship ends badly, they could argue that you do not have the right to modify or maintain the code.

NDA Considerations

If your project involves proprietary business logic, customer data, or a genuinely novel idea, a Non-Disclosure Agreement is reasonable. Most professional developers will sign a standard NDA without objection.

However, understand what an NDA does and does not do. It protects confidential information — not ideas. If your business concept is "Uber for dog walking," an NDA does not prevent someone from building a competing product. It prevents them from sharing the specific business details, customer data, and proprietary processes you disclosed during the engagement.

Keep NDAs reasonable in scope and duration. A 2-year NDA covering information shared during the project is standard. A 10-year NDA that prevents the developer from working in your entire industry is unreasonable and a good developer will (rightly) push back.

Technical Evaluation for Non-Technical Founders

You do not need to understand code to evaluate a technical partner. Here is a checklist you can use.

Ask About Their Technology Choices

A good developer will explain their technology recommendations in terms you can understand and justify them based on your project's needs — not their personal preferences. Ask: "Why are you recommending this technology for my project?" The answer should reference your specific requirements, timeline, and budget.

Be wary of developers who recommend the newest, most cutting-edge technology for a straightforward business website. Proven, mature technologies are almost always the better choice for business applications. New tools are exciting for developers but risky for your project.

Ask About Hosting and Deployment

Where will your website or app live? Who manages the servers? What happens if the site goes down at 2 AM? How are updates deployed?

You should understand the hosting arrangement enough to know: who is responsible for keeping it running, what the monthly cost is, and whether you can move to a different provider if needed. If the developer hosts everything on their personal server and you have no access, you are locked in to that relationship — and locked out of your own product.

Ask About Security

For any project that handles customer data or payments, ask how they handle security. The answer does not need to be deeply technical, but it should cover: how customer data is stored and protected, how payments are processed (they should use established payment processors like Stripe, not handle card numbers directly), whether the site uses HTTPS, and how access credentials are managed.

If they dismiss security questions as unimportant for your project, that is a red flag. Security is important for every project that has users.

Ask for References

This is the most underused evaluation tool. Ask for 2-3 references from past clients — preferably clients with projects similar in size and type to yours. Then actually call them.

Questions to ask references:

• Did the project finish on time and on budget?
• How was communication during the project?
• Were there any surprises or unexpected costs?
• Would you hire them again?
• How do they handle problems or disagreements?

The answers will tell you more than any portfolio review or sales call.

Managing the Relationship for Project Success

Hiring the right developer is half the battle. Managing the engagement effectively is the other half.

Set Communication Expectations Early

Before work begins, agree on:

• How often you will communicate (weekly updates at minimum)
• Through which channel (email, Slack, a project management tool)
• Response time expectations (24 hours for non-urgent questions, same-day for blockers)
• Regular check-ins (a weekly 30-minute video call to review progress)

Most project failures I have seen were not caused by bad development — they were caused by communication breakdowns. The developer built something different from what the client wanted because neither party verified alignment until it was too late.

Provide Clear, Written Feedback

When reviewing work-in-progress, write down your feedback. "I do not like the design" is unhelpful. "The header font feels too casual for our brand — can we use something more professional, similar to what we see on [specific example]?" gives the developer something actionable.

Create a shared document or use a project management tool where feedback is tracked and addressed. Verbal feedback in a call gets forgotten. Written feedback creates accountability and a record you can reference.

Manage Scope Changes Deliberately

Every project encounters scope changes. A new feature idea, a change in business requirements, or feedback from early users — these are normal and healthy. The problem arises when scope changes happen informally, without discussing their impact on timeline and budget.

When you want to add or change something, frame it as: "I would like to add X. How does that affect the timeline and cost?" This forces an explicit conversation about trade-offs. The developer might say it adds two weeks and $3,000, and you can decide whether that is worth it. Or they might suggest a simpler version of the feature that fits within the existing scope. The key is making scope changes deliberate, not accidental.

Define "Done" Before You Start

The single most common source of conflict in development projects is disagreement about when the project is finished. The developer thinks they have delivered everything agreed upon. The client expected more. Both are operating in good faith, but their expectations were never aligned.

Before work begins, create an acceptance criteria document that describes — in plain language — what the finished product will do and how you will verify it. "The checkout process works correctly" is vague. "A customer can add items to a cart, enter their shipping address, pay with a credit card, and receive an order confirmation email" is testable.

When the deliverable meets the acceptance criteria, the project is done. Additional changes beyond those criteria are new scope, with their own timeline and budget.

After the Project: What Comes Next

The handoff at the end of a project is as important as the kickoff at the beginning.

Get access to everything. Domain registrar login, hosting account, source code repository, all third-party service accounts (analytics, email service, payment processor). You should be able to operate independently if the developer relationship ends. If you do not have admin access to every service your product depends on, you are not in control.

Get documentation. At minimum, you need a document that explains: how to update content, where the code lives, how to deploy changes, what third-party services the product uses, and any ongoing maintenance tasks (like renewing SSL certificates or updating dependencies).

Discuss ongoing maintenance. Every digital product needs ongoing attention — security patches, dependency updates, bug fixes, minor improvements based on user feedback. Agree on a maintenance arrangement: retainer hours, response time for emergencies, and how maintenance requests will be prioritized.

Plan for knowledge transfer. If you ever switch developers (and over a long enough timeline, you probably will), the new developer needs to understand what was built and why. Good documentation, clean code, and a well-organized codebase make this transition smooth. Poor documentation and messy code make it painful and expensive.

The Investment Mindset

Hiring a developer is not a purchase — it is an investment. Like any investment, the return depends on making good decisions about where to allocate your resources and managing the process actively.

The cheapest developer is rarely the best value. The most expensive is not always the best either. The best value comes from finding a competent professional who understands your business goals, communicates clearly, and delivers reliably.

Take the evaluation process seriously. Check references. Read the contract carefully. Set clear expectations. Manage the relationship actively. The upfront effort you put into choosing and managing the right technical partner will pay dividends for years to come.

And if something feels off during the evaluation process — if the communication is hard, the answers are evasive, or the promises seem too good — trust that instinct. The best time to walk away from a bad development partner is before you have given them your money.