In this article (15 sections)
Every company that needs software for the first time arrives at the same fork: hire a person, hire a company, or build a team of my own. All three work. All three also fail, and they fail in different, predictable ways.
This piece isn't going to tell you the answer is "an agency" because we happen to be one. It's going to tell you the conditions under which each option is the right one, what each actually costs —including what doesn't show up on the invoice— and the signs that you picked wrong.
The freelancer
When it's the right call
A senior freelancer is hard to beat when the work is narrow, well defined and single-discipline. A landing page, one specific integration, a new module on top of a system that already exists and is documented, a redesign. Work where one head is enough and the scope fits in an email.
It's also the sensible option when the budget is genuinely small. A USD 2,000 project can't pay for a company's overhead, and forcing it ends with a company assigning you its most junior person.
What it actually costs
A senior freelancer in Latin America runs between USD 25 and 45 an hour, cheaper than a company for an obvious reason: they aren't paying for overhead. Rates where you are will look different. But there are costs that aren't in the rate:
- You're the project manager. Defining, prioritizing, reviewing and coordinating is on you. If your hour is worth something, add it in.
- There's no redundancy. If they get sick, move, take a full-time job or simply stop answering, the project stops. And the knowledge of the system leaves with them.
- One person rarely covers every discipline. A great backend developer doesn't necessarily do good frontend, or think about the user experience, or know infrastructure.
How it fails
The typical freelancer failure isn't bad work. It's that the project outgrows them and nobody notices in time. It starts well, the scope grows, the person can't keep up, replies get further apart, and four months in you have a half-built system nobody else understands. When that happens, starting over is usually cheaper than picking it up.
The in-house team
When it's the right call
Your own team is justified when software is the business, or a core competitive advantage. If your product is a platform, if the system is what sets you apart from competitors, or if you'll be changing it constantly for years, having the knowledge inside isn't a luxury: it's a requirement.
The rule of thumb: if you can project two years of continuous work for at least two or three people, start evaluating it seriously. With less than that, an in-house team spends more time waiting for work than doing it.
What it actually costs
This is where the math usually goes wrong. A developer's cost is not their salary:
- Salary plus everything on top of it. Payroll taxes, benefits, paid time off, insurance. Whatever the rules are where you hire, the loaded cost is meaningfully above the base number.
- Equipment and licenses. Laptop, tools, services.
- The cost of recruiting. Between the search, the interviews and the time of whoever interviews, filling a technical role takes one to three months.
- The ramp-up. A new developer isn't at full output until month two or three.
- Turnover. This industry turns over. Every exit takes knowledge with it and restarts the cycle.
- Someone has to lead them. A team of three with no technical leadership produces three different solutions to the same problem.
A minimum viable team —two developers with some leadership— is a commitment of several thousand dollars a month that holds whether or not you have work for them that month.
How it fails
Two classic ways. The first: hiring before the work is steady, and ending up with expensive people doing tasks that don't justify their cost. The second, quieter one: going insular. A small in-house team with no exposure to other projects tends to solve everything the same way, the way it already knows, even if that stopped being the best way three years ago.
The agency
When it's the right call
A development company makes sense when you need several disciplines at once, for a limited time, with a date that matters. A full business system needs someone thinking about the data model, someone building the screens, someone handling deployment and someone coordinating. Hiring those four capabilities separately is a management project in itself.
It's also the right option when software is important but isn't your business. A logistics company needs an excellent fleet system; it doesn't need to become a software company to have one.
What it actually costs
The hourly rate sits between USD 30 and 55 and projects are usually quoted at a fixed price. It's more per hour than a freelancer because it includes the coordination, the redundancy and the disciplines the freelancer doesn't cover. What it saves you:
- You don't do the management.
- There's cover. If someone leaves, the project continues.
- At a fixed price, the risk of the estimate isn't yours. If the team estimated badly, they absorb the difference.
How it fails
The typical failure is distance. A company with many clients can assign you whichever team is free instead of the right one, quote you with seniors and staff you with juniors, or hand you something that meets the contract to the letter and doesn't solve your problem. You can catch this before signing: ask who specifically will work on your project and how often you'll see something working.
How to decide
Four questions, in this order.
1. Is software your business or a tool of your business?
If it's the business, the knowledge has to end up inside. In-house team, eventually. If it's a tool, outsourcing it is a healthy decision.
2. How much work is there, honestly, for the next 24 months?
Continuous work for three or more people: in-house team. One big project and then maintenance: agency. Something one-off: freelancer.
3. How many disciplines does the project need?
One: freelancer. Three or more: a company or a team.
4. What happens if the key person disappears tomorrow?
If the answer scares you, you need a structure with redundancy.
The path that works for most small companies
In practice, the most common and healthiest route is staged:
- Start with a company to build the first version at a closed scope and price. You get something working without committing to a fixed structure.
- Add a freelancer you trust for small adjustments and day-to-day work, while the system matures.
- Only once software becomes central do you start moving the knowledge inside. And by then you're doing it with a system that already exists, already works and is already documented, instead of starting from zero.
What matters about that order is that each step is funded by the result of the one before it. Hiring an in-house team to build the first version is the most expensive way to find out that the system you needed wasn't the one you asked for.
One condition that holds for all three
Whichever option you pick, ask for the same thing: that the code and the access are yours. Repository in your name, infrastructure credentials in your hands, documentation on how the system gets stood up. It isn't distrust, it's continuity. The day you want to change vendors —and that day comes in every project that lasts— the difference between a two-week transition and starting over is exactly there.