ro

Review your software proposal before you sign

Find what your development proposal may be missing.

A development proposal is the cheapest document in the whole project and the most expensive one to read badly. The parts that hurt later are almost never wrong; they are absent. Nobody signs a contract intending to lose their repository. They sign one that does not mention it.

This review reads a proposal against a fixed list of questions every proposal has to answer, and reports what the document did not say as clearly as what it did.

Who this is for

It is built for one situation: you have a real proposal in front of you and a decision to make about it.

  • a founder or co-founder who has been sent a quote and cannot judge the technical half of it
  • a CTO or technical lead choosing between external vendors
  • an owner of a product that already exists, considering a change of vendor
  • anyone comparing two or three proposals that were written to different briefs
  • fintech, investment, private-market and other products where money, data or a regulator raise the cost of a missed requirement

It is not built for a landing page quote or a small e-commerce job. The questions below would be overkill and the review would tell you so.

What is checked

Twenty-five questions, weighted, of which five are treated as critical: a proposal that leaves any of those unanswered cannot score well however good the rest of it is. Scoring is arithmetic, not opinion, and the method is shown with the result.

01

Scope

What is included, what is explicitly excluded, and what is neither. The third category is the one that becomes a change request.

02

Ownership and rights

Who owns the source, the repository and the infrastructure; who holds the backups; when intellectual property assigns, if it does. All five are treated as critical questions.

03

Exit and continuity

What happens if you leave, or they do. Handover contents, access, and whether another team could pick this up.

04

Commercials beyond the headline

Recurring costs, third-party costs, the payment schedule, and dependencies that turn into somebody else's invoice.

05

Support, SLA and security responsibility

What is included after delivery, what is a separate contract, and which security obligations sit with whom.

06

Delivery realism

Architecture, stack, team, timeline, declared assumptions and declared risks — and whether the timeline is consistent with the scope.

Where this stands today

The Analyzer is not open for self-service yet. The review described above is not a plan — it runs today inside FinMV Workspace, on a project, against the same list of questions. What is missing is the door: a way to use it without an account, and the published data-handling description that has to come before anyone hands over a commercial document.

Ask about a proposal

What it cannot do

  • It is not a legal review. It reads a commercial and technical document, not your jurisdiction's contract law.
  • It does not price your project or estimate what the missing scope will cost. A number invented from a document is worse than an acknowledged gap.
  • It cannot certify a vendor, or tell you that one is good. It can tell you what they did not commit to in writing.
  • It cannot verify anything the proposal does not contain. A proposal that says little produces a review that says the proposal says little.
  • It is not a security assessment of the vendor or of what they would build.
  • A model reads the document; nothing it read is treated as confirmed until you confirm it. Values are shown next to the sentence they came from.