Why we call ourselves a partner, not a vendor

A vendor ships what's specified. A partner pushes back on the spec when the roadmap doesn't hold up. We aim to be the second kind, on every engagement.

That sounds like positioning language, and in most agency decks it is. The difference is only real if you can point at the moment it costs someone something. So here is what it actually means when we work together.

The moment the difference shows up

Six weeks into a build, someone asks for a feature that wasn't in the scope. It's a reasonable request. It's also going to take three weeks, and it sits on top of an assumption nobody has tested with a real user.

A vendor prices the change and adds it to the schedule. That is a defensible way to run a business: the client asked, the client is paying, the contract gets amended, everyone is behaving correctly.

What we do instead is ask what the feature is supposed to fix. Sometimes the answer is solid and we build it. Often the answer is that a customer complained once, or a competitor has it, or somebody senior saw it in a demo. Then the useful reply is not a quote. It's "here is a smaller thing that tests the same assumption in four days, and if it works we'll build the rest."

That conversation is the whole difference. Everything else is branding.

What a partner owes you

Pushback is only useful if it comes with the parts that make it actionable:

• A reason, not a preference. "That's not best practice" is not a reason. "That adds a second source of truth for member balances, and we'll be reconciling them for the life of the product" is.
• An alternative. Saying no without offering a cheaper path to the same goal is just friction.
• A cost, in the units you care about. Weeks, not story points.
• Owning the outcome. If we argued for an approach and it turns out wrong, fixing it is our problem, not a change request.

What it costs us

This is not free on our side, and it's worth being honest about that.

It makes early conversations harder. A prospect who wants a quote for a fixed feature list sometimes wants exactly that, and our first response is a set of questions about who the users are and what happens if the assumption is wrong. Some of those conversations end there.

It makes engagements start smaller. We would rather begin with a discovery sprint and a narrow v1 than sign for a twelve-month build of something nobody has validated. Smaller first contracts are a worse quarter and a better year.

It occasionally means turning down work. If a project only makes sense with a plan we think will fail, taking it means being paid to build something we expect to be rebuilt. That is a bad trade for both sides.

What we ask in return

The arrangement only works if it runs both directions.

We need access to the actual problem, which usually means talking to the people who will use the thing rather than only the people commissioning it. We need someone on your side who can make a decision inside a week, because a partner who can't get an answer becomes a vendor by default. And we need the spec to be genuinely open to change, not open to change in principle and frozen in practice.

Where we have that, the work gets noticeably better. Where we don't, we're an expensive way to implement a document.

Where the line is

Pushing back is not the same as overruling. It's your product, your market and your money, and you know things about all three that we don't. When we've made the case and you still want the original plan, we build the original plan and we build it properly. Sulking through an implementation is a vendor move too.

The commitment is narrower than it sounds, and easier to check: you will always know what we think before a decision, not after it goes wrong.