Big partner, small startup. Building collaboration that stands up to reality

Working with a large organisation can open opportunities that would take a small technology company years to build on its own. Access to infrastructure, specialists, real problems and a potential market can accelerate product development. For a large business, a startup can offer expertise, ideas and a pace of experimentation that may be difficult to achieve within its own structures.

Both sides therefore have rational reasons to start a conversation. Difficulties arise when similar-sounding statements begin to mean different things.

For one side, another meeting may be part of exploring the market. For the other, it becomes a reason to buy components and commit another month of work to the project. One organisation is still assessing the possibility of working together while the other is already paying to prepare for it.

The central question is whether the pace of committing resources matches what has actually been agreed.

This article examines such situations from the perspectives of the startup, the large company and the people who will eventually use the solution. The tools presented here are suggestions for organising collaboration, and the numerical example is hypothetical. They do not describe a particular business or determine the responsibility of participants in any specific project.

1. Why a large partner can be so valuable

In technology projects, the hardest resource to obtain can be remarkably ordinary: the opportunity to find out whether a solution works under the conditions in which someone will actually use it.

A startup can build a demonstrator, run laboratory tests and prepare a convincing presentation. It still does not know how the product will behave within an existing process, how users will respond or how much work maintenance will require. A large organisation can provide conditions that cannot be reproduced at a desk.

The benefit also runs in the other direction. The partner gets to evaluate a new technology without having to build every capability internally. It can understand the idea’s limitations sooner, assess its usefulness and decide whether further development is worthwhile. The EIC report on corporate-startup collaboration highlights access to resources, market validation and opportunities to scale, alongside the expansion of capabilities within large firms. It is a programme report describing possibilities and participants’ experiences, rather than a guarantee of similar results for every venture. EIC, “Unlocking innovation through corporate-startup collaboration”.

It helps to distinguish three kinds of value: access, learning and revenue.

Access to a test environment can be valuable even if it does not lead to a purchase. Knowledge gained through testing can improve a product intended for many customers. Revenue is a separate outcome, dependent on subsequent decisions. Problems begin when a startup funds the project as though the third outcome were already a natural consequence of the first two.

Before substantial work begins, it is therefore worth asking what will remain in the company if the partner ultimately does not buy the solution. Will it be validated assumptions, reusable technology and data the company is allowed to use? Or will it be an expensive configuration tailored to one environment that needs rebuilding before the next sale?

Whether the collaboration itself can be used as a reference matters too. A reference has value only when the startup is permitted to use it and knows what it demonstrates. Participating in a programme, completing a test and achieving a commercial deployment are different accomplishments.

The large organisation needs a similar distinction. Observing an interesting technology can be a legitimate objective. If the objective is to improve a particular process, however, someone responsible for that process should be involved from the outset.

A good partnership starts by defining the value each side hopes to obtain and the cost it consciously accepts in order to discover whether that value is achievable.

2. What does “we want to work with you” actually mean?

“Collaboration” is a convenient word because it allows a conversation to begin without predetermining its outcome. That same flexibility can later become a source of misunderstanding.

Needs discovery helps the parties understand a problem. Acceleration may offer contacts, knowledge and development support. Joint research and development aims to create something that does not yet exist. A pilot tests specified properties of a solution in a limited application. A purchase concerns the delivery of agreed value on agreed terms.

These forms can overlap, but they should not automatically be treated as successive steps towards an order. Nesta’s guide to collaboration programmes recommends starting with corporate objectives and then matching the form of engagement and available resources to them. Launching a programme does not, by itself, determine the business outcome it should deliver for a particular startup. Nesta, “Winning Together”.

Imagine that a customer asks for an additional feature during a demonstration. For the customer’s team, this is a question about what might be possible. The startup interprets it as a condition of a future purchase and starts implementation. Unless someone makes that difference explicit, both parties may later be sincerely surprised by the other’s expectations.

A simple distinction between types of confirmation can help:

This is a management tool, not a ranking of documents by legal force. The significance of a particular email, understanding or agreement depends on its contents and circumstances.

It is especially important to establish whether the partner is assessing an existing product or expecting technology development. If running a pilot first requires designing a device, obtaining data and creating a validation method, the scope includes substantial development work. Calling the whole effort a “quick test” does not reduce that work.

It is also worth checking whether the intended result is a repeatable solution. A large customer may legitimately need adaptation to its own processes. The startup should nevertheless know when it is developing a product for a market and when it is delivering a bespoke engineering service for one organisation. Both models can be profitable, but they require different approaches to pricing and funding.

