Freelancer, studio, or company: who should you choose for software development?

Freelance, studio, or IT company: a deep comparison of options for developing your software product.

Freelancer, studio, or company: who should you choose for software development?
INGELLO / BUSINESS1830

I get asked this question regularly, and usually with a catch. The person has already been burned somewhere and wants me to confirm their new theory. "Freelancers always disappear, right?" or "Companies just inflate estimates, better to hire one smart guy." I always answer the same way: the question is framed wrong. You cannot choose a contractor without understanding what exactly You are building. It is like asking whether to hire a carpenter or a construction company without saying whether You mean a birdhouse or a shopping mall. I have been building systems for business for many years. I have worked as a freelancer, in a studio, and now in a company, so I can honestly describe all three options, including their dark sides. Yes, ours too.

First the size of the task, then the contractor

Any software project can be roughly placed on a scale of complexity. At one end there is a simple business card site, a landing page, a small tweak to an existing store, a script for exporting data. At the other end there is a system with roles, access rights, integrations with the bank, warehouse and accounting, reporting for the owner and dozens of employees who work in it every day. Everything else sits in between. And every point on that scale has its natural contractor, much like every river has its type of bridge. A plank is enough for a stream. The Dnipro needs an engineering project, geologists, load calculations and a crew that will maintain the bridge for the next thirty years.

The main mistake I see is trying to throw a plank across the Dnipro because "a plank is cheaper". The second, rarer but just as painful: building a cable-stayed bridge over a stream because "a serious company should do things seriously".

The freelancer: freedom and solitude

A good freelancer has huge advantages. He is cheaper, because he has no office, no managers and no accounting department. He starts faster, because he does not have to negotiate resources inside a team. You can talk to him directly, without intermediaries. On small, clearly defined tasks a freelancer is often the best choice, and I worked that way myself for many years.

But a freelancer has a property clients remember too late: he is alone. He gets sick alone, goes on vacation alone, burns out alone, gets a more interesting offer alone. When he disappears, and sooner or later everyone does, for all sorts of reasons, all the knowledge about the system disappears with him. There is usually no documentation, because there is nobody to write it and no reason to, it is all in his head anyway. The architecture lives in his head too, and it is whatever one person managed to come up with between deadlines. The new contractor opens the code and says the famous line: "It is easier to rewrite this." And that is not always laziness. Sometimes it is the truth.

The studio: beautiful and fast, while the system is simple

A studio is a few people, usually strong in design and front-end. They have a portfolio of beautiful websites, a well-oiled process for typical projects, and a manager who answers emails. For a company website, a promo page or an online store on a ready-made platform, a studio is often optimal: cheaper than a company, more reliable than a freelancer, and the result usually looks great.

Problems start when a studio is asked to build a system. A studio is used to thinking in screens, while a system lives on data, processes and integrations. I have seen many projects where the interface was gorgeous and underneath lay a database designed on a napkin, with no thought that in a year there would be a hundred times more orders and the accountants would want a report the data schema simply cannot produce. It is like a house with a luxurious facade and a foundation meant for a shed. As long as nobody lives in it, everything is fine.

The company: processes, architecture and accountability

An IT company is more expensive, and that should be admitted honestly right away. You pay not only for programmers, but for an architect, an analyst, a tester, a manager, for processes that look unnecessary until there is a fire. In return You get what the first two cannot give: a system that does not depend on one person. Architectural control, where decisions are made with growth in mind rather than between two deadlines. Documentation, tests, code review. Legal accountability and a contract under which You can demand something. The ability to scale the team up if the project grows, and down if You need to save money.

Companies have their own anti-pattern too, and I will not pretend it does not exist. A big company can drown a small project in bureaucracy: three weeks for an estimate, five calls to agree on a button colour, reports for the sake of reports. If You need a landing page and someone is selling You "a two-month discovery phase", You have come to the wrong place. A good company can honestly say: "You do not need us, a freelancer will do, here is what to look for when choosing one."

How to choose in practice

I usually offer the client three questions. First: what happens if the contractor disappears tomorrow? If the answer is "well, we will find someone else and he will figure it out in a week", it is a job for a freelancer or a studio. If the answer is "the sales department will stop", You need a company, or at least a team with documentation and an architect. Second: how many years will this system live? A website for a promotion lives six months. An accounting system lives ten years and outlasts three directors. Third: how many external systems will it touch? Every integration with a bank, a warehouse, a CRM or a government registry multiplies complexity, and here a lone developer almost always loses.

And one more practical tip that has saved my clients a lot of money. Whichever contractor You choose, insist that the code lives in Your repository, the access credentials are Yours, and the architecture is described on at least a few pages. That is insurance against any of the scenarios above. At Ingello we use Fractal for this: the system is described declaratively, and from that description any engineer understands how it is built, even if the original author has long since moved on to another project. But You can buy this insurance without us too. What matters is buying it before You need it. Good luck with Your choice, colleagues, and may Your bridge match Your river.