You are choosing between two bets: a permanent full-stack developer on your payroll, or a small external team contracted for a defined scope. They fail in different ways, and the wrong one is expensive to unwind. Here is the comparison as we would give it to a friend, including the cases where hiring is clearly the better call and you should stop reading.
What a full-stack hire actually costs, beyond the salary line
Salary is the number everyone compares and the smallest part of the decision. On top of gross pay sit employer social contributions (substantial in France and much of continental Europe, lighter elsewhere, never zero), paid leave, sick leave, equipment and per seat tooling. A working full-stack setup carries recurring costs of its own: source control, a hosting platform (Vercel's Pro tier is roughly 20 US dollars per seat per month at the time of writing), a managed database (Supabase's paid tier starts around 25 US dollars a month per project at the time of writing, with usage above the included quota billed on top), error tracking, a password manager, a CI budget.
Then the acquisition cost. Recruiters charge a percentage of first year salary. Screen candidates yourself instead and you pay in senior engineering hours: writing the brief, filtering CVs, setting a technical exercise, running the interviews, chasing the people who go quiet. Add ramp up. A genuinely senior developer joining an unfamiliar codebase ships nothing load bearing in week one. Expect several weeks before their pull requests stop needing heavy review, and longer if documentation is thin or the previous developer left without a handover.
None of this argues against hiring. It is the denominator you need before comparing anything. If the honest total fits your runway and you have a year of continuous product work queued, hiring is very likely the right call.
One developer is one point of failure, and one skill profile
A single hire concentrates everything: the code, the context, and the reasoning behind decisions nobody wrote down. That is fine until it is not. Annual leave, sick leave, parental leave and notice periods all land on the same person. When they resign, and eventually someone does, you serve a notice period commonly running one to three months in France and much of Europe, then inherit a codebase no one else has read.
There is also the breadth question, which is routinely underestimated. Plenty of developers genuinely cover React, an API layer and a Postgres schema. Far fewer are also strong on what only surfaces in production: Stripe webhook handling that is idempotent and tolerant of out of order delivery, Supabase row level security policies that were never really tested because development ran through the service role key, serverless functions exhausting Postgres connections with no pooler in front of the database, App Router caching quietly serving stale data after a deploy, migrations written with no rollback path, an N+1 query that only bites once the table passes a million rows, rendering choices that decide whether Google indexes a page at all.
One person covers part of that list well and the rest at whatever depth they had time for. Neither model removes the risk: hiring concentrates it in a person, contracting concentrates it in a supplier. Both need the same antidote, which is written documentation and code you own outright.
When hiring clearly wins, and when we are the wrong supplier
Hire in house when your roadmap never empties (continuous work keeps a permanent developer busy and repays the ramp up many times over), when the software is the business rather than a channel for it, when domain knowledge accumulated over years is your actual moat and belongs inside the company, when you need incident response measured in minutes with someone on call, or when this first hire is meant to grow into the person who leads the team.
There are also cases where we are the wrong supplier whatever model you pick. If you want weekly calls, video demos, a kick off workshop or a standing calendar slot, we do not offer them, and that is policy rather than availability. If you need someone physically on site, we work remotely from Dijon and nowhere else. If your stack is Rails, Django, .NET, Java and Spring, native iOS or Android, or heavy data and ML infrastructure, hire people who live in it: we work in TypeScript, React, Next.js, Node and Postgres, and stretching outside that costs you more than it costs us. If you need a 24/7 pager rotation, or five workstreams running in parallel next month, two people cannot honestly do it.
If three items here describe your situation, hire. Better you read that now than six weeks in.
When a small contract team is the better fit
The contract model earns its place when the work has edges. A rebuild, a migration off a legacy CMS (URL map, 301s, and keeping the handful of pages that actually rank), a Next.js front end over an existing API, a Stripe integration with the webhook and reconciliation work done properly, a site that has to rank and convert rather than merely exist. Scope with a defined end, in a stack the team already knows cold, is where an external team beats a new hire on time to first useful output: no ramp up on the tooling, only on your domain.
Second, management overhead, which rarely shows up in the comparison and should. A hire needs onboarding, one to ones, code review, career conversations and eventually a replacement plan. If your founding team is two people and neither wants to become an engineering manager this quarter, that cost is real. With a contract team you write a brief and read a pull request.
Third, reversibility. You can stop. No notice period, no severance question, no difficult conversation. Most of our work sits in this shape: French SMEs such as Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats and Vectosolve needed a defined thing built well, not a permanent engineer on payroll.
A hybrid works too. Have an external team build version one and document it deliberately, so the developer you hire in six months inherits migrations, a README that actually runs, and notes on the non obvious choices.
How two people in Dijon work with a client in California or Bangalore
We are two people. Robin Monteiro writes the code (TypeScript, React, Next.js, Node, Postgres) and Florian Loppion handles the marketing side. One office, at 9 rue Jean-Jacques Rousseau in Dijon, France. No branch in London, none in New York, no account managers. You get direct access to the people doing the work, with nothing routed through a layer that does not read code.
Everything runs in writing, by email, and we reply within 24 business hours. No calls, no video, no scheduled slots, not even as an option. For an international client that is the useful part rather than the compromise. A founder in California never takes a call at 3am to accommodate Central European Time. A team in Bangalore never waits on a 30 minute window that lands at the end of their day. Work moves during your hours and during ours, and the overlap stops mattering.
The other benefit shows up months later. Every specification, trade off and change of direction sits in a thread you can search. Nobody argues about what was agreed, because it was typed. When a bug appears in November, the reason a field was made nullable in March is still there in writing.
What you do differently: write the brief properly instead of talking it through, batch feedback rather than sending one line at a time, and be explicit when a decision is final. If your company decides verbally and documents nothing, this feels slow for a week or two, then usually feels faster.
Handover, ownership, and never being captive
You own the code, the accounts and the domain name, from the first commit rather than as a concession at the end. The repository lives in your GitHub organisation or is transferred into it. The domain sits in a registrar account in your name. Hosting, database and payment provider run under your billing, with us added as collaborators and removable in one click. No mandatory subscription, no proprietary layer that has to keep running for the site to stay up, no build step only one machine can perform.
Handover, whether it goes to an in house hire, another agency or you, is a document rather than a ceremony. It covers running the project locally, what every environment variable does and where its value comes from, how to deploy and how to roll back, where the migrations live and how they are applied, which third party services are involved and who owns each account, plus notes on the decisions that look strange until you know why (that unusual index, the webhook replay guard, the reason a given page renders on the server).
Ask any supplier the blunt version before signing anything: if we part ways next month, what exactly do I have. If the answer involves a dashboard only they can log into, a theme only they can edit, or a domain registered in their name, you are not buying software. You are renting access to it.
