Can a software company use ARTES Industrial Competitiveness for a satcom product?

A software company can investigate ARTES Industrial Competitiveness when its work contributes to a satellite-communications product, service or system. The business case should explain that contribution precisely. Merely operating in cybersecurity, cloud software or artificial intelligence does not establish programme fit.

ESA's current description combines Technology and Products with Partnership Projects under Industrial Competitiveness. It identifies development across satellite communications, including software-relevant areas such as ground-segment digitalisation. The programme seeks activities that improve industrial competitiveness and can reach commercial use. ESA Industrial Competitiveness

Start by identifying what the company would actually sell. It might offer a software component to an equipment supplier, a management application to a service provider or a complete commercial service. These models have different customers, integration responsibilities and revenue assumptions. A proposal should not move between them without explanation. The DLR optical ground network case identifies the operating evidence still needed for a continuing space service.

Define the product boundary. Which functions belong to the company's software, which are supplied by partners and which depend on a customer's existing system? A clear boundary helps the team estimate development effort and makes the proposed commercial contribution assessable.

The customer case should explain an economic or workflow benefit in appropriate public terms. Reduced administrative effort, more consistent service management or simpler integration can be meaningful business outcomes. Avoid substituting a generic claim about strategic importance for evidence that someone would use and pay for the offering.

For a component supplier, partner engagement can be essential. A technically promising module may need an integrator willing to evaluate it within a larger product. Record what the partner has agreed to contribute and which decisions remain open. An introductory meeting is different from an integration commitment.

The development plan should distinguish internal verification from customer qualification. Completing software features establishes one milestone; demonstrating that the product fits the customer's required environment and support model establishes another. Budget the documentation, review and integration work needed for the latter.

Commercialisation also requires ownership of maintenance. If the company expects to provide updates over several years, the business model should support that effort. A project that funds initial development without a sustainable support proposition can leave both supplier and customer with unresolved responsibilities.

Use the official route to check eligibility, national participation and the applicable funding arrangement. The programme overview is a guide to scope, while the specific documents determine the proposed activity's conditions. Do not infer a funding ceiling from a broad programme page or from an unrelated previous project. The NAVISP Element 2 review connects the proposed navigation product with the programme's commercial purpose.

Locate the software inside the communications business

The most useful first drawing is commercial rather than technical: identify the organisation buying the software, the satellite-communications function it improves and the party responsible for the surrounding service. A product sold to a network operator has different adoption dependencies from a tool licensed to a terminal manufacturer. Both may involve software, but the buyer, integration work and evidence of value are different.

ESA's separate application guidance distinguishes industry-originated co-funded proposals from invitations to tender with an ESA-defined activity. It also directs applicants to confirm national participation in the relevant programme element. These are separate questions from whether a proposed feature sounds innovative. A company should resolve the route and funding authority before assigning a large team to a proposal.

Consider a hypothetical developer of commercial ground-network management software. Its existing product might automate the administration of terrestrial networks. The proposed satcom work could concern the additional functions and validation needed by a satellite operator. The commercial argument would need to identify that specific increment. Rebranding the existing product for space would explain little about the development risk, while rebuilding the entire platform might make the proposal unnecessarily expensive.

A useful boundary separates the company's reusable platform, the changes made during the supported activity and customer-specific implementation. The distinction affects ownership, pricing and maintenance. If every customer requires a separate engineering project, the revenue model should say so. If the company expects repeat licensing, it needs evidence that later customers can adopt substantially the same product without repeating the original development effort.

Turn a performance claim into a purchasing comparison

A software proposal becomes more persuasive when the customer can compare the new offering with an identifiable existing cost. That comparison might concern engineering hours, service administration, time needed to bring a new customer online or the cost of maintaining several interfaces. It should use a measure the prospective customer recognises, with the period and scope made explicit.

For illustration, suppose an operator currently spends 120 staff-hours each month reconciling information across two commercial systems. A proposed tool might reduce that work, but a statement that it “saves 100 hours” is incomplete. The evaluation would need to show whether the figure includes exception handling, checking results and maintaining the connector. The operator would also care about licence fees and the effort of changing its existing workflow. These are hypothetical business measures, not reported ARTES project results.

The developer should examine the counterexample as well. A customer with only a small number of transactions might reasonably prefer the existing manual process. Identifying that boundary improves the market case because it explains which customer segment is worth pursuing first. A forecast built around all satellite operators, regardless of scale or workflow, would obscure the actual reason to purchase.

The same reasoning helps choose an evaluation partner. A familiar organisation that likes the technology may be less useful than a customer able to provide the baseline, staff time and commercial decision needed to assess it. The proposal should distinguish a letter expressing interest from an agreement to participate in an evaluation. Neither should be recorded as a future order unless the purchasing commitment is documented.

Price the period after the development activity

The company's financial model needs a supported-project view and a continuing-product view. The first concerns the work, resources and contributions attached to the proposed activity. The second concerns what it costs to maintain and sell the resulting software once that activity ends. Treating the two as identical can make a development project appear profitable while leaving the subsequent product expensive to support.

Continuing costs can include customer onboarding, compatibility work after other vendors change their systems, documentation and the staff who answer commercial support requests. A developer should estimate which costs recur per customer and which are shared across the installed base. That distinction is especially relevant when deciding between a licence, subscription or managed-service offer.

A practical investment decision therefore connects three records: the incremental development work, the evidence required by the first customer and the economics of serving the next customer. If one is missing, the proposal may be technically plausible without yet supporting the company's growth assumptions. ARTES becomes commercially relevant when the supported work closes a specific gap between an existing capability and an offering that a satcom customer can evaluate, purchase and continue using.

A credible software proposition therefore connects four things: a defined product, an identifiable buyer, a development step and a route to integration. That structure helps the company decide whether ARTES is relevant and what partners or evidence it still needs. It also keeps a potential development relationship separate from any future procurement or customer deployment decision.