How to choose a web development partner?

What to look for in references?

Projects of similar size and type. A beautiful presentation site does not prove that the team can build a web application full of integrations. Ask what the difficulty of the project was and how they solved it. If you can, talk to one of their former clients. It also says a lot if a partner has been running its earlier work for years: clients stay when things go well.

What questions should you ask?

• Who actually works on the project, and with what experience?
• How does design work, and when will I see the first designs?
• How often will I see progress, and who is my contact?
• How do you test, and who is responsible for quality?
• What happens if a requirement changes along the way?
• Who will own the code, the designs and the documentation?
• What do you commit to after launch: operations, support, SLA?

What to watch for in proposals?

Compare what they include item by item: design, development, testing, content, migration, training, operations. If a proposal is much cheaper, it probably includes less. Notice whether the partner asks questions: one who asks nothing during discovery probably has not understood the task. A good partner also tells you if they think you do not need something, or if an off-the-shelf solution would do.

What are the warning signs?

• A proposal without discovery or questions.
• Vague scope and an "everything included" promise.
• The code and the access are not registered to you.
• No mention of operations or responsibility after launch.
• The salesperson says something different from the people who will work on the project.

How can you reduce the risk?

Start with a smaller, well-defined phase, such as scoping. In a few weeks you see how the team works, and at the end you get a specification and a fixed-price proposal that are yours even if you continue with someone else.