I am usually on the other side of this conversation. Founders hire me to build first versions, or to fix ones that were built too fast. This is what I would tell a friend who was about to hire a full-stack developer for a startup: what the role really covers, how to tell a builder from a talker, and how to set the engagement up so you are safe if it goes wrong.
What "full-stack" means for a first version
For an established product, full-stack means someone comfortable across the interface and the backend. For a first version it means more: one person who owns the whole thing, from the screens to the database to the billing to the server it runs on.
That matters because the parts of an MVP that go wrong are the joins. A payment that succeeds in the billing provider but is not recorded in the app. A customer who can see another customer's records. A long job that runs inside a web request and times out. None of these belongs to "the front end" or "the back end". They belong to whoever owns the whole.
So the first filter is simple: has this person shipped a product where they owned all of it, and can you open that product today?
Check the work before the call
A résumé lists technologies. A portfolio shows screenshots. Neither tells you whether the thing works.
Open their products
Ask for two live products they built end to end. Sign up. If one takes payments, pay for something small. Note how sign-up, login and errors feel. This takes twenty minutes and filters out most candidates.
Read one case study closely
A real case study names the problem, what was built, what changed and what was hard. A vague one lists features. Detail is the tell.
Look at how they write
You will spend the engagement reading their messages. Plain, specific writing on their site usually means plain, specific updates later.
Questions that expose gaps
Ask these on the first call. You do not need to understand the answers in depth. You need to notice whether the answer is specific or generic.
| Question | A good answer sounds like | A worrying answer sounds like |
|---|---|---|
| "How do you make sure one customer can never see another's data?" | Names a mechanism: rules enforced in the database or the server, tested as two different users | "The app checks who is logged in" |
| "What happens when a subscription renewal fails?" | Talks about the billing provider's events, retries, and what the customer sees | "Stripe handles that" |
| "Where do the secret keys live?" | On the server, never in the browser, in your accounts, rotated if exposed | Does not know, or "in the config" |
| "What would you cut from my feature list for version one?" | Cuts features, keeps security, billing and data separation | Cuts nothing, or cuts the plumbing |
| "How will I see progress?" | A staging link after each slice, in your repository | "I will show you at the end" |
| "What happens if you disappear?" | The code is in your GitHub, the infrastructure is on your accounts, and it is documented | Silence |
The last question is the one founders skip, and it is the one that decides how bad a bad outcome can be.
Red flags
- A price before a scope. Nobody can price what they have not defined. A quick number means they are guessing or planning to renegotiate.
- Hourly rates with no estimate attached. The rate is not the cost. The cost is the rate times an unknown.
- "Everything in two weeks." Something is being skipped, and it is usually the parts you cannot see.
- Their stack, not your problem. If the first ten minutes are about frameworks, they are selling what they know rather than solving what you have.
- No product you can open. Demos, mockups and "it was under NDA" are not proof. One live product is.
Structure the engagement so you are safe
- Start with a short paid scope. A first slice with a clear deliverable, such as login, roles and one screen. You learn how they work; they learn your product. Both sides can walk away cheaply.
- Get the first version in writing. Features, roles, plans, what launch means. One page is enough. Everything not on it waits for real customers to ask.
- Pay for milestones, not hours. A fixed price for the agreed scope, split into milestones you can see on a staging link. Changes get their own quote.
- Ask for a staging link after every slice. You should be clicking through the product every week, not at the end.
- Agree the handover up front. Documentation, a walkthrough and access to everything, whether the engagement continues or not.
What I do
This is how I work when someone hires me under SaaS products: a written first-version scope, a fixed quote, the repository and accounts in your name, a staging link after each slice, and the plumbing that gets MVPs rewritten (login, data separation, billing) done properly the first time. Scribeside, an AI medical scribe, was built this way: one engineer owning the pilot end to end, with two-factor login, audit logs and credit-based billing in the first version rather than bolted on later. You can read that story in the Scribeside case study.
If you already have a developer and want a second opinion on what they built, that is a different conversation, and I have it under prototype to production.