Before every substantial stage, the parties therefore need a shared statement of its purpose: what they intend to test, what will be produced, who will benefit and which decision the result will make possible.

3. The partner is an organisation, not a single person

A good relationship with a representative of a large company matters, but it does not provide a complete picture of that company’s ability to act.

Someone in the innovation team may understand the technology and actively support the startup. The budget may nevertheless belong to another unit, the test environment to operations, and supplier approval to procurement. Each of these functions assesses the project against different criteria.

Nesta’s research into barriers to collaboration identifies differences in pace, coordination problems and internal strategic and procedural barriers. Its authors drew on interviews and a startup survey, among other sources. The report dates from 2016, so it is useful as an account of mechanisms rather than a current measure of how often they occur. Nesta, “Scaling Together”.

The practical implication is that several functions need to be identified. Who experiences the problem and is responsible for solving it? Who can allocate money? Who will provide people and access? Who will assess the result? Who can stop a test if a significant hazard emerges?

In a small project, one person may fulfil several functions. What matters is that their authority and availability match their responsibilities. A senior-sounding job title does not establish that on its own.

The point of contact may have limited influence

It is easy to judge a situation through the person in front of you: if they promise help, they should be able to provide it. Yet they may still be seeking internal backing and resources themselves.

That does not diminish the value of their work. It does change how the startup should plan its own expenditure. An internal advocate needs evidence and support. A company funding development also needs to understand where that advocate’s authority ends.

The operational user’s perspective matters just as much. For them, a test may mean extra duties, changes to established routines and responsibility for responding to errors. Without time, instructions and an explanation of the purpose, even a technically sound product may be seen as a burden.

Procurement also has legitimate questions. Can the supplier meet its commitments? Who will provide support? What happens if a key engineer leaves? The startup should treat these questions as part of preparing its offer and be candid about the limits of its readiness.

Distributed responsibility needs explicit connections

Shared responsibility for a project’s success is not enough to manage a particular task. If infrastructure access depends on three departments, someone must be able to obtain their decisions and confirm readiness.

Every significant dependency should have an owner, a deadline and a way to confirm completion. Otherwise, the startup’s schedule may contain dates that depend on resources the partner has not yet allocated.

An accelerator programme operator may have a separate role. It is worth establishing whether it is responsible for introductions and meetings or also for coordinating resources, escalation and tracking agreements. Having an intermediary does not remove the need to identify the person making the business decision.

A useful measure of progress is a reduction in significant unknowns. Another meeting adds value if it produces a decision, supplies information or removes a dependency. The intensity of contact alone does not show whether the project is moving towards a feasible next stage.

4. The same month can have a different cost

The asymmetry in a partnership is not simply a difference in budgets. It is primarily about how much of each side’s operating capacity the project absorbs and what happens when it is delayed.

A large company incurs real costs: specialists’ salaries, infrastructure use, coordination and the risk of disrupting operations. A salaried employee’s time is not free. Yet one experiment may represent a small part of the organisation’s portfolio while occupying most of the startup’s team.

A founder may also fund the company personally and go without pay for an extended period. The bank account then shows only part of the burden. The remainder takes the form of personal financial reserves, time and reduced capacity to earn elsewhere.

Evaluating the project requires at least three separate views:

• Cash flow: how much money must be spent, and when.
• Work committed: how much time the project consumes and whether that work is already paid for.
• Available alternatives: what can realistically be done instead of the next stage.

Keeping these categories separate helps avoid both underestimating the effort and artificially overstating losses.

Sunk costs and retained value

Expenditure that has already been incurred and cannot be changed by the current decision is a sunk cost. Its size does not automatically justify further funding. The possibility of selling or otherwise using existing resources should be assessed separately. The Green Book explains this distinction, although the document itself concerns public-sector appraisal rather than startup valuation. HM Treasury, “The Green Book”, section on sunk costs.

In practice, the historical cost of writing software and that software’s future usefulness are separate pieces of information. Continuing a particular partnership is not necessary to preserve the value of the technology created. Adapting it to another application may make more sense.

Nor should the entire value of a hypothetical contract be treated as an opportunity cost. The alternative must be available and realistic. If the same hours have already been valued using the earnings available on another project, adding that project’s entire value again may count the same cost twice.

Example: three ways to use the next two months

Consider a hypothetical team with PLN 120,000 in cash. Its fixed expenses are PLN 12,000 per month and, in this example, do not include the founders’ pay. We assume no new cash receipts during the next two months.

The partner has not yet approved funding. The team is considering three options:

These figures are assumptions for the example, not market data. The cash difference between full continuation and a pause is PLN 18,000. The difference in time committed is 760 hours.

