When to raise funding for your product
There's one idea that puts every funding decision for a product in order: public grants don't make you succeed; private money starts the clock.
Public money doesn't dilute your stake, doesn't impose a growth schedule and can cover well-defined pieces of development. It rewards innovation and technical feasibility, things you can prove before you have customers. Private money is the opposite: it demands metrics that don't exist yet at an early stage and, from the day it comes in, there's a schedule to meet. If it arrives before there's a product, you hand over a big share of the company for little money (because the company isn't worth anything yet) and you bet everything on the first version getting it right. Without a product there's no valuation, and no second chance either.
With that in mind, the right question isn't "what funding is out there?" but "what stage is my product at?". Let's go stage by stage.
1. An idea, nothing built
What fits: your own resources and, at most, the entrepreneurship grants meant for people starting a business. Nobody outside is going to put serious money into an idea, and that's fine: it forces you to validate cheaply.
What should be ready first: a clearly defined problem, who suffers from it and some validation that doesn't require building anything (interviews, a landing page that measures real interest).
The typical mistake: looking for private investment with a pitch and nothing built. At this stage the company is worth practically zero: any money that comes in takes a huge slice in exchange for very little.
2. A prototype or demo
What fits: public grants for launching innovative companies. This is exactly what they're for: there's something to show, there's innovation to justify and there are no metrics to demand yet.
What should be ready first: a credible demo, a written description of the problem without jargon and a milestone plan with an itemized budget. Almost everything a grant application asks for at this stage is documentation that a well-run development produces as a matter of course.
The typical mistake: building first and applying later. Many programs only count spending after the application: every month of development before it is money left on the table. You check the grant calendar before you start, not when you finish.
3. A working MVP
What fits: public R&D and innovation funding to expand the product, and public loans tied to a business plan, which arrive without dilution and without personal guarantees. This is the bridge-building stage: a real product, first data, but not yet enough history for private capital.
What should be ready first: the product in production with real users (even if only a few) and honest metrics: who comes in, who comes back, who pays.
The typical mistake: two opposite ones. Settling into grant life, stringing programs together without looking for customers; or rushing to raise private capital with weak metrics, which is the expensive way to fund yourself: low valuation, heavy dilution.
4. A product with its first customers
What fits: now, yes, private money (there's a valuation, a track record and metrics to show) and, in parallel, public funding for growth and international expansion.
What should be ready first: retention and revenue that hold up without tricks. An investor isn't buying what you've built: they're buying what's already happening.
The typical mistake: raising capital to cover up a product that doesn't retain users. Investment accelerates whatever is already happening, good and bad. If users are leaving, a bigger budget just makes them leave faster.
What the money gets spent on (the most expensive mistake)
The most expensive mistake usually isn't when you ask for funding, but the shape of the team you build with it. It's a pattern that repeats across the industry, and two examples sketch it well.
A nutrition app grew to ten people on staff without a single backend developer: two marketers with no product to promote, one iOS developer and one Android developer who could have been a single person, and a full-time UX designer when that's a role you bring in by phases. By the time backend was finally added, the budget had already been spent in the wrong shape.
A product for musicians turned down an international distribution channel to focus on its home market. It shut down with a handful of subscribers.
What the two have in common: a product that was technically correct but useless in the user's hands (in one case, typing every meal by hand into a clumsy search box; in the other, audio where the user's own instrument drowned out everyone else), and nobody found out until the whole budget was gone. The technology didn't fail: the order in which the money was spent did, along with the lack of contact with real users while it was being spent.
The vaccine: show something real every two weeks
That's why we work in two-week cycles with working software at the end of each one. It isn't a methodological preference: it's what keeps you from spending an entire round on something nobody will use. If the search box is clumsy, you find out in the second cycle, when fixing it costs one delivery, and not at the end of the budget, when there's nothing left to fix it with.
It's also what we bring to funding: because we run the development, the product roadmap and the funding calendar are designed together. That's how we approach development from scratch. If you're deciding when to raise and what to ask for, tell us what stage you're at and we'll give you an honest read. No strings attached.