← Client guides

Five red flags
before you hire
a dev shop.

Before you agree to a build, find out who’s doing the work, how you’ll review it, and what happens after handoff.

Look inside the proposalFive sheets in a project proposal: team, access, reviews, scope and handoff. Each needs a clear answer. TEAMACCESSREVIEWSSCOPEHANDOFF
Fig. 07Look inside the proposal
05

You can’t meet the people building it.

A good sales conversation tells you what a studio can offer. It doesn’t tell you who will make the decisions when the work gets difficult.

Ask this

Who will actually build this, and can we speak with them before we start?

A useful answer includes

The people doing the work, the person responsible for delivery, and how you’ll get a technical question answered.

A studio can have a sales team. You still need a route to the people building your project.

04

Your business runs on accounts you can’t access.

The site goes live. Then you find out the domain, hosting and source code are all behind somebody else’s login. Moving on becomes a negotiation.

Ask this

Whose accounts will we use, what access will we have, and what happens if we change providers?

A useful answer includes

A written plan for the domain, source repository, hosting, data and billing. It should say who controls each one and what can be transferred or exported.

Managed hosting can be a sensible choice. The terms and exit route should be clear before you agree.

03

Nothing to try until launch.

A progress update can sound reassuring while hiding a misunderstanding. Finding it at launch is an expensive way to learn you asked for different things.

Ask this

When will we try a working version, using examples from our own work?

A useful answer includes

Agreed review points, access to working versions, and a way to record feedback. You should know how the team will check that the result meets the brief.

Early work can be rough. It should still let you check the part that matters.

02

A firm quote before a single question.

“We can do that” is easy to say. The awkward details are usually in the systems it needs to connect to, the data it will use and the people who need it to work.

Ask this

What does this price include, what are you assuming, and what would change the scope?

A useful answer includes

An agreed outcome, deliverables, assumptions, exclusions and a process for changes. If something important is unknown, the team should say how they’ll find out.

A ballpark price is useful. A fixed commitment needs enough detail to stand behind it.

01

The handoff is a zip file.

Having the files is a start. Someone still needs to know how to run the system, change it, recover it and work out why it stopped.

Ask this

What will another developer need to run, maintain and change this after handoff?

A useful answer includes

An agreed list of files, access, setup and operating notes, dependencies and ownership terms. Ongoing support, if needed, should have its own scope.

A small project can have short documentation. It still needs the information required to use it.

Keep this for the first call

Five questions.
Space for real answers.

Tick a question when you have a clear answer. Print a copy or take the questions with you.

Questions to cover with a software team

6 Watt Labs · 6wlab.com/red-flags · @_6WLab

Ask us the same questions.

Tell us what you’re planning. We’ll work through the scope, review points and handoff with you.

How we work
Tell us about your project

Your questions

Select the text below to copy it.