Can I build this company fully remote, or does cybersecurity need us in a room?

You can build the company remote, and this is not the variable that decides whether you succeed. We have watched remote companies do well and remote companies fail, and in-person companies do both, and nothing about the posture itself predicted which. What predicted it was whether the founder treated distance as something to be worked at, or as something already solved by choosing a policy. The security market makes the question harder here than in most software: your buyers cluster by city, your researchers meet in person twice a year, and the security review is a conversation rather than a form. And the highest-stakes conversations kept moving into a room anyway, so the founders who planned for that spent less than the founders who fought it.

Your company is an archipelago, and you are the bridge.

You are running a set of islands. Everyone is somewhere, each somewhere is its own place with its own weather, and the only thing joining them is you. That is what remote actually is, and it is a different job from the one you would have in an office rather than a lighter one.

Culture is the part founders assume will arrive on its own, and in a room it very nearly does — people absorb how the company behaves by watching each other work. At distance nothing is absorbed. Every norm you want has to be stated, demonstrated and repeated by you, because culture comes from the founder and reaches the company through the executive team, and at distance that transmission is the whole of it. Remote companies fail when culture is left to happen. Build it deliberately, the way you would build a product, and treat it as first-class work rather than something you get to after the roadmap.

That also means the travel is yours. Pick one airline and earn its top status. A founder who is present in each place often enough to be a real person there is doing connective work that no process replaces.

The decisive conversations happen in a room.

You will frame the question as one company-wide policy, remote or office. Across the remote-first companies we have backed, the interactions that actually changed outcomes were physical: an on-site working day going through a stuck pipeline account by account, an offsite that repaired a broken relationship between two departments, a director flying to the founder's city when the quarter went wrong. The real question is not the policy. It is which specific interactions you will always do in person, and budgeting travel for those rather than for presence.

Write the list.

You write the list once and budget for it. The buyer's first serious meeting and the start of the security review. The first two weeks of a senior hire. The quarter-end forecast review with the sales team in one room. The offsite in the quarter when two departments stop talking to each other. The board meeting after a miss. The incident. Everything else can be a call, and most of it should be.

Set the posture by role, not by policy.

You will treat remote work as an identity the company has to keep consistent to be credible with candidates. Deciding role by role was the practice that actually worked. Companies that hired remotely for years still wrote a co-located job description for their single most important role, and the reason they took real office space was rarely selling. It was delivery complexity, handoffs between departments, and onboarding. Write the job description for the role, and let the role decide the room.

Security sells and recruits in a city.

The market itself is not remote. Buyers cluster by city and refer each other inside it. The dinners with security leaders happen at a table. The researcher community meets in person twice a year, and the hire you want is in that hallway. A remote company in this market sells in person, and the travel line is a sales line, not an overhead.

There is no free lunch.

You get the best person for the role regardless of where they live, which matters more in security than in most markets, because the detection engineer you want is not in your city. What you pay for it is a set of problems that arrive in exchange, and every one lands on you: distance, communication that has to be written down to exist, culture that drifts a little each month nobody is watching, and a slowness you can feel and cannot point at.

None of that is fixed by tooling and all of it is managed by attention. Decide that you are buying the talent and paying the tax. A policy that promises neither side has not been thought about.

Offshore engineering charges two hidden taxes.

An offshore or lower-cost engineering team gets judged by cost per engineer, and the costs that matter are elsewhere. Distributed engineering is a real efficiency, and it charges two taxes. The first is a penalty on senior recruiting that lasts for years. The second is a loss of visibility into whether your engineering leadership is any good, because you cannot see the work happen. An outsourced team is a variable cost only until it holds knowledge you cannot replace, and by then it is a fixed cost with a foreign address. Judge the decision on those two taxes, not on the rate card.

What has worked.

You keep a small core in one city where the buyers are, put engineering wherever the best people are, budget travel for each interaction on the list above, and bring the whole company into one place more often than feels affordable. That line is the first one cut in a hard quarter and the most expensive one to have cut. That is not a policy. It is a list of rooms, and the company works because the rooms are booked.