The Proposal Looked Perfect. The Project Was a Disaster.

You have seen this pattern before — or lived it. A polished proposal lands in your inbox. The agency promises fast timelines, impressive deliverables, and a price that seems almost too reasonable. Six months later, you are staring at a half-built platform, a pile of invoices that somehow doubled the original quote, and a codebase that the next developer describes as 'interesting' in a tone that means the opposite.

The painful truth: most failed agency engagements are not caused by incompetent people. They are caused by misaligned expectations that were never surfaced before the contract was signed. The vendor had every incentive to say yes to everything during the sales process, and no mechanism to slow down and ask harder questions.

If you are evaluating a development partner right now — whether for infrastructure work, a web build, an automation project, or a brand overhaul — these seven questions will help you separate grounded expertise from polished pitches. They are designed to expose the gaps that overpromising vendors hope you never notice.

1. What Does Your Discovery Process Look Like Before Any Work Begins?

This is the most revealing question you can ask, and it should come first. A vendor who jumps straight to wireframes, timelines, or tooling recommendations without understanding your goals, your current environment, and your constraints is already cutting corners.

What you want to hear: a description of deliberate soil work — mapping your business goals, technical landscape, audience, and competitive environment before a single line of code is written or a single campaign is launched. Discovery should feel like architecture, not a checkbox.

What should concern you: vague answers like 'we do a kickoff call' or 'we will figure it out as we go.' If the vendor cannot describe a structured process for understanding your world first, they are designing solutions for a problem they have not yet defined.

Why This Matters

Every engagement should start underground. The foundational work — aligning on what success actually looks like, identifying risks early, and designing systems that are scalable from day one — is where real projects either take root or begin to rot. A vendor who treats discovery as overhead instead of architecture is building on sand.

2. Can You Walk Me Through a Project That Did Not Go Well — and What You Changed?

Any agency with real experience has had projects that went sideways. The question is not whether it happened. The question is whether they learned from it and changed how they operate.

What you want to hear: a specific, honest account. Maybe a scope issue was not caught early enough. Maybe they did not have the right observability in place and a deployment broke in production. The details matter less than the transparency and the systemic change that followed.

What should concern you: a claim that every project has gone perfectly. That is not credibility — it is a warning sign. Either the vendor has not done enough work to encounter real complexity, or they are not being honest about the complexity they have encountered.

The Deeper Signal

This question tests for something more important than technical skill. It tests for the kind of grounded, purposeful self-awareness that separates a development partner from a vendor who just wants the contract signed. The vendors who have done the hardest work are usually the most willing to talk about what they have learned from it.

3. Who Exactly Will Be Doing the Work — and Will I Have Access to Them?

One of the most common agency red flags is the bait-and-switch on personnel. A senior architect sells you on the engagement, then disappears after the kickoff call. The actual work gets handed to a junior team you have never met, sometimes offshore, sometimes subcontracted, sometimes both.

What you want to hear: clear, direct answers about who will be hands-on. Names, roles, and experience levels. If subcontractors are involved, that should be disclosed upfront, not discovered three months in when the code quality shifts.

What should concern you: evasive answers about 'the team' without specifics. Reluctance to let you speak directly with the people building your system. Any structure where the person you are talking to during sales will not be involved during delivery.

A Practical Test

Ask to meet the lead engineer or designer before you sign. A vendor who is confident in their team will welcome this. A vendor who resists it is telling you something important about the gap between their sales process and their delivery process.

4. How Do You Handle Scope Changes After the Contract Is Signed?

Scope will change. Every meaningful project encounters new information, shifting priorities, or technical realities that were not visible during the initial planning phase. The question is not whether scope changes will happen — it is whether the vendor has a mature, transparent process for handling them.

What you want to hear: a defined change-order process. Clear communication about what is in scope, what constitutes a change, and how changes affect timeline and budget. The best partners treat scope management as a collaborative conversation, not a contractual weapon.

What should concern you: a vendor who says 'we are flexible' without any structure behind that flexibility. Equally concerning is a vendor whose contract language is so rigid that any deviation triggers expensive renegotiation. Both extremes signal a lack of experience with real-world project dynamics.

The Budget Question Behind the Budget Question

