For a Benelux B2B founder building open-source infrastructure, the useful funding question is not simply which grant is available. It is whether the work you need to do produces a shared technical asset, and whether you can deliver that asset without confusing it with the commercial product around it. NLnet’s Restack call gives that question a concrete deadline. It deserves attention from teams building reusable infrastructure, but it is not a general subsidy for every software startup.

What is open, and what changed?

The official Restack page lists its first deadline as 3 November 2026 at 12:00 CET, seeking proposals of €5,000–€50,000. Results must be released under a recognised free or open-source licence. Check the live call before applying; selection is competitive and the amount advertised is not an entitlement.

There is also a recent operational change. NLnet’s 20 October policy announcement says generative AI may no longer write proposals, apart from its accessibility exception, and confines LLM and diffusion-model use in project development to read-only use. The announcement applies the new policy to the November calls. Read the full policy yourself before preparing an application. This article is editorial analysis, not application text to reuse.

Separate the shared component from the business

My starting point would be a two-column map. In the first column, describe the component other developers could use independently: an interoperability layer, a deployment tool or a reproducible package. In the second, describe the business offering: hosting, implementation, support or a workflow product. These are illustrative possibilities, not a promise that any particular project qualifies.

The distinction matters because a proposal can sound public-spirited while its deliverable remains inseparable from one company’s service. Ask whether another team could install it, inspect its limitations and maintain it without buying your subscription. If the answer is no, investigate the missing dependencies before spending a week polishing a funding narrative.

Benelux founders should also check the programme’s eligibility conditions, including its requirement for a strong European dimension. A Belgian, Dutch or Luxembourg address does not by itself establish technical fit. The published criteria include relevant development, testing, documentation and deployability work; build the case around the work and intended users.

Define a deliverable someone else can verify

A weak milestone says “improve reliability”. A useful milestone defines what will exist and how it will be checked. For a hypothetical deployment tool, that might mean a documented installation path, automated recovery tests and a reproducible example that a second developer can run. Keep the deliverable narrow enough to finish, but complete enough to be useful outside the founding team.

Write down what will not be included. A connector for one protocol is not universal compatibility. A demonstration using synthetic data is not proof that a customer can deploy it safely. Honest boundaries make the result easier to evaluate and reduce the risk that the team silently absorbs unlimited work to satisfy an ambitious description.

Before applying, ask a technically capable person unfamiliar with the project to follow its existing instructions. Record where they stop. That exercise can reveal a more valuable funding scope than another feature request: packaging, configuration, error messages or documentation. This is my suggested preparation method, not an additional programme requirement.

Plan the cash gap around milestones

The Restack FAQ explains that grants are not paid upfront: payment is requested after milestones are reached. A founder therefore needs a cash plan alongside a technical plan. The ability to win support and the ability to finance work until payment are different questions.

Build a simple weekly schedule showing people required, cash committed, acceptance dependencies and the point at which a payment request could be made. Include time for clarifications and rework without presenting any assumed payment date as guaranteed. If one unavailable reviewer or contributor blocks the entire deliverable, the milestone is probably too dependent on a single person.

Consider a hypothetical team with capacity for eight development weeks but only four weeks of available cash. Splitting work into clear milestones might make progress easier to review; it does not create cash automatically. The team still needs a credible way to cover the gap or should reduce scope. Do not count unsigned customer work as certain funding.

Keep commercial evidence separate

An open-source grant and a paying business customer answer different questions. The grant concerns the supported work. A customer tests whether a product solves a problem worth paying for. Repository interest, contributor feedback and downloads may help guide development, but none should be relabelled recurring revenue or a signed deployment.

I would maintain separate records for component adoption and commercial demand. On the adoption side: who can run it, which deployment problems recur and whether fixes are reusable. On the commercial side: who owns the budget, what service is being purchased and what the team must deliver repeatedly. That separation makes the investor discussion more precise.

It also protects pricing decisions. If a founder promises extensive custom implementation to generate early adoption, the service effort needs its own budget. Open availability of code does not make support or delivery free. Our analysis of B2B integrations offers a related way to think about ongoing maintenance responsibilities.

A practical decision before the deadline

Use a short decision memo: the reusable asset, intended users, licensing approach, verifiable milestone, delivery owner, cash gap and commercial boundary. Check the current rules directly, especially the AI policy, and prepare the application in a way that complies with them. If those basics are unclear, declining this round can be a better operational decision than submitting a project the team cannot deliver.

For me, the interesting investment question remains what happens after the funded work: who maintains it, why a business buys the surrounding product and whether delivery can repeat. The paid-pilot rollout scorecard provides a separate framework for that customer decision. If you are building an early-stage B2B or fintech product in the Benelux, share the product, customer evidence and next milestone. A grant can support useful work; it does not replace the business case.