ProofDevs
Specialists for this

Get an independent review before you sign or continue

Free analysisNo commitment2 min

Choose what needs an independent review

Proposals

Comparing offers written in different shapes

Suppliers structure proposals however they like, which makes direct comparison impossible until you normalise them. Here is how to get them onto the same axis.

Proposals

How to read a development proposal

The price is the last thing to look at. Four other things tell you far more about whether the project will finish on time, and all of them are visible before you sign.

Requirements

How to write an RFP suppliers can answer

Most RFPs fail in the same way: they specify a solution instead of a problem, and they leave out the constraints that would actually change a supplier's answer.

Proposals

Warning signs in a proposal

Every one of these is visible before money changes hands. None of them is proof of anything on its own; two or three together is a pattern worth acting on.

Estimates

Have someone read the quote who is not selling to you

An independent engineer goes through the estimate line by line and tells you what each item actually involves, whether the days are plausible, and which parts of the work are not in the document at all.

Requirements

Check these before the RFP leaves your desk

Four groups of checks. Each corresponds to a specific way that RFPs come back with proposals you cannot compare against each other.

Requirements

A worked example, annotated

A realistic brief for a small internal system, with a note on each section explaining what it does for the supplier and what a weaker version would have cost.

Requirements

An RFP template short enough to be used

Six sections with a note under each explaining what a supplier does with it. Copy the headings, delete the notes, fill in your case.

Requirements

Do you actually need an RFP?

A request for proposal is a good tool for a narrow set of situations and a waste of several weeks for everything else. Here is how to tell which one you are in.

Independent audit

Get an Independent Second Opinion Before You Rebuild

Developers often reflexively recommend rebuilding existing code from scratch because reading others' code is hard. Get an unbiased assessment of whether your software truly needs a rewrite or just targeted refactoring.

Related paths

If this is not quite your situation, start with the path that matches what you need next.

Understand developer rates

Separate hourly rates, estimated effort and agency overhead before comparing proposals.

Review a stalled project

Move from checking the proposal to planning a safe takeover of an existing codebase.

Hire under a clear cap

Use hourly or part-time terms when the work needs flexibility instead of a fixed project quote.

Why the person quoting cannot be the person checking

Every technical opinion you receive from someone who wants the contract is, unavoidably, also a sales document. That does not make it dishonest — it makes it unverifiable by you.

A review is worth having precisely because the reviewer is not competing for the job. Their only output is an assessment you can take to any supplier, including the one who gave you the quote.

What a quote should let you check

The number at the bottom is the least informative part of a quote. What matters is whether the structure underneath it can be argued with.

  • Work broken into items you can recognise, not one line reading 'development'.
  • Hours or days per item, so the rate and the effort are separable.
  • A stated assumption list — what the price depends on being true.
  • What happens when something takes longer than expected, agreed in advance.
  • What you own at the end, written down: code, accounts, designs.

The signals that a proposal is trouble

A few patterns show up again and again in projects that later go wrong, and all of them are visible before any money changes hands.

  • A total price with no breakdown, offered before anyone examined the existing system.
  • A rewrite recommended within the first conversation.
  • Timelines with no dependency on anything you have to provide.
  • Reluctance to name who will actually do the work.
  • Ownership of the code left unstated, or assigned on final payment only.

Reviewing a codebase you already own

The same logic applies to code you have already paid for. An independent read tells you whether what you own is a reasonable foundation, and gives you a concrete list of what to fix — which is useful whether you keep your current developer or not.

It is also the cheapest form of insurance before an acquisition, an investment round, or handing the project to a new team.

What the review should help you decide

A useful review ends with a decision, not just a list of technical observations. You should know whether to accept the proposal, renegotiate its assumptions, pause the work, or move the project to another developer.

That makes Review the right starting point before a new build, before a takeover, or whenever a quote feels too vague to approve.

Common questions

Will the reviewer try to win the work themselves?

No. Reviews are deliberately assigned to engineers who are not candidates for the project, because the value of the opinion depends on that.

What do I actually receive?

A written assessment in plain language: what the quote or code implies, what looks reasonable, what does not, and what to ask before you sign.