Most software teams look good in a first meeting. The slides are polished, the examples are impressive, and everyone is friendly. What you cannot see yet is how the work actually gets done, and that is where projects succeed or fail.
These eight questions are meant for an intro call. For each one, here is what a good answer sounds like and what should make you pause. Write the answers down and compare them across the teams you talk to.
#Who does the work, and who you talk to
1. Who will actually write the software, and where are they?
A good answer names the people or roles, says whether they are employees or contractors, and says where they work and in what time zones. Remote is fine, and so is a mix of locations. What matters is that you know who they are and when you can reach them.
A worrying answer is vague (“our global team”) or reveals that the person selling the project will not be the person building it, and nobody will tell you who is.
2. Who will I talk to day to day?
A good answer is one named person who knows your project and can answer technical questions without checking with someone else. Ask whether that person will still be on the project in three months.
Be cautious if every question goes through an account manager who relays messages. That slows decisions and hides problems until they are expensive.
#How scope and price are agreed
3. How are scope and price agreed in writing?
A good answer describes a written scope: what is included, what is not, what you will receive, and what it costs. Ask to see a sample scope document with the client details removed. You should be able to read it and tell what you are buying.
Worry if the price comes from a conversation and a single number, or if the scope is “to be defined as we go.” Our own guide to scoping a custom build lists what a written scope should cover.
4. How are changes handled once work has started?
Changes will happen. You will learn things halfway through that you could not have known at the start. A good answer explains the process: you describe the change, the team tells you what it affects (cost, order of work, anything that gets pushed back), and you approve it before work begins.
A worrying answer is “we are flexible, don’t worry about it.” Flexibility without a process usually becomes an argument over the invoice later. Equally, “any change needs a new contract” with no middle path is a sign of rigidity.
#What you see and what comes after
5. What will I see before launch?
A good answer is that you will use working software while it is being built, not only a demo at the end. Ask how often and in what form: a link you can click, a test environment, a recorded walkthrough. Ask what you are expected to review and how quickly feedback is needed.
Be cautious if the first time you see anything real is launch day. By then, a misunderstanding from week one is baked into everything.
6. What happens after launch?
Software needs attention after it goes live: bugs appear, dependencies get updated, and your business changes. A good answer says who monitors the system, how you report a problem, how fast someone responds, and what is covered by a support arrangement versus billed separately. It should also say what documentation and training you get at handover.
Worry if support is “we’ll figure it out” or if the answer is only about the build.
#Data and access
7. How do you handle my data and access to my accounts?
A good answer is specific. Accounts for hosting, domains, and third-party services are registered to your business, with the team added as users. Access is limited to what the work needs, passwords go through a password manager rather than email, and access is removed when the engagement ends. Ask where your data will be stored and who can see it.
Worry if the team wants to set everything up under its own accounts “to make it easier,” or cannot explain how it handles your data.
#Asking for a reference
8. Can I speak to a past client?
A good answer is yes, with a name and an introduction. Some work is under confidentiality, so a team may offer a conversation rather than a published case study. Ask the client what went wrong and how the team handled it, because every project has a rough patch.
If a team cannot connect you with anyone at all, or only offers testimonials it wrote itself, treat that as information.
#Using the answers
Put the answers side by side. Clear, specific, slightly boring answers beat polished ones. The team that says “here is exactly how a change request works” is usually safer than the team that promises nothing will go wrong.
If you want to hear how we would answer these, book a 30-minute call. It is with an engineer, in English or Español, and you are welcome to bring this list.
