Skip to content
Free assessment · Methodology v1

Build-Ready Scope Grader

Most software projects do not fail in code. They fail in the decisions that were never made. Score your project’s readiness, see the decisions blocking the build, and put a number on the cost of scope ambiguity.

4 minutes 16 questions No email required Shareable report
1

What are you building?

The archetype sets the base planning band. It does not change your score.

2

Budget and timeline

Used to compare your expectation with the planning range. Optional.

3

The decisions behind the build

Answer honestly. A low score is useful; a flattering score is not.

Problem & outcome weight 15%

A written problem, a measurable outcome, and a way to know whether the work succeeded.

Can you state the problem and the measurable business outcome in one sentence each?

A good outcome names a number, a direction, and a date.

How will you know the project succeeded six months after launch?

Name the metric, the baseline, the target, and who reviews it.

Scope boundaries weight 15%

Explicit non-goals, deferrals, and a change process that protects the first release.

Is there an explicit list of what is out of scope for the first release?

Non-goals are as useful as goals: they protect the date and the budget.

If a stakeholder requests a new feature mid-build, what happens?

The process should force a trade-off, not just record a wish.

Functional depth weight 15%

Core journeys written as steps, with edge cases and testable acceptance criteria.

Are the core user journeys written as steps with expected results?

Include the unhappy path: errors, empty states, and retries.

Does every important requirement have a testable acceptance criterion?

If two people could disagree about pass or fail, it is not testable yet.

Users & use cases weight 10%

Named user roles, their goals, and the permissions each role needs.

Do you know who the primary users are and what they need to accomplish?

Role, goal, frequency, and current workaround.

Have you mapped the permissions and data access each user type needs?

Especially for admin, support, finance, and external users.

Non-functional requirements weight 10%

Performance, availability, security, privacy, and accessibility expectations.

Do you have explicit expectations for performance, availability, and scale?

"Fast" is not a requirement. A number and a load assumption are.

Are security, privacy, and accessibility requirements written down?

Include data classification, retention, and who can export what.

Integrations & data weight 10%

Every external system, its owner, its contract, and who owns the data.

Do you know every external system the product must connect to?

Include owners, APIs, contracts, rate limits, sandboxes, and failure handling.

Who owns the data, and where does it live?

Ownership, export, deletion, backup, and what happens at exit.

Decision rights weight 10%

A named decision-maker, the roles needed to build and operate, and an escalation path.

Is there one named person who can approve scope, budget, and trade-offs?

A committee can advise. Someone still has to decide.

Does the team have the roles needed to build and operate the product?

Product, engineering, design, QA, operations, and a support owner.

Delivery controls weight 10%

Milestones, dependencies, a definition of done, review points, and a release gate.

Is there a delivery plan with milestones, dependencies, and a definition of done?

A calendar is not a plan. The plan should show what must be true at each gate.

Compliance & risk weight 5%

Applicable obligations, evidence, owners, and review dates.

Have you identified the regulations and risk obligations that apply?

Sector rules, data protection, accessibility, financial controls, or AI transparency.

0 of 16 answered

Your report unlocks when all 16 questions are answered.

Methodology v1

How the score and the estimate work

The tool is deliberately transparent. It is a planning instrument, not a quotation, and not an audit. Here is exactly what it does.

The readiness score

Sixteen questions are scored 0–4 and grouped into nine weighted dimensions. The weights are problem and outcome 15%, scope boundaries 15%, functional depth 15%, users 10%, non-functional requirements 10%, integrations and data 10%, decision rights 10%, delivery controls 10%, and compliance 5%. The weighted result is a score from 0 to 100.

Bands: Exposed 0–39, Developing 40–69, Build-Ready 70–100.

The planning range

Each archetype has a base planning band. The model adds a contingency that falls as readiness rises: clamp(60% − 0.5 pp × score, 10%, 60%), where score is 0–100. The result is the planning range. The contingency portion is reported separately as the cost of ambiguity.

Base bands are anchored to published market data, including Clutch’s 2026 pricing guide (average project around $132k over about 13 months; mid-market custom software commonly $75k–$250k; MVP work from $25k). Maintenance is budgeted at 15–25% of build cost per year. See our software cost guide.

What it is not

  • Not a quotation. A quote needs a defined scope and a commercial conversation.
  • Not a technical audit. It does not inspect code, infrastructure, or contracts.
  • Not a guarantee. It is a structured way to expose the decisions that usually drive cost.

Your data

The full report is visible without an email address. Completed assessments are stored as anonymized records: archetype, answer codes, dimension scores, aggregate score, budget band, timeline band, and a random completion id. No name, email address, IP address, or free-text description is stored in that record.

The aggregated dataset is public: dataset.json. The report URL contains only the assessment state, never personal data.

Questions about the grader

What is the Build-Ready Scope Grader?

It is a free assessment that scores how ready a software project is to build. Sixteen questions across nine dimensions produce a 0–100 readiness score, a risk breakdown, the decisions blocking the build, a modeled cost of scope ambiguity, a planning range, and a five-year total cost of ownership estimate.

How is the readiness score calculated?

Each question is scored from 0 to 4. Questions are grouped into nine weighted dimensions: problem and outcome (15%), scope boundaries (15%), functional depth (15%), users and use cases (10%), non-functional requirements (10%), integrations and data (10%), decision rights (10%), delivery controls (10%), and compliance and risk (5%). The weighted result is a score from 0 to 100. The model is methodology v1.

Is the planning range a quote?

No. It is a planning range, not a quotation. Base bands are anchored to published market data and adjusted by your readiness score. A quote requires a defined scope, a delivery model, and a commercial conversation. The tool is designed to show you the size of the uncertainty before you ask for a fixed price.

What is the cost of ambiguity?

It is a modeled contingency. At lower readiness scores the model applies a larger contingency to the base planning band, representing the work that unclear scope usually adds. It is not a measured statistic and it is not a discount. It is a way to put a number on the decisions that are still open.

Do I have to give my email address?

No. The full report is visible without an email address. The email field only sends you the report and its permanent link. There is no account, no newsletter, and no sequence.

Can I continue later or share the report?

Yes. Every answer is encoded in the report URL. Open the link later to continue, change an answer, or share the report with a teammate. The URL contains the assessment state only — never your name or email address.

What data do you store?

Completed assessments are stored as anonymized records: project archetype, answer codes, dimension scores, aggregate score, budget band, timeline band, and a random completion id. No name, email address, IP address, or free-text description is stored in that record. The aggregated dataset is published as JSON for anyone to cite.