Software Grants for Small Businesses: How They Work and How to Pick a Contractor

The short answer

A software grant works differently from buying with your own money: you don't get to pick a contractor from among people you know. First you describe what is to be built, then you publish a tender, collect offers, choose against criteria set out in advance, and document the whole procedure — because the funding body will look at it when you settle. And the money usually comes back to you after the fact, against invoices and handover protocols, so for a while you are financing the project out of your own account anyway.

One more thing, because this is where the disappointment usually comes from: the whole game is decided in a single document, the statement of work. The description you write is the program you get. Companies that come out badly on a grant almost never lose on formalities. They lose because they described the job so vaguely that the cheapest offer won — and the cheaper offer meant less work, not a better price.

Call names, amounts and deadlines change several times a year, so there is no point listing them here. This post is about the mechanism, which stays the same: how to get from application to settlement without ending up with a program nobody in the company wants to use.

The path: application, decision, tender, rollout, settlement

The application. You have to describe what will be built, why, in what time and for how much. "A system to manage the company" plus a number won't do. The funding body wants to see a scope, a timeline and a budget that looks calculated rather than guessed. Which means the design work happens before you submit, not after the decision.

The decision. Months usually pass between submitting and hearing back, and the company keeps running: new orders, someone leaves, someone adds another spreadsheet to an already decent mess. So describe the scope in a way that still holds six months later — around processes, not around whatever idea felt exciting that week.

Choosing a contractor in an open procedure. You publish the tender wherever the funding body requires, give everyone the same deadline and the same information, and choose against criteria announced before the offers arrive. You can't change the criteria once you've seen the offers, and you can't add a requirement that happens to fit one company.

The rollout. This is where the project is won or lost. A good grant-funded rollout is split into stages, each signed off separately — that gives you protocols for the settlement and a working version to look at along the way, not only at the end.

The settlement. A payment claim is invoices, handover protocols and proof of payment. If the invoice says "IT services" while your application talks about five specific modules, somebody will have to reconcile the two. Agree at the start that invoices and protocols will use the language of your application — five minutes of the contractor's time, two weeks less of your explaining.

The statement of work: the document everything rests on

A statement of work has two contradictory jobs: it has to be specific enough that two offers can be compared, and open enough that it doesn't rule out anyone except one favoured supplier. Overshoot one way and you get offers you can't line up next to each other. Overshoot the other and you get questions at settlement.

For offers to be comparable, the description needs:

• Who uses it, and in which roles. Office, shop floor, supervisor, owner, an outside client. A program for three roles is different work from a program for one, and nobody reads that out of "a system for the company".
• What goes in and what comes out. Where the data comes from: email, a PDF, a spreadsheet, a scale, a terminal. What the program has to produce: a document, a report, a file for the accountant, a notification.
• A list of features, one sentence each. Not "production module" but "the office enters a multi-item order, the floor sees it on a tablet in priority order".
• Technical requirements phrased as outcomes, not product names. Instead of naming a database or a framework, write that the program runs in a browser, on your server, with a daily backup and a full export to file. Brand names are what funding bodies query most often.
• A timeline with stages and a sign-off method. What is finished after stage one, how you check that it is finished, who signs the protocol.
• A clause about code and data. That the code and the data are yours, in your repository and on your server, from day one — not once the final invoice is paid.
• Support after go-live. How many months of fixes are included, what counts as a defect under warranty and what counts as new scope, and what a month of support costs after that period.

Now, why a loose description ends with the cheapest offer that doesn't deliver. When the tender is one sentence — "a program to handle orders" — every bidder prices their own mental picture of it. The company that imagines the least quotes the lowest number and formally wins. Nobody cheated you; there was nothing to break. It only comes out during the rollout that the price never included the Excel import, the shop-floor role, the training or the fixes after launch. Either you top it up yourself, because those lines aren't in the grant budget, or you sign off a program your team doesn't use. We've watched both happen.

