Freelancer, agency or in-house?

I have a one-person studio and I have been on both sides of the agency table, so I am no neutral party here. Keep that in mind as you read this.

All three can produce good software. Which one suits you depends mostly on how much work there is, how long it lasts and how close the software sits to the core of your business.

What a freelancer does well

A freelancer is one self-employed person working for you under contract. You talk directly to the person building it, so a question or a change does not have to pass through anyone else. With no layers in between, that one person holds the whole project in their head. A freelancer also suits work with a beginning and an end, or a product still working out what it should be.

It does remain one pair of hands. No more can happen at once than one person can manage, and each freelancer has their own craft: one also does design, another does not. So ask what someone does themselves and what they do not, and what happens during a holiday. Good documentation covers part of that. What else to look for is in How to hire a freelancer.

What an agency does well

An agency brings different specialists together under one roof: designers, developers, testers and a project manager who keeps the overview. On a big project that needs all those people at once, you do not have to find them or coordinate them yourself. An agency can also bring in more people as the project grows, and if someone leaves or falls ill, a colleague can take over. The way of working is often already set, which is handy if your organisation has fixed procedures of its own or issues formal tenders.

At an agency there is often a project manager between you and the people building, and the person you meet in the first conversation is not always the person doing the work. That need not be a problem, but ask about it: who works on my project, and who do I talk to when something has to change? More people also means more coordination, and that time is part of the project.

What an in-house team does well

An in-house team consists of people you employ, who work only on your product. The knowledge stays in your business. They know your customers and are at the table when plans change. If software is the core of what you sell, and there are years of work ahead, that puts you in a strong position.

Building a team does ask something of you. You have to find and assess people, even if you are not technical yourself, and you become their employer. Someone has to lead the work and be able to make technical choices. One permanent developer is not yet a team either: if they leave, a lot of knowledge leaves with them. For a project that is finished after a while, a permanent hire fits less well, because there is no more work for that person afterwards.

Combinations

You do not have to choose for ever. A freelancer can build a first version, after which you hire an in-house team that carries on with the handover. An agency can do the design while your own developers build.

A freelancer can also work within an existing team. I do that at Eagl, where I work in their engineering team on a long-running freelance contract and pair closely with their own people. An arrangement like that gives a team extra experience without a permanent hire, and the in-house team keeps the knowledge.

Questions that help you choose

• Does the work have an end, or does it keep going? A defined project suits a freelancer or agency, and work that runs for years points more towards an in-house team.
• Is software what you sell, or does it support your business? An internal tool for your team asks for something different from the product your revenue comes from.
• How much has to happen at once? An app, a website and an integration at the same time need more hands than those three one after another.
• Which crafts are needed? Do you need separate design, testing or security, or can one person handle that?
• Who steers it on your side? Every option needs someone on your side who makes choices. With an in-house team that person also has to be able to judge the technical work, or you have to hire someone who can.
• What happens if someone drops out? With every option, ask about documentation and about who owns the code and the accounts. Who owns your code and data? is about that.

If you are unsure what exactly you need, it also helps to write a brief before you talk to anyone.

How I fit into this picture

Helsh-js is one person on purpose. The person on the call is the person writing the code, and the studio is small enough that I know the state of every project. I work across mobile, web and infrastructure, from analysis and design to front-end and back-end.

So with me too it remains one person, and that counts in the comparison above. How we would work together is on the process page. If you later want an in-house team, or want to carry on with someone else, I hand it over.