A practical framework for service providers to evaluate product, delivery, and procurement fit, set boundaries, and…
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
A company can need exactly what you know how to build. You can understand the product, identify the risks, see the right architecture, and have relevant experience delivering similar systems. The client may recognise all of this too. And the project can still turn into the wrong opportunity, because product fit is only one part of what makes an engagement work. The missing piece is often procurement fit: whether the process the client uses to buy the work is one your business is actually built to survive.
Most service providers evaluate opportunities by looking at product fit. Do we understand the problem? Have we built something similar? Do we have the right technical and design capabilities? Can we produce a meaningful result? These are important questions, though they only cover part of the evaluation.
A provider can be a strong fit for the actual work and still be poorly suited to the process through which the client purchases that work. This distinction matters most for small specialist teams, independent consultants, and founder-led studios.
A larger agency typically has dedicated salespeople, bid managers, legal support, and employees whose job is to participate in procurement processes. A specialist team usually runs without any of that. For a small team, time spent preparing unpaid demonstrations, attending presentations, answering procurement questionnaires, and participating in workshops is time taken directly from paid client work, and that changes the economics of the opportunity.
It helps to separate three different questions.
Can the provider solve the client's problem? This includes technical ability, relevant experience, understanding of the market, design capability, architecture, and execution. A product fit means the provider is capable of building the right thing.
Can the client and provider work together effectively? This includes communication, access to decision-makers, feedback cycles, ownership, speed of approvals, meeting culture, and expectations around collaboration. A delivery fit means both sides can operate in a way that allows good work to happen.
Is the provider willing and structurally able to participate in the client's buying process? This includes tender documents, compliance forms, unpaid prototypes, in-person presentations, proposal rounds, workshops, commercial negotiations, and internal approvals. A procurement fit means the process of winning the work is compatible with the provider's business model.
These three types of fit are related, though they operate independently of each other. A provider can be an excellent product fit and a strong delivery fit and still land as a poor procurement fit.
Procurement exists mainly to reduce risk. The client wants to compare providers, document decisions, evaluate pricing, confirm compliance, and demonstrate that the selection process was fair. Regulated industries and large organisations have good reasons for building processes this way.
Every procurement process also creates a filter, whether or not that's the intent. It shapes which types of providers show up as much as it evaluates the quality of the providers who do.
A process that requires extensive unpaid work will favour companies that can absorb extensive unpaid work. A process that requires repeated in-person presentations will favour local companies with dedicated sales teams. A process built around formal documentation will favour providers that are good at producing formal documentation. A process involving several rounds of presentations, workshops, and negotiations will favour companies whose commercial model expects long sales cycles.
The company that wins a process like this is often simply the one best structured to win that type of process, independent of whether it's the strongest product team on the list.
This creates an outcome the client rarely intends. The providers with the strongest demand are often the least willing to participate in a long procurement process.
Busy specialists already have clients who hire them based on expertise, referrals, reputation, and focused conversations. Competing through several rounds of unpaid work rarely fits how they operate. They tend to ask direct questions early: how much time will this process consume, how many providers are involved, is there a real budget, who makes the decision, is the next step paid, can the process be completed remotely, how many additional rounds should we expect.
When those answers stay unclear, they often just leave. This usually reflects a high opportunity cost.
The result is that an overly demanding procurement process can filter out the exact type of provider the client is trying to find. The client may want a small, senior, fast-moving team, while the procurement process stays optimised for large vendors with sales departments, account managers, legal teams, and the capacity to absorb a long competitive process. The desired provider and the selected provider can end up being very different companies.
A client has a legitimate need to assess whether a provider understands the project. A focused concept, prototype, technical discussion, or short proposal is a reasonable way to build that confidence.
The real question is proportionality. Showing how you think, demonstrating a relevant capability, and presenting a limited concept all serve that purpose well. Producing substantial unpaid work the client can use independently serves a different purpose entirely.
A small prototype can help both sides evaluate the opportunity. A complete design system, detailed architecture, implementation roadmap, technical specification, and commercial plan already represents a meaningful portion of the project itself.
There's a clear boundary between enough work to establish confidence and enough work that already solves the project for free.
The same logic applies to meetings. Some sessions genuinely benefit from being held in person: complex discovery workshops, stakeholder alignment, product strategy sessions, and critical project milestones can all justify physical attendance.
An early-stage concept presentation usually doesn't need that. A video call lets the provider share a prototype, explain decisions, answer questions, and walk through the user journey without losing a day to travel.
For remote-first teams, this reflects how their whole operating model works, not just a scheduling preference. They often work with clients across several countries, and their processes are already built around clear documentation, focused calls, asynchronous communication, and rapid delivery.
Requiring physical attendance before any commercial commitment tends to reveal something about how the organisation expects the wider engagement to run. The first in-person demo can turn into an in-person proposal presentation, which can turn into an in-person negotiation. After the contract, it can turn into regular stakeholder meetings, steering committees, and internal presentations. A single request works as an early signal here, well before it becomes a pattern.
When the operating models differ, the provider doesn't need to tell the client that its process is outdated. Whatever conclusion the provider reaches privately, voicing it rarely helps the relationship.
The more useful response is describing the operating model clearly. For example:
Before a commercial engagement, we work remote-first and keep unpaid proposal activities focused. We are comfortable preparing and presenting a concise concept remotely. Once there is commercial alignment, we are available for in-person workshops where they materially benefit the project.
This functions as a compatibility test. The client gets to decide whether the process can accommodate the provider. The provider gets to decide whether the opportunity justifies participation. Either side can walk away without anyone being wrong.
Setting boundaries is often read as a mark of maturity, even though many providers worry it will make them look difficult — that saying no to an in-person meeting, refusing excessive unpaid work, or questioning a procurement step will damage the relationship.
A professional provider should know how it produces its best work, which types of engagements suit its team, how much unpaid presales effort is reasonable, which activities belong in a paid discovery phase, and when an opportunity stops being commercially sensible.
Establishing this early beats participating reluctantly. A provider that ignores the mismatch tends to grow frustrated, underprice the work, resent the client, and struggle throughout delivery, which leaves the client experiencing exactly the risk its procurement process was meant to prevent. Early clarity serves both sides better.
This might be the most important point here. Not every strong opportunity should become a project.
You can respect the client, understand the product, and believe your team could deliver it well, and still conclude that the selection process doesn't match how you operate. Recognising that mismatch is a mature business decision. It reflects an accurate read of what a quality engagement actually requires: alignment across the product, the delivery model, and the buying process. When only one or two of those line up, the relationship can turn difficult before implementation even begins.
A mature service business doesn't try to win every possible project. It tries to identify the projects where it can deliver excellent work under conditions that support excellent work.
That means asking more than "can we build this?" It also means asking whether you can work effectively with this client, whether their procurement process is compatible with your business, and whether this engagement will let you operate at your best.
Sometimes the answer is yes. Sometimes a small adjustment, like a remote presentation or a paid discovery phase, creates enough alignment. And sometimes the fit for the product and the fit for the procurement process simply point in different directions.
Recognising that early can save both sides a significant amount of time.
Thanks, Matija