Questions to ask before hiring an MVP developer

Why it matters

Hiring the wrong person to build your MVP costs more than their invoice. It costs the months, and often a rebuild. Many of the problems come from questions nobody asked at the start: who owns the code, what was in the price, who was meant to design it.

None of these questions are awkward to ask a good developer. They will have clear answers, usually in writing already. Vague answers to clear questions tell you a lot.

This checklist is part of my guide to how to build an MVP. It is about questions to ask any individual or team. If you are still deciding between an agency, a freelancer and AI tools, I compare those in agency vs freelancer vs AI tools, and the UK against offshore teams in UK vs offshore MVP development.

Before the first call, it helps to have a written scope. How to scope an MVP in one afternoon gets you there, and the MVP cost calculator gives you a rough number to sense-check quotes against.

The checklist

You do not need to ask every question on the first call. Use the first call for the work, the team and the design questions, because those tell you whether this is the right person at all. Save the scope, ownership and data questions for when you have a proposal in front of you, and ask for the answers in writing as part of it. A good proposal will already answer most of them without being asked.

Their work

Use the products, do not just look at screenshots. Sign up on your phone, try the main flow and try to break it. A product that works well on a bad connection tells you more than any portfolio page.

Speaking to a past client is the most useful ten minutes in this whole process. Ask what went wrong, not just whether they were happy, because every project has a hard week. What you want to hear is how the developer handled it.

Who does the work

Capacity matters more for a small team or a solo developer than for an agency. A good freelancer with three other projects can still deliver, but you should know about it before you plan a launch date around their diary.

Design

A developer will build what you describe. If nobody designs the flows first, you can end up with a product that works and confuses people. If the developer does not design, budget for a designer as well.

Scope and price

The pricing model matters as much as the price. Fixed price vs day rate explains who carries the risk in each, and how change requests usually work.

Ask about running costs early. Hosting, the database, email sending, error tracking and any paid APIs are small at MVP scale, but they are yours from launch day, and a developer who has thought about them will have a rough monthly figure ready.

Ownership and accounts

This is easy to skip, and it is the most expensive to fix later. GOV.UK's guidance on copyright ownership says that someone working under a contract for services usually keeps the copyright in what they create, unless there is an agreement to the contrary, and that when you commission work, the creator is usually the first owner unless you agree otherwise in writing. Settle it in the contract, in writing, before you pay.

Accounts matter just as much. If the hosting, database or domain sits in the developer's account, you do not fully control your own product, whatever the contract says about code.

Your users' data

If your developer handles personal data on your behalf, UK GDPR expects a contract between you as controller and them as processor. The ICO lists what it must cover, including acting only on your documented instructions, confidentiality, security measures, using sub-processors only with your authorisation, and deleting or returning data at the end. A developer who has never been asked for one is not necessarily a problem. One who refuses is.

After launch

The after-launch questions are easy to leave until launch week, when you have the least leverage. A product is never finished on launch day. The first real users will find bugs and ask for changes, and you want to know in advance who handles them, how fast, and at what cost.

Common misses

Hiring on hourly rate. A lower rate on a vague scope is not cheaper. Compare written scopes, not numbers.

Comparing totals instead of scopes. Put the quotes side by side as lists: what each includes, what each excludes, how each handles change. The cheapest total often turns out to leave out design, payments or post-launch fixes that another quote included.

Not meeting the people who will do the work. The person who pitches is not always the person who builds.

No IP clause. Covered above, and worth repeating, because it is the one that costs most to fix later.

Accounts in someone else's name. Ask on the first call. It costs nothing to set up correctly at the start.

Assuming a developer also designs. Some do. Many do not, and will say so if you ask.

Forgetting the running costs. Hosting, the database, email sending, error tracking and any paid APIs add up to a monthly bill that starts on launch day.

Skipping employment status. If you hire an individual contractor through their own company, the off-payroll working rules may apply. GOV.UK says that when the client is a small private-sector business, the worker's intermediary decides the worker's employment status. Check the current rules for your situation.

Next step

Before you speak to anyone, get a rough number for your scope from the MVP cost calculator, so a quote that is far too high or far too low stands out. If you are still deciding whether to hire at all, build it yourself or hire covers when AI tools are enough.

If you would like to put these questions to me, book a call. I am one person, a senior product designer who also writes the code, so the answer to who designs it and who builds it is the same. The code, hosting and accounts are in your name from day one.