The difference between a vendor and a partner rarely shows up in the pitch. Both can present a polished proposal, a reasonable timeline and a credible portfolio. The difference shows up six months after launch, when something needs to change, a bug surfaces in a part of the system nobody has touched since handover, or the business itself has moved on from the assumptions the original build was based on. A vendor delivered what was specified and considers the relationship finished. A partner expected this moment and built for it.
What a vendor optimises for
A vendor's incentive is to close the current contract efficiently: match the spec, hit the deadline, hand over the deliverable, move to the next client. This is not dishonest — it is simply a different relationship than most businesses actually need from technology, because a spec written before a system exists is never the final word on what the system should do. A vendor treats deviations from that spec as scope creep to be billed separately. A partner treats them as the normal, expected process of building something that works in the real business rather than only on paper.
Questions that surface the difference before signing anything
"What happens after launch?" A vendor's answer is usually a support package priced by the hour or the ticket. A partner's answer usually includes what they expect to change in the first three months, because they are already thinking about the system as something that evolves rather than something that ships and ends.
"Who else has access to this once we're live?" This question exposes whether the company plans to hand over real ownership — credentials, source code, documentation — or intends to remain the only party who can touch the system. An answer that dodges specifics here is worth taking seriously as a warning, not a technicality to sort out later.
"What would you have built differently if the brief had been wrong?" A partner has an answer, because they have already been pushing back on parts of the brief that did not hold up, rather than building exactly what was asked for and letting the client discover the gap later. A vendor's answer here is often that they built to spec, which sounds responsible and usually is not.
"Can you show me a client relationship that's lasted past the first project?" A vendor's client list is mostly one-off engagements. A partner's client list includes businesses still working with them years later, which is a stronger signal than any single project in the portfolio.
Why this matters more for smaller businesses
A large enterprise can afford to hire a vendor for a narrow, well-specified task and manage the relationship in-house with its own technical team. A smaller business usually cannot — it does not have the internal expertise to catch a bad spec before it is built, or to manage a system's evolution without outside help. For a business in that position, the technology relationship itself is part of what is being bought, not a formality around the delivered code, which is one reason why the process a project runs on matters as much as the software it produces — a well-run relationship absorbs surprises the same way a well-mapped process does. Our software team is set up to keep working with clients after handover specifically because that is when a system's real requirements usually become clear.
