Hire full-stack developers to carry one change, screen to schema
One developer owns the change end to end. The screen somebody clicks, the API behind it, and the table the data lands in. What matters before you hire anyone is where that ownership stops, so that is written down here, along with the two situations where one person is the wrong answer and you should go and hire a specialist instead. Two things hold from day one and you can check both before you commit to anything. Your code lives in your repositories and your deployments run in your cloud accounts. The intellectual property is yours from day one, not on completion and not on final payment. Send the brief and a shortlist comes back, typically within a few days. Interview whoever is on it, or skip the interviews and go straight to a two-to-three-week pilot whose criteria are agreed with you before anyone starts.
Send the brief
Send what you have. A rough outline is enough to start. Tell us what needs building and what already exists around it. A shortlist comes back, typically within a few days, with the people on it named. Sending this commits you to nothing.
The strongest argument against hiring one full-stack developer was made in public, and it goes like this.
Where it was said
"Full stack compresses two jobs into one. It's purely for cost-savings." vsareto, 30 May 2021, on Hacker News.
That is fair, and it is why there is no saving quoted anywhere here. If one person covers two jobs and nothing else is true, you have bought a discount and inherited a bottleneck.
From the same community, the other half of it.
But engineer #1 likely has to be full-stack. ... once you have 3+ engineers, a mix of full-stack and domain experts can ease planning challenges.
Both of those are right at once, and together they set the real question. One person is the correct shape early and the wrong shape at some size, and the people who argue this in public do not agree where that size is. So the thing to settle is not whether one developer can do the work. It is what one developer owns, and what happens at the edge of it.
What splitting one change between two owners costs
Splitting one change between two owners has a measured cost, and it was measured twice. Herbsleb and Mockus, writing in IEEE Transactions on Software Engineering in 2003, tracked every modification request in one department for two years, 2,227 of them. A change carried at one site took 5 days. The same class of change involving more than one site took 12.7 days. They then repeated the work in a second department, on a different product, with no shared people and no shared sites: 4,974 changes, 7 days against 18.
Show data table
| Dimension | One site | More than one site |
|---|---|---|
| Department A | 5 days | 12.7 days |
| Department B | 7 days | 18 days |
The authors then tested why, and the answer is not the one usually assumed. Once the number of people on a change is accounted for, being distributed has no significant independent effect of its own. Splitting a change pulls more people onto it, and more people is what makes it slow.
That is not an argument for paying for fewer people. It is an argument about how many people one change passes through, and it is a question you can put to everyone bidding for your work.
One developer covering the whole change is not always right. Across ten public discussions of exactly this question, three people name a number and the three do not agree: one or two people who can do everything, a mix once you have three or more, good for up to twenty and maybe past that. Anyone who hands you a single threshold is guessing at it. Here is how we would decide it in your situation, and two of the three cases have a better route than this one: when only the API and the database side need a specialist, and when the interface is the whole job and someone else already owns the API.
Where one full-stack developer is the wrong answer
This is the first software engineering hire
Choose this when
Whoever comes first has to cover everything, because there is nobody to hand anything to.
What that means
One full-stack developer is the right shape here. It stays right until a second and a third arrive and the work starts to specialize on its own.
Only the API and the data side need a specialist
Choose this when
If the interface already has an owner and the open work is schema, queries under load, auth, and throughput, hire for that end alone.
What that means
You will get deeper answers from someone who does nothing else.
The interface is the whole job
Choose this when
If someone else already owns the API and the work is state, accessibility, and what happens on a slow device, hire for that end alone.
What that means
For the same reason. You will get deeper answers from someone who does nothing else.
More people claim this title than any other, of the 43,560 who answered the job-role question
A stack of CVs all carrying the same two words tells you very little, and there is a measured reason for that. In the Stack Overflow Developer Survey 2025, 27 percent of the 43,560 people who answered the job-role question chose Developer, full-stack. It is the top answer, claimed by 1.9 times as many people as the second one, back-end at 14.2 percent. That ranking has held five years running under two different question designs.
Show data table
| Item | Share of respondents |
|---|---|
| Full-stack | 27% |
| Back-end | 14.2% |
| Student | 11.3% |
| Architect | 6.1% |
| Desktop or enterprise | 4.3% |
| Front-end | 4.3% |
| Mobile | 3% |
| Embedded | 2.8% |
The denominator there includes students and people who have retired. Read it as what people call themselves rather than as a census of working developers. Either way the title is a claim and not evidence, and it filters nobody. The useful move is to stop reading the title and start asking for evidence at a specific boundary.
Every candidate names one end first, and that is the end they are comfortable in. The evidence worth asking for is always about the other one.
Ask about the end they mentioned second
Layer 1
Data
Ask how the schema was decided, what a query does under load, how auth is enforced, and how a migration runs against live data. A schema change is the one change a redeploy cannot roll back, which is why it is worth asking about even when nobody mentioned it.
Hands upward
Every change at this layer is reviewed by a senior software engineer before merge, and the architecture decision behind it is written into the technical requirement specification.
Layer 2
API
Ask what the API promises, what it does when a dependency is slow, and what happens to the same request arriving twice. The contract between the two ends is where ownership quietly stops on most teams.
Hands upward
GitFlow branching, unit and integration tests, and CI/CD gating every merge.
Layer 3
Interface
Ask about state with three tabs open, keyboard-only use, and what a slow device does with the page. Then ask them to explain one decision inside something they built, rather than to describe it.
Hands upward
We can tell you what our process guarantees about any change at this layer. What a particular person is strong at is what the interview and the pilot are for. We would rather you found that out yourself than took our word for it.
Here is what to ask at each boundary, and what we guarantee about a change that crosses it.
One build, and the three boundaries inside it
We built a cloud-based RFID solution to help SMBs track inventory across multiple stores with real-time scan accuracy, automated vendor reordering, and smart SKU validation.
- The scan interface
Real-time scan accuracy, used by people working a floor rather than a desk, where a failed read costs someone a second walk across a warehouse.
- The reordering automation
Vendor reordering driven by what the scans reported, with SKU validation in front of it so bad data did not enter the system in the first place.
- The multi-tenant data model
Separate businesses kept apart inside one system, which is a schema decision before it is anything else.
All three of the boundaries named above were inside one piece of work. That is what was built, described rather than measured, and it carries no figures because we will not put a number in front of you that we cannot show you the source of. It is offered as that and nothing more.
Send the brief
Tell us what needs building and the shape of the team around it. A shortlist comes back, typically within a few days, with the people on it named. Interview whoever you want to interview, or skip the interviews and go straight to a pilot. If our current bench does not match your requirement, we tell you that directly instead of sending someone close enough, because a near miss costs you a month you do not get back. Sending the brief commits you to nothing, and no document is held back behind it. What comes next is a two-to-three-week pilot, and the criteria it is judged against are written down and agreed with you before the developer starts.
You cannot tell in advance which project you are on
Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester published a study of 4,677 IT projects in the Journal of Management Information Systems in 2022. Every project in it had a paired estimate and actual cost, across 66 countries.
The median cost overrun was 1.0 times. The median project lands on budget, and overruns and underruns turn out to be about equally common, so the familiar claim that most projects run over is not what this data shows.
The tail is the part that should worry you. The mean is 1.8 times, the largest overrun in the sample is 280.4 times, and the authors state plainly that the average cost overrun for IT projects does not exist as a number, because the distribution has no finite mean. The worst single case they found was not a megaproject. It was a workflow customization estimated at USD 1,500 that finished at USD 425,000.
1.0x
Median cost overrun
280.4x
Largest overrun in the sample
What nobody can tell you, including us, is which one yours is going to be.
| Option | times the estimate |
|---|---|
| Median cost overrun | 1.0x |
| Largest overrun in the sample | 280.4x |
If you are pricing the in-house version of this hire, start with what the published sources say and notice that they do not agree with each other. Three of them put the same role between USD 101,612 and USD 138,000, roughly 36 percent apart, across different years and different collection methods. Indeed's figure comes from job postings in 2026. Glassdoor's is from 2025. Stack Overflow's is a self-reported median from its 2025 developer survey.
Three published sources, one role
Published in-house salary figures for one full-stack developer
USD 101,612 (Indeed, 2026) to USD 138,000 (Stack Overflow Developer Survey, 2025) · median USD 132,219 (Glassdoor, 2025)
None of these is an Atyantik figure. Each mark carries its own publisher and year, and all three describe an in-house hire in the United States.
Whichever of those you build your model on, the payroll line is the visible part. Employer taxes, benefits, equipment, and the cost of running the search all sit on top of it, and there is no honest multiplier to give you for that, so the published numbers stop where they stop.
Use the spread as the range for your own alternative, and ask anyone who gives you a firm number what they read before they arrived at it.
And that hire is not permanent
An in-house model usually stops at one salary for one year. The role turns over, and refilling it costs time and money that never appears in the comparison.
US Bureau of Labor Statistics, Employee Tenure in 2024.
Ashby, 2026.
Gallup, 2019.
Those three are separate measurements from three separate bodies, so do not add them into a single figure. Read them as the shape of the commitment instead. The role is filled for a few years rather than indefinitely, the search to refill it is measured in months rather than weeks, and the refill costs a fraction of a salary at the low end and several times one at the high end.
None of that argues against hiring in-house. It argues for putting the turnover line in the model before you compare anything to it.
The thing you cannot do on a software project is watch closely enough to know how it is going. So every stage here hands you something to read instead of a reassurance.
What happens, and what you get to read
01
Brief and shortlist
You send the brief. A shortlist comes back, typically within a few days, with the people on it named. If our current bench does not match your requirement, we tell you that directly. Interview whoever you want to interview, or skip it.
You get
A named shortlist
02
Pilot criteria, agreed first
Two to three weeks, and the criteria the pilot is judged against are written down and agreed with you before the developer starts. If those criteria are not met, the developer is replaced and the pilot re-runs with the next candidate against the same criteria.
You get
The evaluation criteria, in writing, before anyone starts
03
Working setup
Code lives in your repositories and deployments run in your cloud accounts from day one. Overlap hours are agreed at scoping; our working day runs 10:00 to 19:00 IST. Most engagements run three months or longer, and the length follows the work rather than the contract.
You get
Repository and deployment access, in your own accounts
04
Decisions, and the exit
Architecture decisions are documented in the technical requirement specification as they are made, and a scope change is written down before it is accepted. When we stop, you keep everything, the operational runbook included.
You get
The technical requirement specification, and the operational runbook at offboarding
What is being agreed, in five lines
The person who signs is usually not the person who read the argument, and should not have to. These commitments stand on their own with nothing around them.
Atyantik Technologies: 50+ enterprise engagements across 7 countries, from our engagement record, confirmed 2026-05-14. Ask whoever else is bidding for the same three things in the same form: who owns the code, what you keep if the work stops, and what the pilot is judged against. Written answers to those three, side by side, will settle the decision faster than another conversation about capability.
The terms, on one screen
Atyantik Technologies: hiring a full-stack developer, the terms
- Confidentiality An NDA with Atyantik Technologies is in place from day one.
- Code ownership You fully own the code, and the IP is yours from day one.
- Where the work lives Work happens in your repositories and your cloud accounts, with SSO and secure repositories.
- Working hours Working hours are agreed at scoping and written down.
- Ending it If it ends, it ends cleanly. You keep everything, the operational runbook included.
Before you send the brief
Ownership, review, hours, and what happens if the person changes. Answered here rather than on the call.
Who owns the code, and where does it live while it is being written?
- If you already have Git hosting and cloud accounts, we work inside them.
- If you do not, we provision them and hand you the keys.
- When an engagement ends you keep everything, the operational runbook included.
How is a change reviewed before it reaches the main line?
Can we interview the people you propose?
- Many clients run technical interviews or their full hiring loop, and others trust our vetting and skip interviews entirely. Both are fine.
- Everyone we propose is vetted by our own technical team first and comes from a pool we train continuously.
- If a shortlist does not produce a fit we send another, and if our bench does not match what you need we say so directly.
One developer covering both ends is one point of failure. What if they move on?
Is it only the developer, or do DevOps and QA come with them?
What happens when the scope changes halfway through?
What hours will they work?
- Every developer is currently based in India, and European teams get substantial afternoon overlap.
- Where a live sync is needed, a project coordinator can host it.
- An overlap shift can also be arranged on request.
- Overlap is agreed at scoping. We do not offer continuous cover.
Send the brief
There are two good outcomes here. Either we agree a pilot, with the criteria written and agreed before anyone starts, or the first conversation shows this is not the right shape for what you are building and you go and hire the right one.
If a developer does not pass the criteria you set, we replace them and re-run the pilot against those same criteria. That commitment is exactly as narrow as it sounds: it covers the developer, not the engagement.
Tell us what you are building, what already exists around it, and when you need somebody in it. A question instead of a brief is a fine use of the same form, and you will get an answer either way.
- Your repositories, your cloud accounts
- IP yours from day one
- Pilot criteria agreed before anyone starts