Skip to content

Software requirements and vendor selection: someone on your side, through to acceptance.

For companies in Europe about to put real money in front of a software vendor. We write the requirements and acceptance criteria, run the RFP, and challenge the bids.

Tell us about your projectReply within 48 hours

What does a software requirements and RFP consultant do for you?

They turn your business need into documents that bind the other party: the requirements, the acceptance criteria, the request for proposal and the comparison of bids. Then they check the delivery against those documents, line by line, before anyone signs acceptance.

In France the role has a name, project owner assistance. In English you buy the deliverables, so this page is organized around them. What matters is who writes them: the requirements come from the people doing the work, not only from those commissioning it, because the workarounds they have built are the map of the real requirements.

For a buyer with European customers, the requirements also carry the European rules as testable conditions: where the data must be hosted, which sub-processors are acceptable, what gets logged and for how long. Written as acceptance criteria, they stop being a question in a vendor questionnaire and become a line a vendor signs.

Four documents, and they are yours.

Not a methodology deck: four artifacts that bind the other party, and keep working after we leave.

  1. Before the RFP

    Requirements a manager can read and a developer can build from.

    The real processes, the edge cases, and explicitly what is out of scope, gathered from the people who do the work.

  2. Before the build

    Acceptance criteria that settle whether it is finished with a yes or no.

    The section almost nobody writes, and the one that decides how the project ends. Without it, acceptance happens when everyone is tired.

  3. Bids in

    A comparison grid, with the awkward questions asked.

    Exclusions read before inclusions, and the technical questions a supplier does not expect, which is where the value concentrates.

  4. Delivery

    Acceptance signed against what was written.

    Edge cases and real data volumes tested, each gap qualified against the criteria, a delivery defect kept apart from a new request.

An empty meeting room with a long table and laptops (illustration photo)

Where your vendor's quote hides the real cost.

Most bids are honest and still misleading, because the expensive part sits in what the estimate does not say. Three places to read before the total.

Read the exclusions before the inclusions.

  • The integration missing from the estimate.The connection to your accounting or customer tool, assumed to exist, priced nowhere.
  • The data migration in one line.Mentioned in passing, and often a third of the real work.
  • The hosting and data terms.Where the data runs, under which contract, and what leaving costs.

If the scope goes out to bid, we do not bid.

A firm that writes your selection criteria and then competes against them is in a conflict of interest. It is not a question of morals, it is structural. So the rule is stated before signing, and a firm without a clear answer on that point has told you something.

  • You want us to build instead?Then we are your supplier, we say so, and this role stays with you or goes to a third party.
  • What never happensHolding both positions on the same money.

Who should write your requirements: what each option protects.

An engineer on your side, the vendor and a functional consultant writing the requirements, compared on four criteria
An engineer on your side, the vendor and a functional consultant writing the requirements, compared on four criteriaAn engineer on your sideThe vendorA functional consultant
Whose interest the document servesYours: nothing to sell on the projectIts own product, inevitablyYours, within the workshop
Challenges a technical estimateYes: has built this kind of systemIt wrote the estimateRelays the answer
Acceptance criteriaWritten before the build, testableWritten around what the product doesOften left for the end
Right whenReal money, several departments, a migrationThe product is chosen and only needs configuringThe problem is organizational, not technical

100%platform uptime over the program

Expertise France engagement, case studies page

Expertise France, French government development agency

A written condition, held all the way to delivery.

The problem
Cameroon's national addressing infrastructure had to be delivered with the source code and the hosting under the country's control, and the institution made that condition non-negotiable.
What was delivered
On this program we were the builder, and the condition held: the addressing base in production, the sources handed over so the country could host it, a local project manager and two local developers recruited and trained.
Read the case studies

Who handles your project, from the need to acceptance.

Laurent Tulpan scopes the engagement and holds the pen on the requirements; he has written code and led architectures, which is why he can read a technical estimate as its author would. Clairmont reviews the answers that touch infrastructure and integrations. Measured in July 2026, across every engagement delivered since 2019: no client has had to call us back on an emergency after handover. The few follow-on contracts extended a warranty or widened the knowledge transfer, never to repair something we had left behind.

  • Laurent Tulpan, founder of Coeur du WebLaurent, founder and CTOGathers the need, writes the requirements and the acceptance criteria, runs the steering meetings.
  • Clairmont, technical leadClairmont, technical leadChallenges the technical estimates: integrations, data migration, hosting.

What you sign for vendor selection, in short.

Price
A fixed fee on defined deliverables, set by a short scoping of your project, never by a grid.
Deliverables
Requirements, acceptance criteria, RFP, comparison grid, acceptance report: yours.
Independence
We do not bid on a scope we wrote.
End
The engagement stops when acceptance is signed.
How we work, and the limit of each commitment

RFPs, vendors, small projects: what buyers ask us.

What does an RFP consultant actually do?

On a software project, three things:

  • Write the requirements and the acceptance criteria from the people doing the work.
  • Write the request for proposal around them: what bidders must price, what they must disclose, how they will be compared, and the deadline.
  • Then read the bids line by line, exclusions first, and hold the chosen vendor to the statement of work through to acceptance.
Why not let the vendor write the requirements?

Because a supplier makes its living from its own solution. Asked to write your requirements, it will inevitably produce a document describing what its product already does.

That is not dishonesty, it is a mechanical bias, and the result is a need shaped around an offer instead of an offer chosen for a need.

The requirements come from you, or from someone with nothing to sell you.

Do you write the RFP itself, or only the requirements?

Both, and they are different documents. The requirements describe what the system has to do and how acceptance will be judged. The request for proposal wraps that in the commercial frame.

Plenty of RFPs fail not because the requirements were weak but because the RFP never told bidders what comparison they were entering.

We also review the statement of work before signature, since that is the document you will hold the winner to.

Does the person doing this need to be technical?

On a software project, yes, and it is the criterion that matters most.

Most people in this role come from functional consulting: they run a workshop well and hold a schedule, which is useful and insufficient.

When a supplier says an interface cannot do what you asked, or that a data migration will take three months, someone without build experience can only relay the answer. They become a conduit rather than a counterweight.

How is this priced?

On a fixed fee, for defined deliverables:

  • the requirements
  • the acceptance criteria
  • the RFP
  • the comparison grid
  • the acceptance report

The fee comes out of a short scoping of your project, never from a grid, and we do not publish it. The engagement ends when acceptance is signed.

Is this worth it on a small project?

Not always, and a straight answer matters more than a sale. Below a certain budget, this costs more than it protects.

It earns its place as soon as there is real money at risk with a supplier, several departments to reconcile internally, or a data migration to work out.

If your case does not justify it, a short scoping exercise is enough to write the requirements and the acceptance criteria, and you go to market on your own.

And if it is ours to build?

Then we stop sitting on your side of the table and become your builder, on the other half of our work.

Build and automate

Software, automations and AI hosted in the EU, sources in your name.

Closer to your case

All services

A project to scope, or a quote to read?

20 minutes to qualify the situation. If this is not the right format for you, we will say so and point you to what is.

Tell us about your project

Reply within 48 hours