What to Prepare Before Your First Call With a Developer

First calls with a development company often go in circles, and it is usually not the fault of either side. You want to know what it costs; they cannot say until they understand what it is. Both leave with less than they hoped.

Half an hour of preparation fixes this. Here is what to have ready — useful whoever you end up talking to.

The problem, not the solution

The most valuable thing you can bring is a clear statement of what is broken. “We need an app” is a solution. “Our drivers call the office fourteen times a day to check the next stop” is a problem — and a good partner can tell you whether an app is the right answer or whether something simpler solves it.

Write two or three sentences describing what happens today and why it costs you. Do this even if you are certain about the solution.

Who uses it, and what they need to do

List the types of user — customers, staff, administrators, partners — and for each, the two or three things they must be able to do. Not a feature list. A short description of jobs.

This is the single most useful artefact you can produce, because it maps directly to how the work gets estimated. It also reveals scope you had not noticed: most projects discover the admin user halfway through the first call.

What it has to connect to

Name the systems already in use — accounting, CRM, ERP, payment processor, whatever runs the business today. For each, note whether you know if it has an API, and who inside your company controls access.

Integrations drive timelines more than features do. Arriving with this list can move an estimate from a range to something specific.

Your constraints, stated openly

Three things that people hold back and should not:

• Deadline, and why. A date tied to a trade show or a contract is a real constraint that shapes the plan. A date with no reason behind it is worth knowing too.
• Budget, even roughly. The fear is being charged whatever you name. The reality is that a range lets a competent partner tell you what is achievable within it, or tell you honestly that it is not — instead of you both spending three weeks arriving there.
• Who decides. If the answer involves a board, a partner or a parent company, say so early. It changes how the proposal should be written.

What you already have

Designs, wireframes, a previous version, a competitor you like, even a sketch on paper. Anything visual saves an enormous amount of describing. If a previous developer built something, say so and be candid about how it ended — it is not a judgment, it is context that changes the plan.

Questions to ask them

Bring these, and note whether the answers are specific:

• Who will actually write the code, and will they still be here in month four?
• How many hours a day do we overlap?
• Who owns the source code and the store accounts?
• How are changes to scope priced and approved?
• What would you talk us out of?

What a good first call produces

Not a price. It should produce a shared understanding of what is being built, a list of the unknowns that still need answering, and a clear next step with a date attached. If you get a firm number before anyone has mapped your integrations, treat it as a marketing number rather than a commitment.

When you are ready, tell us what you are building — we come back the same day. If you are still choosing between firms, how to choose an app development company covers what to compare.