How long should hiring a full stack developer take?

The scoping conversation is the part worth spending time on; the hiring decision itself is usually quick once a written scope exists, because the scope is what you are really comparing. Expect the sequence — brief, conversation, written scope, quote — to take longer than reading CVs, and to save more than it costs.

Should I hire a freelancer, an agency, or in-house?

One freelancer suits a product with a single core workflow where continuity matters more than capacity. An agency suits parallel workstreams, a support rota, or a risk model that needs more than one person to know the system. In-house suits a product that has found its market and now needs permanent ownership. The wrong one is not usually the cheapest — it is the one whose shape does not match the work.

How do I check code quality if I am not technical?

Pay an independent developer for an hour to read the repository and answer three questions: is this structured the way you would expect, is anything here going to be expensive to change, and could you pick it up. That hour is the cheapest insurance in the process, and the answers are legible even if the code is not.

How to hire a full stack developerGuide — 10 August 2026

Hiring one engineer to own a whole product is a different decision from hiring for a role on a team. This is the sequence that makes it a decision rather than a gamble: define the outcome, write a brief, ask questions whose answers mean something, and agree ownership before any code exists.

Start from the outcome, not the feature list

The most expensive mistake happens before anyone is contacted. A brief written as a list of features locks in a solution you chose before anyone with engineering judgement looked at the problem — and every developer who reads it will quote against the list rather than tell you the list is wrong.

Write down what has to be true when the work is finished instead: who is using it, what they can do that they cannot do today, and how you will know it worked. A good developer comes back with a shorter feature list than the one you would have written, and that conversation is worth more than any discount.

What a full stack developer should actually be able to do alone

The term is used loosely enough to be worth pinning down. Someone hired to own a product end to end should be able to take a described outcome and, without a second engineer, produce all of the following:

A data model that will survive the next two releases, not just this one
A working API with authentication, roles and permissions
An interface a real user can complete the core workflow in
A deployment pipeline and a staging environment that is not someone's laptop
Sensible error handling on the paths that touch money or data loss
Enough documentation that another developer can run and change it

How to hire remote developers: the five questions worth asking

Hiring someone you will never meet removes the signals interviews normally lean on, so the questions have to do more work. Most test recall. These test judgement, which is the thing you are actually buying.

Describe an architectural decision you made and what you gave up to make it — an answer with no trade-off in it means the decision was a default, not a decision.
What would you cut from my brief? — silence here is a warning; anyone who agrees to everything has not read it.
How will I see progress between now and delivery? — the answer should involve a repository and an environment, not a status call.
What happens to this project if you disappear next month? — the good answer is structural: my accounts, my repository, documentation written as work lands.
What is a project you would turn down? — a developer with no boundary has no basis for scoping.

How to read a portfolio when you are not technical

Screenshots prove design taste and nothing else. In a case study, look for whether the writer explains the problem before the solution, names a constraint they worked within, and lists a stack that makes sense for what the product does.

Ask for one live URL and try to complete the main workflow yourself — a product with real users behaves differently under a stranger's hands than a portfolio piece that has never had any.

If a codebase is available, an hour of an independent developer's time reading it costs a fraction of a project and tells you more than any interview.

See 15 shipped projects and how each was built

Scope before price, in that order

A quote produced before a written scope is a guess, and you will pay for the guess — either as a change-request argument halfway through, or as padding built into the number to cover the unknowns.

The sequence that works: conversation, written scope naming what is included AND excluded, then a price against that document. It also gives you a way to compare two quotes that differ by a factor of three — if one names error handling, staging and a migration path and the other says "build the app", they are not quotes for the same work.

What actually drives the price of a build

Agree ownership before anything is built

Boring to discuss, expensive to discover late. The repository, hosting account, domain, database and every third-party service should be created in your name at the start — not transferred at the end, and not held against a final invoice.

Ask directly, get the answer in writing, and check you can actually log in. A developer who resists this is telling you something useful about what leverage they expect to need.

Fixed project, or a dedicated developer monthly?

Fixed scope suits work with an end — an MVP, a rebuild, a defined feature set. It gives you a document to hold the work against and a clear finish line.

A monthly engagement reserves a share of an engineer's time with scope agreed as it goes, which suits a live product where next month's priorities depend on what this month's users do.

Most relationships start as the first and become the second after launch. Worth saying out loud at the start rather than negotiating under pressure later.

Hire a full stack developer — how I work and what I build MVP development for startups

The warning signs

None of these are proof of anything on their own. Two together are worth slowing down for.

A price quoted before a scope was written
No questions asked about your users or your deadline
Reluctance to put the repository in your name
Estimates given in days for work nobody has broken down
A rewrite recommended before the existing code has been read
Agreement with every request in the brief, including the contradictory ones

Common questions

How long should hiring a full stack developer take?: The scoping conversation is the part worth spending time on; the hiring decision itself is usually quick once a written scope exists, because the scope is what you are really comparing. Expect the sequence — brief, conversation, written scope, quote — to take longer than reading CVs, and to save more than it costs.
Should I hire a freelancer, an agency, or in-house?: One freelancer suits a product with a single core workflow where continuity matters more than capacity. An agency suits parallel workstreams, a support rota, or a risk model that needs more than one person to know the system. In-house suits a product that has found its market and now needs permanent ownership. The wrong one is not usually the cheapest — it is the one whose shape does not match the work.
How do I check code quality if I am not technical?: Pay an independent developer for an hour to read the repository and answer three questions: is this structured the way you would expect, is anything here going to be expensive to change, and could you pick it up. That hour is the cheapest insurance in the process, and the answers are legible even if the code is not.