You've found a small team you like. The developer on the call clearly knows the work, the estimate makes sense, and the price is a fraction of what the big agency quoted. Then, usually right around the time the contract lands on your desk, a quieter question shows up. What happens if that developer leaves?
The short answer: if your developer leaves, gets sick or goes on holiday, your project shouldn't stop, and the reason should be something you can check rather than a promise. At Conimex IT the reason is how we staff. I'm on every project from the first day as CTO, architect and project manager. A second developer reviews code before it goes in. Every project carries documentation a newcomer can start from, and most of our contracts name the people who work on it. What you won't get from us is a replacement developer in 48 hours, and I think anyone who offers you one is selling the wrong thing.
Why "what happens if my developer leaves" is the right question
Engineers have a grim name for this risk. The bus factor is the number of people who'd have to disappear from a project before it stalls. Hit by a bus, in the grim version. Hired away, far more often. A bus factor of one means everything depends on a single person.
It's more common than you'd guess, even in projects with big communities behind them. A 2016 study of 133 popular open source projects on GitHub found that 34% had a bus factor of one and 65% had a bus factor of two or less. You'll see 46% quoted online for the first figure. The paper says 34%. A later study led by the same first author looked at what happens when the worst case actually arrives: in 315 projects where every key developer walked away, only 41% survived, and only because new people stepped in and took over.
Inside companies it isn't better. In a 2022 survey of 269 engineers by researchers at JetBrains and Bilkent University, 63% said they'd worked in the past year on at least one project where they felt there was a high risk of the bus factor dropping to zero. Only 19% had ever worked on a project where anyone told them what the bus factor was.
Those numbers come from open source and from large companies. Nobody has studied teams as small as ours this way. The mechanism doesn't care about size, though, and the moment before you sign with a small team is exactly when to ask about it.
How we staff a project
We're a team of five, and I'm one of the five: two backend developers, one frontend developer, one QA engineer who tests what we ship, and one designer. Whatever else I'm doing, I'm on every project as CTO, architect and project manager. We never run more than three projects at the same time.
The smallest project we run has one developer on it. That sounds like a bus factor of one, and on its own it would be. It isn't, because the person who designed the system is on the project too.
For problems outside our daily work we bring in consultants, and they're the same people every time. When a project needs a complex payment setup on Stripe, or a complex calling and messaging setup on Twilio, we call in consultants who guide us through that specific problem. They're long term collaborators, not whoever happened to be free that month.
Where the knowledge lives, so it doesn't walk out the door
A bus factor is really a question about where knowledge sits. Here's where ours sits.
In review. We try to have every change reviewed by a second developer before it goes in. Code review is usually sold as bug catching, but when Alberto Bacchelli and Christian Bird studied it at Microsoft in 2013, they found it was less about defects than people expected and more about knowledge transfer: the reviewer ends up understanding code they didn't write. That side effect is exactly what you want on the day someone is suddenly away.
In the repository. Every project has a detailed README, the file that tells a developer how to install and run the project, plus a TODO list and a written record of the tasks in progress and the tasks already finished. Someone new can see what was done and what's left without asking the person who's gone.
In the code itself. On the frontend we don't have a second developer, so we lean on structure instead. We insist on the SOLID principles there, five design rules that keep each piece of code doing one job and let you change one part without breaking the rest. Code written that way is much easier for a stranger to pick up. It still isn't a second person, and I'll come back to that.
In your contract. Most of our contracts name the people who work on the project. Not all of them, because it depends on what the client asks for. If you want names in yours, ask.
And ideally in your accounts. We prefer the code, the servers and the service accounts to be in the client's name, with access given to us. In practice plenty of clients have nobody who can set up hosting, repositories and third party services, so we often run them on our company accounts instead. That's convenient. It's also a dependency on us, and you should know about it from the first day. Whoever holds them, ask for a written list of every account your product runs on.
Holiday, illness, resignation: three different answers
Most agencies answer "what if someone is away?" with one sentence about backups. It's three different situations, and they don't get the same answer.
Planned holiday
Serbian labour law gives every employee at least 20 working days of annual leave a year, and the first part has to be at least two weeks in a row. So absences aren't a risk, they're a certainty, and a predictable one. We plan them internally. They're our scheduling problem, not something you should have to manage.
One thing worth knowing if you're in Western Europe: our public holidays aren't yours. In 2027 Orthodox Easter falls on 2 May, five weeks after Western Easter, on the same weekend as Serbia's 1 and 2 May holidays.
Sudden absence
We haven't yet had a developer fall seriously ill in the middle of a project. We have had the closest thing to it: a client asking for one of our developers to stop working on their project immediately. No notice period, no handover week. Each time, I took over the responsibility myself and carried on with the work.
That's what an architect on every project is for. When someone has to leave a project from one day to the next, the person stepping in isn't learning the system from scratch, because I designed it.
Resignation
Nobody has left Conimex IT in the middle of a project. Yet. When it happens, the replacement will need time, and here's the number I'd give you: in our experience it takes about three months for a developer to fully master a medium sized project. Research on developer onboarding lands in the same range. Minghui Zhou and Audris Mockus found that productivity levels off within a few months on small and medium projects and can take up to a year on large ones.
Why we don't rotate developers, and why 48 hours is the wrong promise
Here's where I disagree with a lot of the industry. Large agencies move developers between projects all the time, and small and medium clients are the ones who pay for it. Their complaint is always the same: over the course of one project they had developer after developer, every change slowed the work down, and the product they got at the end was worse for it.
That's why a replacement in 48 hours doesn't impress me. The replacement arrives in two days. The understanding arrives in about three months. Fred Brooks put the general version of this in 1975: "Adding manpower to a late software project makes it later." A project that keeps swapping people never really leaves the onboarding phase.
What a team our size can't do
This is the part most agency posts leave out, so here it is plainly.
Our frontend has a bus factor of one. Clean SOLID code and an architect who knows the system shorten a takeover, but if our frontend developer is out, frontend work slows down until that developer is back or someone else has learned the code.
We can't run a standing 24/7 on call rotation, where an engineer is always ready to respond to an outage. Google's handbook on running production systems puts the minimum for a sustainable single site rotation at eight engineers, which is more than our whole team. If your product needs someone answering alerts at 3 a.m. every night of the year, you need a bigger team or a dedicated operations provider.
We can't double in size next month either. If you need ten developers by the first of the month, we're the wrong call. We'd consider that kind of request only from a client who commits to working with us over a longer period.
And until a resignation actually happens, our answer to one is a plan, not a track record.
Seven questions to ask any development team before you sign
Ask these of us, and ask them of anyone else you're talking to. A good team answers each in a sentence or two. Here are ours.
- Who else knows my code? I do, because I'm on every project as architect. On the backend we have two developers. On the frontend we have one, and that's our weak spot.
- Is every change reviewed by someone else? We try to make it every change.
- Where are the code, servers and accounts? Ideally in your name. If you'd rather we set them up, on ours. Either way, you should know which.
- Are the people named in the contract? Usually. If you want them named, they will be.
- How often do you move developers between projects? As rarely as we can. Rotation is the thing we argue against.
- How long does a new developer need to take over? About three months to fully master a medium sized project.
- What can't you cover? A standing 24/7 on call rotation, and doubling the team at short notice.
Which kind of team fits your project
If you need round the clock on call cover or ten developers next month, hire a bigger provider. We'd tell you that on the first call.
If you're building one product and want the same people from the first commit to launch, a small team with an architect on every project is the safer choice, not the riskier one.
If you're a bank, an insurer or another financial firm, the EU's Digital Operational Resilience Act (DORA), in force since 17 January 2025, already requires exit strategies for IT providers that support your critical functions. Ask for one whatever the size of the team.
If this is the question holding up the contract
We build custom web and mobile products in Laravel, React and React Native, from Belgrade, on the same working hours as most of Europe. If you're weighing a small team for your next build and continuity is the thing holding up the contract, ask us directly. Before you sign anything, we'll tell you who would work on your project by role, who reviews their code and whose name your accounts would sit under. Get in touch at [email protected].