Guide
How to choose a developer for the first version of your product: the questions worth asking
Choosing who builds the first version has bigger consequences than choosing the technology. It decides whether in three months you have a product you can sell and take over, or mock-ups and code you do not have the password to. Below is what to ask, and what should worry you.
Who can build a first version
An agency or software house. A team with a project manager, a designer and several developers. Good when you have a large budget and want one partner for years. The risk: a first version is often too small for them, so the scope grows, and the person who talks to you is often not the one writing the code.
A freelancer. One person, lower cost, direct contact. Good when the product is small and the freelancer has built similar things. The risk: when they are busy or disappear, the work stops, and undocumented code is hard to hand on.
One person in the architect’s role, with a team picked per task. This is how I work. You talk to the person who designs the product and writes its core. With a larger scope, people I trust join for specific tasks, and responsibility for the whole stays with me. The risk, as with any small firm: ask what happens when I am unavailable. The answer is documentation and code in a state someone else can pick up. The scope of that work is described under websites and applications.
Your own team. You hire developers full time. Good when the product is the heart of the company and will be developed for years. The risk at the start: hiring takes months, and you need the first version now. A common scenario is building the first version externally and handing it to your own team once the product earns. You get the first version together with the code and credentials, so your own team can take it over without me.
Questions worth asking everyone
- Who will write the code? You want to know the person, not the company logo. If the answer is “we will assign a team after the contract is signed”, you do not know who you are choosing.
- When do the code and credentials become mine? The right answer: with each stage you pay for, not only at the end. Servers and domain on your contract. Not “we will hand over at the end of the project”.
- Can the product be taken over without you? Ask for a sample of documentation from a previous project. A product another developer cannot take over is worth as much as its author’s availability.
- How does billing work, and what if the money runs out? Payment per stage after acceptance means you keep a working part. Payment up front for the whole means you keep whatever happened to be in progress.
- What do I get after the first month? “Mock-ups and a requirements document” is not enough. After a month there should usually be something you can click through and show.
- What does care after launch look like? Who picks up the phone when payments stop working on a Saturday, and what it costs. Better to know before launch.
- Will you sign a non-disclosure agreement? Before the detailed conversation, if you want one. A refusal or a delay is a signal.
Warning signs
A quote without a conversation about the product. A price given after one email means the developer has priced something they imagined. A real quote needs a written scope and the questions that come out of it.
Payment up front for the whole. Then all the risk sits with you. A deposit at the start can be justified, but most of the money should follow accepted work.
“We will build everything at once.” A developer who does not try to shrink the scope of the first version is building for themselves, not for your sales. A good one takes features out on the first call.
No access to the code during the build. If you see the code “at the end”, you do not know what is being made and cannot walk away halfway with what you paid for.
Technology instead of product. A conversation full of tool names and empty of questions about the customer and what they pay for usually ends in a product that is technically sound and unsellable.
No examples of similar products. Building from scratch differs from adding features to an existing system. Ask for a product the developer built from the first line of code to the start of sales, and ask to click through it.
How to compare offers
Compare only once every developer has received the same written scope of the first version. Otherwise one offer includes payments and a panel, another does not, and the prices look as if they refer to the same thing. How to prepare such a description before asking for quotes is in the guide on preparing for a quote.
What belongs in the scope is on the page what the first version must have, and what drives the price is on the page how much a first version costs. The whole build process is on the main page of the guide.
Describe in the form below what your product should do. I will get back to you and answer each of the questions above in writing.
Questions and answers
Can one person build a whole product?
A first version, yes. Who answers for the result matters more than the head count.
Does a cheaper developer mean a worse product?
Not always, but a low price without a conversation about the product usually means the developer does not yet know what they are building. Compare offers only once each one describes the same written scope. Otherwise you are comparing numbers that refer to different things.
Will you sign a non-disclosure agreement before we talk?
Yes, if you want one, before we discuss the details of the product. Several of my projects are under such agreements, which is why I describe them without names.
Contact
Describe your product and I will answer every one of these questions in writing
You do not need a specification. Describe how the work looks today and what should change. We will write the scope together.