Can InCubed support an Earth-observation software service without building a satellite?

An Earth-observation software company does not need to propose a new satellite to explore InCubed. The programme's scope includes data processing, visualisation, analytics and applications. The more difficult question is whether the proposed development can support a commercially viable product or service.

ESA's scope page covers the Earth-observation value chain, including its data segment. Its application guidance asks proposals to demonstrate commercial viability by the activity's end or a robust route to commercialisation. Those statements make business evidence a central part of the proposition. InCubed scope and application guidance The ESA OSIP review distinguishes an idea channel from the steps leading to a contract.

For a civilian land-management application, begin with the decision the customer needs to make. An attractive visualisation may be technically impressive yet commercially unnecessary. Identify the existing workflow, the information gap and the person responsible for purchasing a solution.

The service should have a defined unit of value. A customer might buy a periodic assessment, access to a dataset or a subscription to an application. Each model creates different obligations for updating, support and explaining uncertainty. State which one the company intends to deliver.

Commercial viability requires more than a large market estimate. Show the evidence behind the target segment, expected price and delivery cost. Separate actual customer payments from interviews, pilot participation and expressions of interest. These sources can all be useful when their limits are explicit.

Data rights and dependencies belong in the business model. The company should understand whether it can use the required inputs for the proposed commercial service and what recurring costs apply. A prototype built with temporarily available resources may not reflect the cost of routine delivery. The GEODES booster cost review makes the cost of continuing an Earth-observation service visible after initial support.

The development plan should resolve a specific obstacle to commercialisation. It might concern a repeatable processing workflow, integration into a customer's system or a service feature needed by a defined buyer group. A broad plan to “improve the platform” is harder to assess because the commercial consequence remains unclear.

If a consortium is needed, allocate work around real contributions. A research partner may strengthen the method, while an industry partner may provide integration or customer-domain knowledge. Confirm their role and funding position under the actual programme conditions rather than assuming every useful partner can receive the same support.

The company's post-project plan should identify the next decision and the resources needed. A minimum viable product can support customer evaluation, but it may still require further commercial work. The proposal should make that path visible without presenting projected revenue as contracted demand.

InCubed's public pages explain scope and intent. They do not establish that an individual company, country or cost item qualifies. Check participating-state requirements and the current application documents before committing the proposal budget. The InCubed outline, pitch and full proposal sequence helps a small team plan its effort around separate review stages.

The funded asset can sit in the data segment

The breadth of InCubed matters because an Earth-observation business can create value at several points after an image reaches the ground. A service may combine observations from existing missions, organise the data into a usable product or turn measurements into information for a particular customer workflow. In those cases the company's defensible asset can be its processing, interpretation and delivery system, rather than ownership of the observing platform.

The programme's commercial emphasis makes this more than a semantic distinction. A satellite manufacturer can usually describe the hardware it intends to deliver. A software team needs equivalent precision about its output. A map is an interface; the saleable product may be a monitored portfolio, a change report or an information feed integrated into another application. The proposal should identify that product and the conditions under which it remains useful between demonstrations.

For a hypothetical agricultural advisory service, a useful product definition could be a recurring field-level assessment delivered to advisers who already manage relationships with growers. The advisers, rather than individual growers, might be the immediate customers. That choice changes the interface, training, support costs and distribution model. It also changes the evidence of demand: conversations with growers can explain the underlying problem, while the advisory businesses determine whether the proposed service fits an existing paid offering.

Derisking and product development answer different questions

InCubed's additional application information distinguishes a derisking cycle from a product-development cycle. The former develops a credible concept with interested customers and a roadmap; the latter aims at a commercially viable product without further public development funding. Activities can involve one or both cycles, subject to programme and national arrangements.

A software-only applicant can use that distinction to make its technical plan more precise. If it has not established that available observations can support the customer's required decision, the central issue is feasibility and customer relevance. If it already has a working demonstrator and engaged customers, the unresolved work may concern repeatability, integration or delivery at a commercially sustainable cost. These are different starting points and warrant different milestones.

The difference also changes the interpretation of a pilot. A pilot that establishes whether the customer understands and uses an information product resolves a market question. A pilot that repeatedly delivers an already-understood product through the customer's own systems can resolve an adoption or scaling question. Describing both simply as customer validation loses the information that makes a development proposal assessable.

A company can report the outcome in terms of the uncertainty removed. For example, the agricultural service might establish that advisers can incorporate its reports into scheduled client reviews without a separate analyst translating each result. That finding has a direct commercial consequence: it affects how many customers the same delivery team can support. It is more specific than claiming that a platform has become more mature.

Economics follow the delivery unit

A recurring service brings recurring costs. Input data, processing, storage, support and interpretation should be associated with the unit the customer actually buys. A portfolio subscription cannot be understood solely through the cost of producing one attractive demonstration image. Equally, a service with low processing costs can still be expensive to deliver if every output requires an expert explanation tailored to the buyer.

A simple commercial comparison can expose the relevant development priority. Suppose the agricultural service can serve ten advisers with largely automatic delivery, while an alternative product requires individual analyst reports for each grower. The second may command a higher price per report, but the staffing model is different. An application that treats both as the same software platform would obscure the work needed to create a sustainable business.

This is where the programme's coverage of applications becomes commercially significant. Integration, user-facing delivery and reliable production can be material product-development work when they determine whether a useful method becomes a repeatable service. The company should connect each proposed improvement to that delivery model and show which evidence will establish that the improvement has worked.

The resulting case remains centred on Earth-observation value. It explains why the observations are necessary, how the company turns them into a usable product and why a defined buyer would continue paying for that product after the development activity ends. Those connections give a software applicant a substantive proposal without inventing a satellite-building requirement.

The software opportunity is real at the programme level, but a credible application needs a disciplined service case: who buys, what improves, what it costs to deliver and what evidence will demonstrate progress toward commercial use.