If we use an illustrative hourly value of PLN 150, the corresponding values of team time are PLN 120,000, PLN 24,000 and PLN 6,000. These amounts are not additional payments from the bank account. Nor do they prove that the team could sell every freed hour at that rate. They simply help show the scale of work not reflected in cash expenditure.

A pause preserves the most resources but may have a cost: losing a test slot, delaying learning or having to prepare the team again. Full continuation may be justified if its results will be useful regardless of the partner’s decision. Limited discovery, meanwhile, may be enough to resolve a particular unknown.

The table therefore does not select a winner. It shows the cost of each decision and reveals what information is needed to choose between them.

With the assumptions unchanged, every additional month of waiting reduces the cash reserve by another PLN 12,000 in fixed costs, even during a pause. That is why saying “we will wait for a decision” requires specifying how long the company can wait and what it will do in the meantime.

The prospect of a large contract does not fund today’s expenditure

The value of future sales must be separated from the timing of cash receipts. Even an attractive project may require purchases and work before acceptance and payment. A positive forecast margin does not eliminate liquidity risk.

It is also unhelpful to assign an intuitive probability to an order and multiply it by a large amount. The calculation can look precise while its crucial assumption remains a guess.

Scenarios may be more useful: what happens if the answer is no, the decision is delayed or the scope is reduced? GAO’s cost estimating guide emphasises explicit assumptions, sensitivity analysis and updating estimates with actual data. A small project can apply these principles in a simple spreadsheet. GAO, “Cost Estimating and Assessment Guide”.

5. Hardware and AI require readiness on both sides

In a project involving devices, a change in requirements can mean another design revision, purchases, assembly and repeat testing. The test date then depends on components, people and the environment, not just the speed of writing code.

A demonstrator may establish that a principle works without establishing durability, manufacturing repeatability or ease of servicing. Technology readiness should be assessed in light of the conditions under which performance has been demonstrated. GAO’s technology readiness guide stresses the importance of evidence of maturity before integration and production. Such an assessment should not, however, be confused with proof that the product is commercially viable. GAO, “Technology Readiness Assessment Guide”.

AI adds dependencies on data and measurement. Access to a test site does not necessarily mean access to suitable data, permission to use it or the availability of people who can help evaluate the result. Testing on a convenient dataset may answer a different question from the one that matters to the future user.

In AI RMF 1.0, NIST recommends documenting test datasets and metrics, evaluating performance under conditions similar to the intended deployment, and identifying limits to how far results can be generalised. These are voluntary risk management guidelines, not automatic certification of a solution. NIST, AI RMF 1.0, “Measure” function.

For managing the collaboration, it is useful to separate three questions:

Technical readiness: can the solution undergo the planned test, and will that test produce a credible result?

Organisational readiness: are the people, infrastructure, data and agreements required to carry out the test available?

Commercial readiness: is it clear who will decide on further expenditure and on what basis?

These forms of readiness can develop at different speeds. A budget does not mean the technology is ready. A functioning prototype does not mean the user is prepared. An organised test does not confirm a future purchase.

If data or access is missing, adding more startup working hours may not accelerate anything. The dependency needs to change, and sometimes the experiment’s scope needs to shrink. Treating every delay as a problem with the technology supplier leads to poor decisions in such circumstances.

Planning beyond the pilot matters too. Who will update devices, analyse errors and handle support requests? Some details can wait, but assessing the economics of deployment requires understanding the kind of maintenance that will be needed. The price of a prototype is not the lifetime cost of an operational solution.

6. Pressure for a demonstration does not replace test conditions

Presentation deadlines, site availability and management expectations create pressure that can be entirely understandable. The problem arises when the deadline becomes more important than determining whether the experiment is ready.

A test needs a defined configuration, purpose and boundaries. It also needs stop conditions and people responsible for responding to problems. NASA’s definition of a Test Readiness Review includes not only the hardware and software under test but also the facility, personnel and procedures. This is a useful principle at a smaller scale too, without importing an entire space programme’s documentation into a startup. NASA, “Systems Engineering Handbook”, definition of Test Readiness Review.

In practice, a technical concern should lead to a decision. It should describe the issue, its possible consequences, what remains unknown and what would allow a decision to be made. Simply recording a concern in a meeting does not resolve it.

Authority matters as well. The person organising a presentation may not have the expertise to assess safety. A technical expert may identify the conditions for proceeding but lack the resources to meet them. Those responsibilities need to come together before testing begins.

Reporting a significant hazard should trigger assessment by the appropriate people, with the ability to suspend activity until the issue is clarified. Schedule pressure is not evidence that a risk has become acceptable.

