Previous article: How I Work Solo Without Losing Reliability
I work as an in-house systems engineer in a small company, and most of the time I build things either alone or in teams of no more than three people. When I was younger, I spent more time in larger teams, so I know the advantages they have. Even so, I still prefer small teams. They move more quickly, they let decisions happen without ceremony, and they fit the way I think about software much better.
There is another side to that, of course. When you work this way and you are handling multiple responsibilities at once, the schedule can become absurd very quickly. That has been my situation over the last few weeks. Between my company work and helping with a small outside development effort I had been asked to support, I became busy enough that I even gave up going out for drinks, which is not an especially dramatic sacrifice in itself but is usually a reliable sign that my margin has disappeared. This was not the first time I had ended up in that state, and I have been in worse situations before, so I thought it was worth writing down how I think about it now.
I should be clear about the scope here. I am not talking about joining a large project as an individual engineer through a freelance arrangement. I mean the case where one developer signs directly with a client and takes responsibility for building something for them. I think demand for that kind of work will increase as AI lowers the practical barrier to small-scale system development. In that sense, I do think it will become a business opportunity. But it is only an opportunity if people are honest about the constraints. If they are not, it becomes a very easy way to create trouble for both sides.
The biggest difference between team development and this kind of solo contract work is simple: there is no labor redundancy. If someone in a team gets sick, has an accident, or becomes unavailable, the team may slow down, but it does not necessarily stop. In a solo contract, it may stop immediately. That means a promise like “I will definitely deliver no matter what” is not a serious promise. Illness, hospitalization, or an ordinary traffic accident can end the work. Unless there is some insurance product willing to absorb that kind of liability, the risk cannot be priced away cleanly. It is simply there. You can reduce it, but you cannot eliminate it.
Because of that, I have always been uncomfortable with the casual way freelancing is sometimes recommended on social media. The advice is often presented as if the only real question is whether you have enough skill to build the software. That is not the real question. The harder question is whether the contract structure makes sense when the work depends on one person remaining continuously available. In practice, it often does not. Working inside a client’s company in a supposedly agile way is not a simple answer either. Usually that just means being bought cheaply and treated as extra hands. At least in an initial engagement, there are not many business owners who want to pay one outside individual more than they pay the employees who already support their business. And regardless of how good the engineer is, an individual and an organization do not have the same credibility.
That is why I almost never take this kind of work from someone I do not already know to some degree. In most cases, the relationship exists before the contract discussion starts. That may sound unglamorous, but it is the practical reality. If I were going to take development work from someone I had just met and had no established trust with, I do not think it would be responsible to treat it as ordinary solo contracting. In that situation, regardless of the legal form, I think you either need a team structure where the work can continue if one person drops out, or you need a payment model tied tightly to concrete deliverables rather than an open-ended promise of completion.
My own way of reducing this risk is to divide the work before implementation begins. I bill business requirements and basic design separately. By basic design, I mean things like table design and screen specifications. I also try, whenever possible, to close the account properly at that point: complete that phase, settle payment for that phase, and only then ask for explicit agreement on whether the next phase should begin. I do not think this is just a contractual detail. It is one of the few ways a solo developer can keep the commercial structure honest.
The important point is not only accounting. The important point is that those deliverables must remain useful even if I disappear from the project. If something happens to me after that stage, the client should still be able to take those materials to another vendor and continue from there. In my own case, I usually tell the client in advance which organization I would ask them to contact if I became unable to continue. That replacement will generally cost more than I do, because an organization carries more overhead than one person, but the money already paid to me does not become pure waste. Continuity matters more than dependency.
This is also why I prefer not to produce a full-project estimate too early. Large companies can sometimes do that because they have enough negotiating power, organizational backing, and contractual leverage to absorb later adjustments. An individual usually does not. If a solo developer gives a broad estimate too early, that number easily turns into a trap. It becomes a promise attached to information that did not yet exist. I think estimates should be delayed as much as possible, and if the design has clarified the work enough, it is even better to price each function or work unit separately rather than pretending the whole project was knowable from the beginning.
In other words, I want the estimate for the next phase to be made only when the current phase has already revealed what the next phase actually is. That is slower than the idealized sales story many people prefer, but I think it is much closer to reality. For a solo contractor, reality matters more than looking smooth at the start.
There is another pattern I sometimes use after the overall design has been made clear. Instead of estimating the whole implementation, I estimate only the smallest possible range that can be put into operation first. The unit has to be small, but not meaningless. It has to produce some real positive effect on the client’s work, otherwise splitting the work that way is just an accounting trick. If that condition is met, a small operational start is often the safest path. In that sense it is not far from the core idea people often associate with agile development. But for solo contract work, I think the commercial side matters just as much as the delivery style. A small start only reduces risk when each unit is individually agreed, individually settled, and allowed to stop there if the situation changes.
The same logic affects scope. I do not take responsibility alone for an entire company-wide system. I avoid that completely. If I am doing the design myself, I think the upper limit should be something that could be finished in about one month of full-time work at the requirements and basic design level. Beyond that, even if it looks possible on paper, the risk concentration is already too high. At that point I think the correct response is either to build a small team or to introduce a development company instead of pretending that one person can responsibly carry the whole thing.
This becomes even stricter when the work is effectively a side job. Many people who do system development already know what that feels like: sometimes you take on extra work for additional income, and then your main job becomes busy enough that there is no time left for the side work at all. In side contracts, I do not think it is realistic to promise deadlines on anything large or urgent. So the only things that make sense are small systems with low urgency, the kind of request that can honestly be described as “we want this, but we do not need it immediately.” I have had cases where I slowly extended a small system over more than a year, working on it in spare hours. Strangely enough, that is not always bad. When a project develops over a long period, there are more casual conversations with the client along the way, and those conversations often reveal better ideas or overlooked needs. In a normal business efficiency discussion that sounds wasteful. In reality, it can produce a system that fits the actual work better.
There are many other techniques that matter in small-team development. Design style matters. Documentation style matters. The way you write specifications matters. I have written about some of that elsewhere, and there is more I could write. But before any of that, the first thing that has to be considered is risk management. Not as a legal formality, and not as pessimism, but as the basic condition for taking the work responsibly. If you ignore that part, the project may still succeed, but only by luck. If you take it seriously, you are not only protecting yourself. You are also protecting the client from building their system on a promise that was never structurally safe to make in the first place.
