If Your Code Lives on One Laptop, You Don't Own It

What does it actually mean to own your code?

Most teams think about owning code the way they think about owning a file: it sits on our machine, so it is ours. That is possession, and possession is not ownership. Owning the work means three things in practice, and a single laptop gives you none of them reliably. Can you recover it if that machine is lost tomorrow morning? Can you change it without the low, constant fear that you will break something you cannot get back? Can you say, with confidence, who changed what and when? If the honest answer to any of those rests on one person or one device, you do not own that code yet. You are borrowing it, and the lender is chance.

Source control - also called version control - is the system that closes that gap. It keeps a complete, recoverable history of every change, stores the authoritative copy somewhere central and backed up rather than on an individual's desk, and lets more than one person work on the same files without quietly overwriting each other. Git is the tool almost everyone uses for this now, and it is also the first and most basic of the practices behind what people mean when they say DevOps - the discipline of shipping software predictably. The mechanics matter less than what they buy you, which is continuity. The work outlives the laptop, the resignation, and the bad afternoon.

Does a five-person team really need source control?

The instinct to wait is reasonable, and worth taking seriously rather than waving away. We are small, the thinking goes, we will put proper process in when we are bigger - and you built lean for good reasons, because every hour spent on tooling is an hour not spent on the client. That logic genuinely holds for a lot of process. It does not hold here, for one stubborn reason: the risks source control protects against do not scale down with your headcount. A five-person firm has exactly the same single points of failure as a fifty-person one. It simply has fewer people to absorb the shock when one of them lands, and less slack to recover while a partner is on the phone explaining the delay.

There is also a part of the old calculation that has quietly changed. A decade ago, standing up version control was a small project in itself. Today a hosted repository is free or close to it for a team your size and takes an afternoon to set up. The trade-off that used to give people pause - is this worth the overhead - has mostly dissolved, because the overhead is largely gone. What remains is not a cost-benefit sum but a decision. Most teams that have not done it are not careless; they simply never hit the day that forced the issue. The point of making the case before that day is that it is far easier to hear now than it is at 9pm on the evening a drive fails.

What are you actually protecting against?

Abstract risk is easy to defer, so it helps to be concrete. Three things go wrong in real firms, and source control turns each of them from an incident into a non-event. The first is a person leaving. When someone resigns - and people do - their work and the reasoning behind it should stay with the firm, in a shared history anyone can read, not locked inside a folder structure only they could navigate. Source control is how the knowledge survives the departure instead of walking out with the badge.

The second is a machine failing. A laptop is taken from a car, a drive dies without warning, a drink finds a keyboard at the worst possible moment. If the code lives in version control, that day is an annoyance and a hardware claim. If it lives only on the machine, it is a phone call to a client you do not want to make - the kind of loss that rarely arrives as a tidy line item but is expensive all the same. The third is a change going wrong: someone overwrites a working version, a small fix breaks something three steps away, two people edit the same file and one set of edits silently disappears. Version control lets you see exactly what changed and return to the last good state in seconds, rather than rebuilding it from memory and hope.

There is a quieter fourth thing, and it tends to matter most to the people who run the business rather than write the code. Today, the question of who changed this, and why, is often an argument that ends in a shrug. With a full history behind you, it becomes a lookup. For a firm that bills clients for its work, being able to show what changed, when, and on whose authority is not bureaucracy for its own sake. It is how you stand behind what you delivered, how you answer a dispute without a scramble, and how you pass the kind of audit that decides whether a larger client will trust you with more.

Isn't a shared drive or cloud sync already good enough?

This is the most reasonable objection of all, and it deserves a real answer rather than a dismissal. Plenty of careful teams keep their code on a shared drive, OneDrive, or Dropbox precisely because they take the risk seriously and want it backed up somewhere other than one machine. That instinct is right. The trouble is that backup and version control are two different jobs, and treating one as if it were the other is exactly where teams get caught out at the worst time.

File sync keeps the latest copy of a file in several places. What it does not do is understand what a change is. When two people edit the same file at once, a sync tool cannot merge their intentions - it picks a winner, or leaves you a 'conflicted copy' to untangle by hand. It preserves the present, not a reliable, navigable past, so going back to how something looked three weeks ago is guesswork rather than a command. And it has no concept of review: no way to look at a proposed change and approve it before it becomes the official version everyone builds on. The distinction is simple to hold once you see it. A shared drive holds your files. Version control holds the story of the work - every version recoverable, concurrent edits merged on purpose, and a change reviewable before it lands. Only one of those lets you sleep.

So where should your code actually live?

Once you accept that code should not live on a single laptop, the interesting question is no longer whether to use source control but where to put it. The modern answer is a hosted Git service: a central, backed-up home for your repositories that each person on the team connects to from their own machine, working on their own copy and sending changes back to the shared one. For a firm already in the Microsoft world, the two usual homes are Azure Repos, which is part of Azure DevOps, and GitHub. Both are mature, both are inexpensive at small scale, and both solve the problem in this piece completely.

Choosing between them is a genuine decision with trade-offs, and it depends less on the code itself than on how the rest of your delivery is run - where your work is already tracked, how your team is licensed, where your other tools live. That is a decision this series takes up on its own terms, because it deserves more than a paragraph. But it is a far smaller problem than the one it replaces. The move that actually matters is the first one: getting the code off the individual machine and into a system designed to hold it. Picking between two good options is easy. Living without having chosen at all is what costs you.

What does the first move actually look like?

It is smaller than the language around it suggests. You do not need a transformation programme, a new hire, or a quiet weekend of dread. You choose a hosted home, create a repository, and get everyone putting their work into it daily rather than saving it up for the end of a milestone. The more advanced habits - branch rules, formal reviews, automated checks before anything merges - can come later, layered on once the basic habit exists. Those are how you get more out of source control over time. They are not the price of entry, and treating them as one is how the whole thing gets postponed indefinitely.

The first day is mostly a decision rather than a setup. Decide that the firm's code is a business asset, not a scatter of files on people's desks - something to be recovered, changed safely, and accounted for like anything else you would not leave in a single unlocked drawer. Almost everything else in a delivery toolchain assumes that foundation is already there; this is the move the rest stands on. It is the cheapest and least dramatic thing on the list, and it quietly removes an entire category of the problems that ruin otherwise good weeks. If your code lives on one laptop today, the next step is not to worry about it. It is to decide where it should live instead, and spend the afternoon.