This does not require complete certainty before every experiment. The purpose of testing is to acquire knowledge. The parties must nevertheless identify which uncertainty they are investigating, under what conditions and with what permissible consequences. Testing a limited function in a controlled environment may require different preparation from using the same prototype in normal operations.

Changes should be treated in the same way. Modifying a device, its installation, an AI model or the conditions of use may make an earlier assessment insufficient. The extent of reassessment should match the impact of the change.

Mature collaboration allows someone to say “this test needs more preparation” without that being treated as a lack of ambition. The startup should be able to justify the limitation and propose the next step. The partner should ensure that the concern receives a substantive assessment.

7. The startup’s responsibility and the large company’s legitimate concerns

A balanced analysis must also examine decisions made by the smaller party. Limited resources do not remove responsibility for how those resources are committed.

A startup may overestimate the significance of the customer’s brand, infer an unjustified likelihood of an order and ask about budget too late. It may also present the technology as more mature than the test evidence supports because it is afraid of losing interest.

This makes planning harder for the partner. If the customer believes it will receive a product ready for evaluation and only later discovers that months of R&D are needed, caution is understandable.

Honest communication is essential: what works, under which conditions, what remains unverified and what work separates the present state from the expected result. Credibility also comes from being able to explain what the startup cannot yet provide.

A large organisation is also buying the ability to deliver

The customer cares about more than whether a feature works. It also needs repeatable delivery, fault handling and continuity of service.

A small team may have exceptional technology while depending on a single person. The partner has legitimate reasons to ask about documentation, coverage of critical skills and what happens when the collaboration ends. The answers should be proportionate to the application: an experiment does not require the same assurances as a solution critical to the business.

The corporation may also rationally choose another route: an existing product, a process change, internal development or postponing the investment. Comparison with those alternatives should be part of the business assessment. The fact that the startup has put in a great deal of work does not mean its solution must be purchased.

At the same time, awareness of a small supplier’s limitations should shape the collaboration. If a large company expects rapid access to the team, bespoke changes and readiness for work on site, it needs to account for the cost of those expectations and the need to agree them explicitly.

Responsibility does not have to be divided equally

Not every disagreement is a “communication failure on both sides”. If someone has failed to fulfil a specific, accepted obligation, that obligation and its consequences should be assessed. Objectivity requires establishing who had the knowledge, influence and ability to act.

It helps to distinguish an event from an attributed intention. A delayed decision can be described, measured and reflected in a plan. Claiming that someone deliberately prolonged discussions requires additional evidence.

The founders’ position also deserves attention. A company may appear to function because its owners continuously fill gaps with unpaid work. That model makes capacity limits harder to see. Limits on investment should therefore include time, personal financial reserves and the ability to meet other commitments.

8. How to design collaboration so it can be managed

A small experiment needs only a short set of agreements. Their value comes from answering important questions, not from the number of pages.

The proposed model assumes that each stage resolves a particular unknown. Discovery confirms the importance of the problem. Feasibility analysis identifies constraints. Technical validation provides evidence of performance. An operational pilot tests usefulness within a process. A commercial decision determines whether, and at what scale, the solution will be used.

Not every project needs all these stages separately. An existing product may proceed directly to a limited pilot. An early technology may need several experiments before it comes into contact with the customer’s normal operations.

Practical tool: a pilot agreement worksheet

The following worksheet is intended for the parties to complete together. In a larger project, individual fields can refer to more detailed documents.

The worksheet is useful only if its agreements are feasible. Writing “the partner provides an expert” is insufficient if the expert knows nothing about the project and has no time available. Confirmation should come from wherever the resource is actually allocated.

It is also worth describing what happens when a dependency is not met. If the environment is not ready on time, is the test postponed? Does the team return to other work? Who bears the agreed cost of preparing again? Such questions allow the parties to respond without restarting negotiations every time.

An unpaid stage can be justified

Unpaid discovery can be a rational investment by the startup. The conditions are a deliberate limit and attainable value: better market understanding, validation of a requirement or access to an environment that is difficult to reproduce.

It becomes a problem when the stage keeps expanding without a fresh decision. Another feature, another trip and another analysis may each appear minor while collectively turning a sales conversation into a substantial project.

It helps to distinguish the cost of preparing a normal proposal from work that creates value for the partner in its own right. A substantial feasibility study, architecture design or research plan may warrant a separate agreement on scope and funding.

Similarly, a paid pilot does not establish repeatable demand. The customer may be buying a one-off expert assessment or experiment. The startup should check whether the result brings it closer to the market it intends to serve.

In-kind contributions and cash solve different problems

