Seven questions to ask a development partner before you sign

Most founders choose a technical partner the way they choose a restaurant: a good conversation, a nice portfolio, a gut feeling. That works fine for dinner. For a decision that will shape your product for the next year, it is not enough.

These seven questions are designed to surface what a pitch deck does not. Each one has a specific failure mode it is built to catch.

1. Who owns the code, and from what date?

This is the question most founders forget, and the one hardest to fix later.

What you are checking for: whether intellectual property transfers to you incrementally, or only after final payment, or not explicitly at all.

A strong answer: "You own everything from the first commit. It's in the contract as a standing clause, not tied to final payment." Some serious partners still gate full IP transfer behind final payment as standard commercial protection, and that is reasonable, but they should be explicit about it rather than vague.

The red flag: hesitation, or an answer that mentions "after the engagement concludes" without a specific trigger. If a partner cannot state plainly when you become the legal owner of the work, assume the least favorable interpretation is the true one.

2. What exactly is not included in this price?

Every quote implies a boundary. The question is whether the other side has thought about where it is.

What you are checking for: whether the exclusions list is specific or generic.

A strong answer is long and dull: no third-party API costs, no content writing, no data migration from your old system, support ends at day 30, native mobile apps are a separate quote. Specificity here is a good sign, not a bad one.

The red flag: "Don't worry, we'll cover whatever comes up." This sounds generous. It means the boundary is undefined, and undefined boundaries get redrawn in the partner's favor once work has started and switching costs are on your side.

3. What was your last project that didn't go well, and why?

Every agency has one. The question is not whether something went wrong, it is whether they can describe it honestly.

What you are checking for: self-awareness and a specific, checkable cause.

A strong answer names a concrete failure: a scope that was underestimated because a payment integration turned out to be more complex than expected, and what changed in their process afterward. This is a partner who has actually shipped enough to have scar tissue.

The red flag: "We don't really have failures, we always deliver." Nobody has a 100% record. This answer means either they are not being honest with you now, on the call, before you have even signed anything, or they don't consider a bad outcome for the client a failure worth naming.

4. What will I see every week while this is being built?

This question tests whether you are buying a process or a promise.

What you are checking for: a concrete, recurring artifact, not a general commitment to communication.

A strong answer: a working demo every Thursday, a written sprint note every Friday, a staging environment you can access anytime. These are things that exist whether or not anyone remembers to send an update.

The red flag: "We'll keep you in the loop" or "however you prefer." Vague cadence becomes no cadence within three weeks, and by week six you are the one chasing status updates instead of receiving them.

5. Who exactly will be working on this, and how much of their time?

Sales calls are conducted by the most senior, most persuasive person at the company. That person is frequently not who writes your code.

What you are checking for: named individuals and real percentages, not job titles.

A strong answer: "A tech lead at 40%, two engineers at 100%, a designer at 30%, and I'll be doing sprint planning at about 15%." Percentages that don't add up to a sensible team, or introduce more people than the budget can plausibly support, are worth challenging.

The red flag: the team is described only by role, with no names, and nobody can tell you who your day-to-day contact will be. You are being sold a company's reputation while your project gets whichever engineers are free that week.

6. What would you cut if my budget were 30% smaller?

This is the fastest way to find out whether the person across the table has actually thought about your product, or is reciting a standard package.

What you are checking for: an immediate, specific answer.

A strong answer comes within seconds, because a partner who understands your product already knows which features are load-bearing and which are nice-to-have. "I'd drop the admin analytics dashboard and the second language, keep everything in the core transaction flow."

The red flag: a long pause, followed by "everything is important" or a request to think about it and get back to you. If they need three days to figure out what matters most in your product, they have not internalized it yet, and that will show up in every scoping decision from here on.

7. What happens on the day after launch?

Launch day gets discussed in every pitch. The day after rarely does, and it is where the real difference between a vendor and a partner shows up.

What you are checking for: a specific plan, not a vague assurance of "ongoing support."

A strong answer names a defined window, a defined scope for what is covered inside it, and an explicit next step: 30 days of bug fixes included, a monitoring dashboard set up before handover, and a proposed retainer or support arrangement for anything beyond that, priced now rather than negotiated later under pressure.

The red flag: "We're always available if you need us." This is not a plan, it is a sentence designed to end the conversation. Available at what price, at what response time, for what scope of work? If none of that is answered before signature, it will be answered later, on their terms, when you have no leverage left.

How to use this in practice

Do not send these as a written questionnaire. Ask them on a call and listen to how quickly and specifically the other person answers, not just what they say. Hesitation on question one or four is more informative than the words used to cover it.

If you only have time for two, ask 1 and 6. Ownership tells you what you are actually buying. The budget question tells you whether the person has genuinely engaged with your product or is running a script.

Here is how we would answer all seven, in writing, before you ask: our sample Blueprint shows exactly what a real scoping process produces, and our pricing lists what is and is not included at every tier. If you'd rather just ask us directly, get in touch.