How to request quotes for a funded digitalization project: the one-page brief that gets you comparable offers (and how we work from it)

Why quotes for the same project come back incomparable

Most requests for quotes are a two-line email: an order application, connected to the ERP, within the grant. Each supplier fills the gaps with its own assumptions, so three offers describe three different projects. The differences that matter are rarely in the total:

• Scope. One offer covers the whole order flow, another only the screens, a third adds a mobile app nobody asked for.
• Maintenance. One includes a year of support, another leaves it out without saying so.
• Licenses and hosting. Some offers include third-party licenses and cloud costs, others assume you already pay for them.
• Hours or deliverables. An offer priced in hours shows what the supplier spends and leaves out what you receive at the end of each stage.
• Ownership. Who owns the source code, the cloud accounts and the data after the project is often missing entirely.

With your own money, this is a nuisance. In a funded project, it becomes a problem with the file.

What the funding file asks of an offer

The rules below come from the applicant's guide for POCIDIF 2021-2027, Action 2.1 (new services, applications and products through innovation and advanced technologies, open to ICT SMEs), and from Order no. 1284/2016, the procurement procedure for private beneficiaries that the guide cites. Regional program guides have their own rules: check the guide of your call.

At application, the 2.1 guide asks for at least two price offers for each eligible expense, signed and dated by the issuer, or dated screenshots from official supplier sites. They are summarized in Annex 7, "Centralizator cantități și oferte" (summary of quantities and offers), which has one row per expense with these columns:

• expense category, unit and name of the product or service;
• minimum technical specifications;
• quantity and estimated unit price without VAT;
• supplier 1 and its unit price, supplier 2 and its unit price;
• the chosen offer and the reason for choosing it.

Evaluators check prices against the market on their own. Without two reasonable offers an expense is ineligible, and so is one where they suspect "formal offers" between the applicant, the bidders or the consultant who wrote the project. They also check that each bidder's field of activity matches what it quotes.

Two more rules shape the calendar. The guide requires an incentive effect: no purchase may start before the project is submitted, apart from application consultancy and project management. Asking for offers is part of preparing the file; signing a supply contract has to wait. During implementation, purchases follow Order 1284/2016: below the threshold, a direct purchase backed by a note on how the estimated value was set; at or above it, publication on fonduri-ue.ro ("Achiziții privați"), at least 6 days for supply offers and 10 for services, and an award note. A single compliant offer can be awarded. Every reimbursement claim carries the full procurement file: specifications, offers, award note, contract, acceptance reports and deliverables.

The one-page brief: eight questions

Send the same page to every bidder. It takes an afternoon and removes most of the differences between offers before they appear:

1. Which process are we changing, and what is wrong with it today? Describe one flow from start to end, for example from order to invoice, and where it stalls, gets typed in twice or depends on one person.
2. Who uses it, and how many? Roles and number of users per role, inside the company and outside it (customers, partners).
3. Which systems must it work with? ERP, CRM, e-Factura, online store, email, shared files. Name each system and say whether it has an API, if you know.
4. What is a must-have and what is a nice-to-have? Two separate lists. Bidders price the first; the second they price as options.
5. What must be delivered for reporting? Documentation, an acceptance report per stage, and what the technical audit will need to see. In 2.1, the last reimbursement claim comes with a technical audit report on conformity, security testing and GDPR.
6. What is the calendar? The submission date, the expected date of the financing contract, the implementation period of your call and any date you cannot move.
7. Who owns what at the end? Source code, cloud and license accounts, domain, data. Ask for all of them in the company's name.
8. Who runs it after the project? Your team, the supplier or a third party, and on what terms. In 2.1, maintenance after implementation is not eligible, yet the three-year sustainability period requires it at your own cost. Plan for it outside the budget.

What to ask every bidder to send back

Ask for the answer in the same structure, so each offer drops straight into the centralizator:

• The price per expense line, without VAT, using the same lines as your specification.
• Deliverables per stage, each with what you receive and how it is accepted.
• The calendar in weeks, counted from the contract signature.
• What is excluded: licenses, hosting, content, data migration, maintenance.
• The team: roles and who does what.
• The warranty: what it covers and for how long.
• Date, signature and how long the offer is valid.

For funding consultants: getting offers you can put in the application

Offers that survive the evaluators' price check share four traits:

• Write the specification per expense line, as it will appear in Annex 7. Custom software development for the order module, with minimum specifications, gets comparable answers; a line that says only digitalization does not.
• Send every bidder the same specification and ask for an answer line by line. Two offers for different scopes cannot justify one price.
• Ask real suppliers whose field matches the item. Evaluators check each bidder's activity against what it quotes.
• Check that every offer is dated, signed and states its validity before it goes into the file.

We are glad to receive specifications written this way. We answer them as a supplier, line by line, at the price we would actually work for.

When we decline

We decline when:

• We are asked to write the application. We do not write funding applications or consult on funds. We can be a supplier named in the file; the application belongs with a funding consultant.
• We are asked for a courtesy offer. Every offer we send is one we would sign a contract for. An offer sent only to fill the second column puts the applicant's expense at risk.
• The project starts from the list of eligible expenses instead of a process. When the scope is whatever the grant covers, the grant decides the project and the result comes second.
• The company has fewer than ten people and no clear growth constraint. A good freelancer will serve it better, and we say so.

The test from digitalization with or without EU recovery funds holds here too: would you do this project without the grant? What a funded project should contain in the first place is covered in SME digitalization with EU funds.

How we work from it

Without funding, we prefer to start with a conversation and an analysis, and to write the brief ourselves. A funded project has a submission date and needs specifications before any contract, so here we start from your brief:

1. You send the brief through the contact page. We reply within two working days.
2. A short call with the people who would do the work, to settle what the brief leaves open. No slides.
3. A written offer in the structure above: scope, deliverables per stage, calendar in weeks, what is excluded, team and warranty. Quoted in EUR, dated and signed. If the brief changes, the offer changes in writing.

The project then runs in our four phases, described on how we work. Diagnose comes first, after the financing contract: we map and measure the process. Design ends with a blueprint your team approves, with acceptance criteria. Build delivers working software in production, with demos at every iteration and acceptance testing on every flow. Scale, after launch, is quoted separately, outside the funded budget.

Each stage closes with an acceptance report you can add to the reimbursement file. The documentation covers requirements, architecture, tests and security, which is what a technical audit asks to see. Code and accounts are in your company's name, and any bug after launch is covered by a 12-month warranty. How the price itself is built is explained on how we price.

Summary

• Offers differ in scope, maintenance, licenses, hours and ownership long before they differ in price.
• In POCIDIF 2.1, each eligible expense needs two signed, dated offers answering the same specifications. Check your own guide.
• Eight questions and a fixed answer structure make offers comparable and ready for the file.