Skip to content

6 min read

What to prepare before hiring a software team

The checklist a founder should have ready before the first call with any agency, the questions to ask them, and the answers that should end the conversation.

By Nexar Labs

  • Founders
  • Hiring
  • Process

You have a product idea, maybe a deck, and a shortlist of agencies or freelancers. The first calls are next week and you are not sure what they will ask, or what you should ask them. This post is the preparation we wish every founder had done before speaking to us, and the questions we would want asked of us in return.

None of it requires technical knowledge. It requires decisions, and most of them are yours to make.

Why preparation changes the price

An agency prices uncertainty. When the brief is vague, the estimate either carries a large contingency or it is optimistic and the overrun arrives later as change requests. Either way you pay for the gaps. A founder who turns up with the items below gets a tighter estimate, a shorter discovery phase and a team that starts on the product instead of on the questions.

The checklist

The problem, in one paragraph

Write it down. Not the product, the problem: who has it, how often, what they do about it today, and what it costs them. If you cannot write this paragraph, no agency can scope the work, and the ones that claim they can are guessing. A useful test is to read it to someone in the target group and watch whether they nod before you reach the end.

The first ten users, by name

Not a market size. Ten actual people or organisations who will use the first version, and how you will reach them. If you know their names, the team can design for them. If you do not, the first piece of work is not software.

What "done" looks like for the first version

One sentence per outcome, phrased so that someone could check it. "A coach can publish next week's sessions and a member can book one from their phone" can be checked. "A modern booking experience" cannot. Three to six of these sentences are enough for a first version; if you have twenty, you are describing version three.

What already exists

Make a list, with logins where relevant:

ItemHave it?Where / who controls it
Domain nameRegistrar and the account it sits in
Designs, wireframes or a brand guideFigma file, PDF, or "in my head"
Existing code or a prototypeRepository, and who wrote it
Data (spreadsheets, an old system, customer lists)Format and rough size
Accounts: cloud, app stores, email provider, payment processorWho is the owner
Legal: company registration, privacy policy, terms

Half of these will be empty. That is fine. The agency needs to know which half, because "we have a Stripe account" and "we need to set up payments from scratch" are different weeks of work.

A budget range, and why they ask for it

Founders often withhold the budget in the hope of a lower quote. It rarely works that way. Software can be built at almost any budget; what changes is how much of the scope survives. A team given "somewhere between X and Y" can propose the version that fits, and tell you honestly what falls outside it. A team given nothing will either propose their default engagement or pad the number.

You do not need a precise figure. You need a floor you can commit to and a ceiling you would not cross, and you need to know whether that money has to cover running costs and a launch as well as the build. [NEEDS: a sentence on the smallest engagement Nexar Labs takes on, so readers can self-select.]

Who decides, and how often they are available

Name the person who can say yes to a design, a scope change and an invoice. If that is you, decide how many hours a week you can give to reviews and questions. A team that has to wait four days for every answer will drift, and the drift is invisible until the demo. Two short sessions a week is usually enough; zero is not.

Anything with a hard date

A trade show, a regulatory deadline, a school term, a funding milestone. Say so on the first call. Dates change the shape of the plan more than any feature does.

What to ask the agency

The pitch will tell you what the agency is proud of. These questions tell you what working with them is like.

Who actually writes the code? Ask for names and whether they are employees, contractors or a subcontracted studio. Ask who you will speak to each week and whether that person is also building. A layer of account management between you and the engineers is not automatically bad, but you should know it is there and what it costs.

Who owns the repository, the cloud account and the domain? The answer should be: you do, from day one, in accounts registered to your company. If the agency proposes to host the code or the infrastructure in their accounts "for convenience", ask what happens to it if the relationship ends badly. Convenience for them is a hold over you later.

What does a week look like? How work is planned, when you see progress, how a change of mind is handled. You are listening for a rhythm: something demonstrable at a regular interval, and a clear way to say "not that, this".

What happens after launch? Who monitors it, who is on call, how updates get made, what the monthly cost is. An agency that has not thought about the first three months after launch has not launched much. There is a separate post on this.

What would you cut? Give them your list of outcomes and ask what they would leave out of the first version. A good team has opinions here and can explain the trade-off. A team that agrees to everything is not planning to deliver everything.

Can I speak to a previous client? Ideally one whose project is a year old, so you hear about what happened after the invoice was paid.

Red flags

  • A fixed price on the first call, before anyone has asked you a hard question.
  • No questions about your users, only about your features.
  • Reluctance to put the repository and cloud accounts in your name.
  • An estimate that does not say what is excluded.
  • "We can do anything" in answer to "what would you cut".
  • A contract that transfers intellectual property only on final payment, with no definition of what final means.
  • Pressure to sign before the end of the week.

None of these alone means walk away. Two or three together usually do.

What good looks like from the other side

For what it is worth, here is what we look for on a first call: a founder who can describe the problem without describing the app, who knows who the first users are, who has a budget range and a date, and who wants to own the accounts. When those are in place, the first call is about the product. When they are not, the first call is about finding them, and that is fine too; it just comes first.

What to do next

Fill in the checklist above, even roughly, before your next call. If you would like to run it past us, send the paragraph about the problem and your list of outcomes through the contact form; we reply within two working days with our questions, or with a suggested first step if the fit is clear.