Scoring criteria are the other half of the same problem. If price is the only criterion, the procedure picks the lowest quote for you. So add criteria you can verify on paper: the go-live date for the first stage, months of support included, the monthly cost of support afterwards, experience in your industry backed by real projects. Then choosing the pricier offer becomes a decision you can justify.

What to require from the contractor

Four things. All of them checked before you sign, not during.

A fixed price in writing. One amount for the described scope, not an hourly rate with a "from–to" range. Under a grant that isn't comfort, it's a condition of settling: the budget in your application is closed, so hourly billing pushes every overrun onto you. New scope means a separate quote and a conscious decision on your side, not a quiet line added to an invoice.

Work in stages, each one signed off. Short stages, payment in instalments per stage, a working version to look at every week. The benefit is double: you get protocols for the payment claim, and you see whether the program is heading the right way while it can still be changed. A contractor who says "we'll show you at the end" is a risk a company settling a grant cannot afford.

Code and data owned by you. Written into the contract, not promised on a call. Code in your repository, data on your server, a full export to file whenever you want it. The funding body may ask about it, but there's a bigger reason: it's the one thing that stops you being tied to a single supplier for the next five years.

Support after go-live. Software doesn't end at handover. Rules change, a new order type appears, someone asks for a different report. Ask what a month of support costs and what it covers while you're still at the tender stage. If the call's terms let you include a few months of support, use it — it's the most commonly wasted part of a budget.

For scale, so the budget in your application isn't pulled out of thin air: one automation of a repetitive office task usually runs a few thousand PLN net. The first working module of a program built around your company runs 8 000–15 000 PLN. A full production management system, with roles for the office and the floor, reports and data import, runs 35 000–60 000 PLN. Support after go-live starts at 2 500 PLN a month. If your scope overlaps with an off-the-shelf product — Relay, for instance — the rollout and subscription come out cheaper and are easier to budget, because the price list is public from the start.

When a grant isn't worth it

We'll say it plainly, because few people do.

When the scope is very small, the paperwork can eat the entire benefit. Count it honestly: the advisor's fee, your own hours gathering data and signing things, preparing the tender and scoring the offers, then the reporting and the payment claim. Add the item that never shows up in the spreadsheet — the months of waiting, during which the manual work keeps costing you. If what you need is one automation or a simple register, you come out ahead doing it with your own money right away.

Second: when you shape the scope around the call instead of around the company. You can spot it in the sentence "maybe let's add this too, it qualifies". Nobody needs those extra modules, but they still have to be signed off, paid for and maintained. Funding towards something you won't use is still spending.

Third: when the process inside the company is chaotic and the program is meant to fix it. It won't. Software mirrors how you work — chaos included, only faster and in several places at once.

And last: when you don't have the cash for your own contribution and for carrying the project until the money is reimbursed. A grant lowers the cost; it rarely defers payments.

But if the scope is real, the process is described, and the funding takes part of the cost off a program you'd build anyway — that's exactly what this money exists for.

The implementation plan as a document that goes into the application

All of it comes down to one thing: before the application you need a written scope, a timeline and a price. Not after the decision, not after the tender. Before.

That's why we treat the implementation plan as a separate, paid step: five days of work and one document with the written scope, a timeline split into stages, a fixed price in writing and sketches of the key screens. It costs 3 000 PLN net and comes back in full once we start the project. That document does three jobs at once: it describes the task in your application, it is the basis for the statement of work, and it stays yours — including when someone else ends up doing the rollout, or when the grant doesn't come through.

We don't write applications and we don't settle grants; that's a job for an advisor. We do the technical side: the description of what is to be built, and the program itself. There's more on our page about grant-funded rollouts, and if you want to check whether your idea can be described properly at all, book a free call. An hour before the application saves half a year of explaining at settlement.

Adrian Hunia — co-founder of SEVENEDGE. Builds software for small manufacturing and service companies, including Relay, a production order management system.