# How to evaluate a technical partner before you sign

The proposals you’re comparing were written to look alike. These are the questions I’d ask before signing with any software vendor — including us.

Signed: José Ribeiro, partner at Bleu

## Why every proposal looks the same

Over the past few weeks I studied how more than a hundred software houses and consultancies present themselves: website, proposal, ads, LinkedIn. Almost all of them say the same thing. Senior team. Agile. AI. Hundreds of projects delivered.

That’s not laziness: a specific promise can be held against you later, so generic is the safe choice. That’s why three proposals on your desk read like the same company with three different logos. When everything looks alike, price becomes the only visible criterion left. And price is the worst way to choose who touches the system your operation runs on.

What follows is the list I’d use in your place. Use it against any vendor, including us.

## The 12 questions

### About the people

**1. Who will write the code?** Ask to meet the project’s engineers before signing. The sales team you have already met. If the company won’t allow it, the proposal team and the delivery team are different things.

**2. How many of the proposed team are actually senior?** “Senior team” describes the proposal; the list of names describes the delivery. Ask name by name, and ask whether those people are still on the project after month three.

**3. Who answers when it goes wrong?** A name, not a job title. Software projects go wrong at some point. What separates vendors is who shows up when it happens.

### About the proof

**4. Of the “500 projects delivered,” which three look like mine?** Project counters are the market norm precisely because nobody checks them. Ask for three cases similar to yours, with names and results, and ask what can be verified.

**5. Can I talk to a client?** A person, with a phone number — the logo wall doesn’t count. A logo on the website says there was a contract; whether the project went well, only the client can say.

**6. Can I see a real repository?** An open source project, or a real repo with the client’s permission. Code says what the proposal hides: how the team names things, tests, documents, and decides.

**7. Show me a hard decision you made.** A real decision document, anonymized if needed. A team that decides well can show how it decided. If there is nothing on record, the decisions are being improvised.

### About the money

**8. How do you price scope changes?** In fixed-scope contracts the margin lives in the change order: the initial price wins the bid, the changes pay for the project. If the answer to this question is vague, you’ve found the business model.

**9. What would you refuse to build?** A vendor that never refuses anything has no judgment, and will take your request even when the request is wrong. Ask for examples of what they have refused.

**10. What part of this scope should I NOT buy right now?** The average proposal maximizes scope. A real partner can point at what can wait, even when it costs them money.

### About the exit

**11. If I leave in six months, what do I take with me?** Code ownership, infrastructure access, documentation, whose name the accounts are in. The cost of leaving is set on signing day, not on leaving day.

**12. Who keeps the knowledge when the contract ends?** If the answer depends on one person staying, you’re renting memory. Ask how knowledge becomes things that stay: code, documents, process.

## Red flags, and the mechanics behind them

- **Generic counters.** “+500 projects,” “+300 clients.” The rounder the number, the less auditable. Delivering five hundred projects proves the company delivers in volume. It says nothing about yours.
- **A logo wall with no named outcomes.** A logo says there was a contract. What was delivered, whether it worked, and whether the client would come back are all missing.
- **Invisible pricing.** In the study I ran, almost no firm publishes a price or a range. Hidden pricing lets the proposal fit whatever number the conversation will bear.
- **The identical packaged offer.** Assessment, then pilot, then scale — the same design shows up vendor after vendor, almost word for word. When the offer is identical, the only variable is who executes. Which is exactly what the proposal doesn’t let you evaluate.
- **The owner disappears after the sale.** The person who courts you is a partner; the person who runs your project, you’ve never met. Question 1 exists because of this.
- **Your vendor can be acquired mid-contract.** The consultancy market is consolidating: good boutiques become divisions of large firms, and the team that served you becomes something else. Ask whether the partners intend to stay owners. Nobody can promise the future, but the reaction to the question tells you plenty.

## How we answer our own list

It would be easy to end the piece here and imply that Bleu passes every question. Let me answer the ones that most separate a vendor from a partner.

- **Who writes the code:** the people you meet before signing. We’re a small team of seniors; there is no “proposal team” separate from the delivery team.
- **Proof:** our cases have names, context and results — and clients who answer the phone. Our longest partnership is past three years, and the piece about it is published on our blog, including what worked and what it demanded.
- **Refusing requests:** questioning the request before executing it is part of how we work. More than once the project we delivered was smaller than the one requested — it’s described in our cases.
- **Scope changes:** an open conversation before it becomes an invoice. No surprise change orders.

## Where Bleu is not the right choice

- **If you want contractors by the hour under your direct management** — staff augmentation is on our list of things we don’t sell. There are good companies for that; we’re not one of them.
- **If the criterion is the lowest price,** we lose the bid, and that’s fine.
- **If you want a vendor that executes without pushing back,** we’ll be annoying. Questioning the request is part of the job.
- **If the project needs a twenty-person team tomorrow,** our model is a different one: small, senior, embedded in your operation.

If you’re comparing proposals right now, a 30-minute conversation helps more than any article: you bring the proposals, we bring the questions.

Contact: [Book 30 minutes](https://bleu.builders/contact/)