Providing infrastructure can be extremely valuable. It does not necessarily pay for components or a subcontractor’s work. When agreeing how costs will be shared, it helps to show both the value of in-kind contributions and the remaining cash needs.

A fair split does not have to mean half the expenditure on each side. It may depend on who retains the technology, who gains the ability to sell it elsewhere and who can use the result. It should nevertheless be deliberate and understood before significant commitments are made.

The path beyond the pilot should be understood in advance

Before testing, it is worth establishing what will follow a good result. Who will prepare the case for purchasing? Will a further supplier assessment be needed? Which budget would fund deployment? What conditions must be met beyond technical success?

This does not guarantee an order. It does make it possible to recognise a pilot that does not yet have an owner for the next step.

A negative outcome also needs interpretation. Insufficient technology must be distinguished from a poorly prepared experiment, missing data or changed conditions. An inconclusive result should not automatically trigger another indefinite round of work. It needs a new question, scope and decision on resources.

9. When to continue, and when to regain room to act

Further commitment should follow from what has changed since the previous decision.

There may be new data, an approved budget, a confirmed user or a solution to a significant obstacle. It may also have become clear that the technology has greater value outside the application being considered. Any of these findings may justify updating the plan.

Caution is warranted, however, if requests and meetings are multiplying without additional confirmations needed to carry out the project. A later decision date does not necessarily rule out collaboration. It should lead to a fresh agreement on how much work is justified during the wait.

Practical tool: questions before the next substantial commitment

1. Which unknown will this expenditure or work resolve?
2. What has changed since the previous decision to continue?
3. Which assumptions are confirmed, and which are still only plausible?
4. Has the partner provided the resources on which the result depends?
5. Who will make the next decision, and when?
6. How much can we spend if the decision is negative or delayed?
7. What will remain useful for other customers or applications?
8. Do we have a realistic alternative use for these resources?
9. Do technical and safety conditions allow the planned activities to begin?
10. What, specifically, would cause us to reduce, pause or stop the work?

The answers can support four legitimate decisions.

Continue when the scope is feasible, resources are available and the next stage will provide valuable knowledge or a useful result.

Renegotiate when the opportunity remains attractive but costs, requirements or the parties’ contributions have changed.

Pause to preserve the relationship without keeping the full team on standby. A pause needs clear rules: limited contact, a condition for resuming and recognition that restarting may take time.

End the collaboration when further expenditure lacks sufficient justification, the partner cannot provide essential conditions or better uses of the resources are available.

The absence of a customer decision does not tell the startup what the customer’s intentions are. It may nevertheless provide enough information for the startup to make its own decision: at the present level of confirmation, the company will not increase its commitment.

Closure should be as deliberate as initiation. Results, payments, equipment, data access and knowledge of the solution’s limitations need to be put in order. An unsuccessful deployment can leave valuable technology and a useful relationship. A project that continues without boundaries can consume the resources needed to make use of either.

For a large organisation, a timely refusal is an equally important capability. Clear information about the absence of budget or priority allows a small partner to make a rational decision and preserves the possibility of returning under different conditions.

A good partnership allows both sides to say: we know what we are testing, who will do the work, how much we can invest and when we will make the next decision. That keeps the scale of the opportunity visible alongside the cost of exploring it.

Sources

This article combines analysis of collaboration mechanisms with original management tools. The financial example is not drawn from a study or an actual project. The cited publications serve different purposes: collaboration reports describe experiences and practices, while GAO, NASA, NIST and HM Treasury documents provide principles for analysis. Their use does not imply that a small company should adopt those institutions’ complete procedures.

1. Nesta, “Winning Together” (2015) - matching the form of collaboration to organisational objectives and resources.
2. Nesta, “Scaling Together” (2016) - decision-making, organisational and coordination barriers; a historical source, without treating its older statistics as current market measurements.
3. EIC/EISMEA, “Unlocking Innovation through Corporate-Startup Collaboration” (2025) - benefits and conditions for developing collaboration, from the perspective of a programme supporting such partnerships.
4. HM Treasury, “The Green Book” (2026) - separating sunk costs from future decisions and alternative uses of resources.
5. GAO, “Cost Estimating and Assessment Guide” (2020) - explicit assumptions, cost estimation and sensitivity analysis.
6. GAO, “Technology Readiness Assessment Guide” (2020) - evidence of technology maturity and the conditions under which it is assessed.
7. NASA, “Systems Engineering Handbook” - readiness of the solution, environment, personnel and procedures for testing.
8. NIST, “AI Risk Management Framework 1.0” (2023) - evaluating AI in its intended context and documenting limitations of results.