ViewBinary Digital ViewBinary Digital

Checklist for briefing a team

Questions to ask before a project starts

The right questions, asked early, save a lot of trouble later. This is a practical checklist for anyone about to brief an agency or freelancer on a website or mobile app project. Use it as a filter, not a script.

Read the project planning guide Jump to the checklist
Two hands sketching an early app screen layout on paper at a dim work table

Ten groups of questions, plus the warning signs worth a second conversation

How to use this checklist

A briefing conversation usually happens in one sitting, and it is easy to leave with a good feeling and no clear answers. The questions below are grouped so you can work through them in order, or pull out the two or three that matter most for your project. There are no trick questions here. What you are listening for is a specific answer, a named person, and a willingness to talk about limits.

Ask them in a call, in writing, or in a short proposal review. Written answers are easier to compare if you are speaking to more than one team. If a team answers vaguely on scope or ownership, ask again with a concrete example from your own product, and note what changes in the second answer.

Before you talk

Write down what the product must do on day one, and what can wait. That single note makes most answers below easy to judge.

During the talk

Ask who does the work and how decisions get approved. Names and steps are the useful part, not the portfolio tour.

After the talk

Ask for the scope, support terms and ownership in writing before anything is signed.

Questions about the team

Who will actually do the work?

Will the same people be on the project from start to finish? How many projects are they running at once? Small teams can be excellent, but you want to know who is responsible and how reachable they are.

Ask for the names of the people who will write the code and design the screens, not just the person who sold the project. Then ask what happens when one of them is unavailable, and who answers your messages on a normal week.

Questions about process

How does the project move from idea to launch?

What happens at each stage, and what do you need to approve? A team that cannot describe its process clearly is a risk, however good their portfolio looks.

Discovery

What they read, ask and check before proposing a build. Ask what they need from you to finish this stage.

Design

How screens are shown to you, how many review rounds are included, and who signs off.

Build

Where you can see progress, how often you get a working version, and how feedback is tracked.

Launch

What must be finished before release, what is checked after, and who is on call that week.

Design, development and the handoff between them

Do they handle both design and development, or is it split? If split, how does feedback move between the two? Design and development handed to different teams is workable, but it needs a clear handoff or things fall between the gaps.

Ask who reviews a finished screen against the built version, and how a change requested late in the build is priced and scheduled. On mobile apps, also ask how interface and backend work is coordinated, since API integration usually sits between the two.

A hand comparing a printed screen layout with an unlit phone on a dark table

Questions about the stack

Why did they choose these tools?

Can they support them after launch? You do not need to judge the tools yourself. You need to hear a reason that connects to your product's requirements, not to what is fashionable.

Frontend framework

What does the choice mean for page speed on a mid-range phone, and who on the team has shipped it before? A framework used on three similar projects is a different answer from one they read about last month.

Backend and database

How will data be stored, and what happens when traffic grows or the schema needs to change? Ask whether the setup suits a small first release or assumes scale you may not reach.

API integration

Which outside services will the product depend on, and what happens if one changes its terms or its pricing? Ask who maintains those connections and how failures are handled.

Native or cross-platform

For mobile app development, ask why one approach suits your case. Device features, release cycles and the size of the team all shape a sensible answer here.

Read the tools and stack guide

Scope, the smallest useful version, and what gets cut

What is the smallest version that delivers value? What would they cut first if the budget shrank? What would they add first if it grew? This tells you whether they think in terms of your priorities or their own.

A useful answer names features, not principles. If the budget dropped by a third, which screens disappear and which stay? If it grew, what would they build next and why? Teams that answer this quickly usually have a working idea of the product already.

Timelines and what usually causes delays

What has to be true for each stage to finish on time? What usually causes delays on their projects? Anyone who says delays never happen is either new or not being straight with you.

Answer to listen for

A named dependency on your side, such as content, approvals or account access, with a date attached to each one.

Answer to treat as a warning

A fixed end date with no mention of what could move it, or a schedule that assumes everything arrives on the first request.

Common real cause

Late copy, late feedback, or a change requested after a screen was already built. Ask how each is handled in practice.

Useful detail

Whether the team shares a plan you can see, and who updates it when something slips.

Support after launch

What happens after launch? Who fixes bugs, how are updates requested, and what is covered? Support terms should be written down before the project ends.

Ask how a problem is reported, how quickly it gets a reply, and whether small changes are included in a monthly arrangement or quoted one by one. Both models work; the problem is finding out which one you agreed to after you need it.

Check quality and support criteria
A quiet office corner at night after a product release, desk lamp on, screens dark

Ownership, cost and what changes the price

Ownership

Who owns the code and the design files? Do you get full access at the end? Can you move to another team later if you want to? Ownership should be clear from the start.

Ask where the code and design files live, which accounts you hold in your own name, and what is handed over on the final day. If a team keeps everything in their own accounts, ask how a future developer would take over.

Cost

How is the project priced, and what changes the price? What is excluded? What happens if scope changes mid-project? Vague answers here turn into difficult conversations later.

Ask for the exclusions in writing: hosting, app store fees, third-party services, content entry and testing on real devices are common ones. Then ask how a mid-project change is quoted, approved and added to the schedule.

Warning signs worth a second conversation

No discovery phase. No written scope. No named contact. No support terms. Pressure to sign quickly. Each of these is common enough to watch for, and any one of them is worth a second conversation before you commit.

  • No discovery phase

    A proposal appears before anyone has asked what the product has to do. Questions about your users and your existing systems should come first.

  • No written scope

    Features described in a call but never listed. Without a written list, there is no shared definition of finished.

  • No named contact

    Messages go to a general address and replies arrive from different people. Ask who is accountable for your project week to week.

  • No support terms

    Nothing said about the weeks after launch. Ask for the support arrangement in writing before the final invoice, not after.

  • Pressure to sign quickly

    A deadline for the decision that comes from the seller, not from your business. A reasonable team can hold a proposal open while you read it.

Short answers to questions we get about this checklist

Do I need to ask all of these before hiring anyone?

No. Start with the questions about the team, scope and ownership, because they decide whether the project can be delivered at all. The rest can follow once you are talking seriously with one or two teams.

How do I compare answers from two different teams?

Ask both for written answers to the same list, then compare the level of detail rather than the tone. A team that names people, stages and exclusions is easier to hold to a plan later than one that answers in general terms.

What if I am working with a freelancer rather than an agency?

The same questions apply. A solo developer will answer the team question differently, but scope, ownership, support and pricing should still be written down. Ask what happens if they are ill or take a holiday during your build.

Should I decide on the technology stack myself?

Usually not. Your job is to state the requirements and ask why a given choice fits them. If the reason refers only to what is currently popular, ask for a second reason connected to your product, your team or your timeline.

Can I use this list for a mobile app as well as a website?

Yes. Add two things for a mobile app: how the build will be tested on real devices, and who handles the store submission and the review process afterwards.

Where to go next

If you want to keep reading before you talk to anyone, the project planning guide covers how to structure a brief and what to prepare. The quality and support page explains what to check once a build is under way. If you have a question about your own project, send it over and we will answer it plainly.