When you are evaluating a vendor, ask them to describe the last time a project went over budget. Listen for whether the overrun was communicated proactively or discovered after the fact. A partner who surfaces cost implications early — even when that conversation is uncomfortable — is a partner who respects your resources.

5. What Will I Actually Own When This Engagement Ends?

This question exposes one of the most damaging patterns in the agency world: building systems that only the agency can maintain. Whether it is proprietary frameworks, undocumented code, locked hosting environments, or content strategies that require ongoing agency involvement to function, the result is the same — you are dependent on the vendor long after the project should have been handed off.

What you want to hear: full ownership of code, assets, infrastructure, and documentation. A commitment to building on open, well-documented standards. Infrastructure-as-code practices that mean another qualified engineer could pick up where they left off. Content and brand assets delivered in formats you control.

What should concern you: any hesitation about code ownership. Proprietary tools or platforms that lock you in. A lack of documentation strategy. If the vendor's business model depends on you being unable to leave, their incentives are misaligned with yours from day one.

Documentation as a Litmus Test

Ask specifically about documentation practices. How are architectural decisions recorded? Where do runbooks live? Is there a handoff process? The quality of a vendor's documentation is one of the most reliable indicators of whether they are building something designed to last beyond the engagement — or building something designed to keep you coming back.

6. How Do You Measure Success — and When Do You Measure It?

A surprising number of agency engagements end without a clear answer to whether the project actually worked. The deliverables were delivered. The invoices were paid. But did the system perform? Did the infrastructure hold under load? Did the content strategy move the metrics that mattered?

What you want to hear: specific, measurable outcomes defined during discovery — not after launch. Observability built into the system architecture. A plan for measuring results that extends beyond week one. The fruit of good engineering and design reveals itself over months, not in a launch-day demo.

What should concern you: success defined only in terms of deliverables ('we will build you a website') rather than outcomes ('your deployment pipeline will go from 45 minutes to under 5'). Vague references to 'ongoing optimization' without defined benchmarks or review cadences.

The Compound Effect

The best technical work compounds. Infrastructure designed with observability and continuous improvement built in does not just work on day one — it gets more efficient, more reliable, and more valuable over time. Ask your vendor how their work is designed to flourish in month twelve, not just survive until launch.

7. Why Should We Not Hire You?

This is the question that makes overpromising vendors visibly uncomfortable — and makes honest ones lean forward.

Every firm has limits. Every team has areas where they are not the right fit. A development partner with fifteen years of infrastructure experience may not be the right choice for a complex native mobile app. A content team that excels at faceless-first brand building may not be the right choice for a live-event video production.

What you want to hear: a clear, specific articulation of where their expertise ends. Maybe even a recommendation for someone who would be a better fit for that particular need. This kind of honesty is rare in a sales conversation, which is exactly why it is so valuable.

What should concern you: a vendor who claims they can do everything. No team is the right fit for every project, and a vendor who cannot or will not define their boundaries is almost certainly overextending into areas where they lack depth.

What This Question Really Tests

At its core, this question tests whether the vendor is purpose-driven or revenue-driven. A firm rooted in something deeper than the next contract will tell you the truth about fit — even when the truth means walking away from a deal. That kind of integrity is not just admirable. It is the single most reliable predictor of a good engagement.

Beyond the Checklist: What You Are Really Looking For

These seven questions are a vendor evaluation checklist, but they are really testing for one thing: alignment. The right development partner is not the one with the most impressive portfolio or the lowest quote. It is the one whose process, values, and incentives are genuinely integrated with your goals.

When you find that alignment, the relationship shifts. You stop managing a vendor and start collaborating with a partner. Decisions get made faster because trust is already established. The work gets better because both sides are invested in outcomes, not just outputs.

That kind of partnership does not start with a proposal. It starts with a conversation — an honest assessment of where you are, where you want to go, and whether there is a real fit.

Start With the Right Conversation

At Figtree Development, every engagement begins with discovery — not a sales pitch. We map your goals, your current landscape, and your constraints before we architect anything. That process is how we make sure the foundation is right before we build on it.

If you have been burned before and you are cautious about the next partner you choose, that caution is an asset, not a liability. Bring your hardest questions. We would rather earn your trust through honest answers than win your business with a polished deck.

Book a free 20-minute discovery call — no pitch, no pressure, just a grounded conversation about what you are building and whether we are the right team to help you build it.