Thursday, eight in the evening. The website has stopped receiving prices from 1C (Russia's leading ERP and accounting platform): the storefront shows yesterday's, and the sales managers are fixing product pages by hand. The only person who knows how it all works is on day two of a vacation and isn't picking up the phone. Evenings like this are when the question comes up: keep a developer on staff, or hand the work to an outside team.
There is no single right answer. What there is, though, is a handful of things you can count and check, including the ones where your own employee beats a contractor.
An ordinary website is five different professions
Behind a corporate site with a catalog and data exchange with 1C there are at least five quite different specialties:
- the invisible part: calculating prices and discounts, processing orders, access rights;
- the visible part: pages, buttons, the cart, so that nothing falls apart on a phone or slows down where a product has a hundred photos;
- servers, the place where the site lives: updates, backups, watching that it is working at all;
- connections to other software: 1C, CRM, payment processing, marketplaces;
- pre-release testing, which people remember once a customer has already written to support.
This really is different work. Someone who writes careful discount logic usually can't work out why the server choked during the night. That's a matter of specialization, not skill level.
The size of the business adds requirements abruptly, not gradually. A catalog of three hundred items lives happily on any cheap hosting. But with a catalog of 400,000 products and traffic of several thousand people a day, it suddenly turns out that the daily product export for a marketplace brings the site down, and that updating prices every fifteen minutes means the old price sits on the storefront for a quarter of an hour while a customer puts the item in the cart at that price.
One strong generalist covers two or three of the five areas. The rest turn into "I'll look at it over the weekend," and then into accumulated problems that only that one person knows about.
What an insider sees better, and what worse
Start with the strength that gets forgotten in these debates. A staff developer knows the business from the inside: why this category of customers has special prices, why the order form has an odd field the commercial director asked for. An outsider will need all of that explained, and some of the detail will get lost along the way.
The weakness is that same closeness to the project. An in-house developer rarely comes to the director and says, "what I've been building for three years can't cope anymore, it needs to be redone." That isn't dishonesty. People just don't criticize their own work. Over time, questionable decisions become "that's how it ended up historically" and drop out of the discussion.
Hence the conclusion: have the system checked by someone who didn't build it. And not necessarily by whoever would do the work next, since an independent specialist has no need to sell you the next phase.
Take that same exchange with 1C. A setup where the site requests data from 1C directly lasts until the first long update in the accounting system: when it slows down, the site slows down, and in peak season that means lost orders. The cure is an intermediary. A separate program keeps a fresh copy of prices and stock levels and serves it to the site even when 1C is unavailable. The solution is well known. It's just rarely reached from the inside, where people fight the symptom and speed up yet another query.
Money: where the line falls
Count the full cost of an employee, not the salary: taxes, vacation, sick leave, equipment, a manager's time, months of searching, and the probation period. And compare it with the real volume of work, not with the feeling that "there seems to be a lot to do."
An hour of development from a contractor in Moscow starts at 3,000 rubles. From there the arithmetic is simple. If the project steadily needs 120–160 hours a month, meaning one person fully loaded, your own developer will almost certainly come out cheaper. If the volume swings, thirty hours in a quiet month and a hundred and fifty before a sale, you are paying a salary for idle time.
The third case is the most common one in mid-sized B2B: there is steadily not much work, but it's different every time. Today it's catalog edits, a month from now a move to a new server, by fall a marketplace connection. You can't hire five people for that, and one person will do half the tasks badly. This is where an outside team comes in: a support retainer with a fixed number of hours, or one-off jobs task by task.
Servers are a line of their own. Not everyone needs a system administrator on staff, but everyone needs backups and updates. Keeping a person on the payroll for an on-call duty that's needed once a quarter is expensive, and boring for that person too.
Access: the risk is on both sides
"We'd be handing our data to outsiders" is an understandable worry, but it's looking in the wrong direction. More often the trouble comes not from a contractor but from the fact that nobody manages access at all:
- the password to the live server sits in a three-year-old message thread;
- there is one shared password for everyone who has ever touched the project;
- an employee who left a year ago can still log in to the admin panel;
- nobody knows whether there are working backups, because no one has ever restored from them.
An outside contractor adds risks of its own, just different ones. Exactly one thing can be checked here: a written contract with a non-disclosure obligation, a separate login for each specialist instead of a shared one, and access switched off once the work is done. A verbal agreement with someone from a freelance marketplace has none of this, and that, not the size of the team, is what separates a company from a freelancer.
Knowledge about the project is lost the same way whether your own employee leaves or a contractor does. Only what's written down saves you: how the site is built, where everything is kept, what to do in an emergency. It's worth demanding this from anyone doing the work, staff included; we went through the procedure for taking over someone else's project in our article on how a site is taken on for support.
Who answers if the site goes down
By law, a staff employee answers under the employment contract, which is to say with almost nothing: an unpleasant conversation at most. A contracting company has money and reputation at stake, and a missed deadline costs it the next contract.
But a contract only works if it states what exactly the contractor does, by when, and how you accept the work. A line like "provision of website technical support services," with no list of work and no response time for an outage, protects no one. And reputation is an argument only for someone who can be found and checked: a mistake costs a company with a portfolio and reviews more than it costs an anonymous account on a freelance marketplace.
The second difference is continuity. In a team, a developer who's out sick doesn't stop the work: tasks and decisions are written down instead of living in one person's head.
What follows from this
The in-house-or-outside argument is more often settled by dividing the work than by choosing. Your own person is irreplaceable where business context and a quick reaction are needed: content, small edits, defining tasks, accepting work. What goes outside is whatever needs narrow expertise and comes up irregularly: servers, security, connections to other software, rebuilding the site for a heavier load.
Before you compare budgets, answer three questions for yourself. How many hours does the project eat in a quiet month, and how many at peak? How many of the five areas does the person doing the work now cover, and which ones do they simply leave alone? And what happens if tomorrow that person, in-house or outside, stops answering?
The answers usually show what the setup is missing.
