The Four-Minute Mile

A proposed benchmark for noncoder-built software

Hosted by Standing

Proposed scorecard, version 0.1

The four-minute mile of vibe coding

Someone has likely crossed this finish line. Defining it would help us recognize them and give everyone else a target.

We should be able to describe what a noncoder has achieved across four areas: build it, prove it, run it, and make it matter.

Each lap has five proposed levels. Five minutes recognizes a first accomplishment. One minute is the target. A four-minute mile means reaching that target in all four laps.

The minutes are scores, not development time. These are proposed benchmarks, not official standards or certification.

For this proposal, a noncoder is someone who cannot independently write or review the implementation. Outside engineering help should be disclosed.

The scorecard

Open any level to see what it asks.

Lap 1

Build it

Can people use it to do what it promises?

Lap 2

Prove it

Does the engineering support what the user sees?

Lap 3

Run it

Does it keep working as people use it and you improve it?

Lap 4

Make it matter

Does the product deliver value people actually use?

Reading the score

Choose the fastest level supported by the evidence for each lap.

For example:

Build it 2 + Prove it 3 + Run it 2 + Make it matter 4 = an eleven-minute mile.

If a lap has not been assessed, leave it unscored and do not calculate a complete time. Missing evidence is not proof that a product fails.

A strong result in one lap cannot replace another. Revenue does not establish security, and technical quality does not establish usefulness.

Assess your own product

Use this prompt with the AI assistant that has access to your project. It gathers evidence for the four laps without changing your product. Bring the results back to the scorecard and see what they support.

Reusable template. Replace [product name] before sending.

Show the full prompt 
I want to assess [product name] against the Four-Minute Mile, a proposed scorecard for noncoder-built software. The scorecard is summarized below, so you do not need to look it up.

This request is read-only. Do not change code, configuration, data, or infrastructure. Do not run disruptive tests or start new tests against the live product. Use existing evidence and inspection only.

Where existing evidence does not settle a question, leave it unknown. Do not invent, estimate, or assume evidence.

About the scorecard

The scorecard and its thresholds are a proposal open for debate. They are not an established standard, certification, or official benchmark.

It has four laps. Each lap has five proposed levels, named in minutes. 5 minutes recognizes a first accomplishment; 1 minute is the target. The minutes are scores, not development time. A lap’s time is the fastest level its evidence fully supports. A lap without enough evidence stays unscored, and a strong lap cannot make up for another. A complete mile time is the sum of all four lap times, so a four-minute mile means reaching 1 minute in every lap.

For this proposal, a noncoder is someone who cannot independently write or review the implementation. Outside engineering help should be disclosed.

Lap 1. Build it: can people use it to do what it promises?
Success means the person finishes the task and understands the result without the builder stepping in. Instructions built into the product count as part of the experience.
- 5 minutes: The builder can demonstrate one main task.
- 4 minutes: Someone else completes one main task without help.
- 3 minutes: Five intended users try the main tasks. Each task succeeds at least 80% of the time.
- 2 minutes: Ten intended users try the complete workflow. Each main task succeeds at least 90% of the time.
- 1 minute: Twenty intended users try the complete workflow. Each main task succeeds at least 95% of the time, including correcting mistakes along the way.

Lap 2. Prove it: does the engineering support what the user sees?
The checks cover results, saved information, privacy and access, failure handling, and whether the implementation can be maintained. The builder proposes the checks, and the reviewer can challenge their scope. For independent verification, both should agree that the checks address the product’s important claims and risks.
- 5 minutes: An initial technical review identifies strengths, problems, and unanswered questions.
- 4 minutes: The builder records the checks, findings, and evidence.
- 3 minutes: Checks of the implementation behind the main tasks pass, including calculations, saved information, and access restrictions. Remaining gaps are identified.
- 2 minutes: The product passes the agreed engineering and security checks.
- 1 minute: Someone independent of the build examines the assessment and verifies its results.

Lap 3. Run it: does it keep working as people use it and the builder improves it?
A successful attempt means someone completes a main task correctly within an acceptable time; a page loading is not enough. Recovery means bringing the product back into working order and checking its information after a failure, and controlled exercises count. A meaningful update changes a feature, calculation, data handling, security control, or dependency. Cosmetic changes alone do not count. Count updates made during the observation period for that level.
- 5 minutes: The product runs in its development environment.
- 4 minutes: It is deployed online, with its main tasks demonstrated in production.
- 3 minutes: It operates for 30 days, with 99% of main-task attempts succeeding and recovery demonstrated within 24 hours. The builder makes one meaningful update.
- 2 minutes: It operates for 90 days, with 99.5% succeeding and recovery demonstrated within four hours. The builder makes five meaningful updates.
- 1 minute: It operates for 180 days, with 99.9% succeeding and recovery demonstrated within one hour. The builder makes ten meaningful updates, and at least nine need no urgent repair or reversal.

Lap 4. Make it matter: does the product deliver value people actually use?
A product can complete this lap through any one of these routes. Funding and valuation do not count.
- Product revenue over a year: 5 minutes, first paying customer; 4 minutes, $1,000; 3 minutes, $5,000; 2 minutes, $25,000; 1 minute, $100,000.
- Monthly active users, paired with the percentage of users returning during days 61–90 after first use. Both targets apply at each level: 5 minutes, 10 users and 10%; 4 minutes, 100 and 15%; 3 minutes, 500 and 20%; 2 minutes, 2,500 and 25%; 1 minute, 10,000 and 30%.
- Used to run a business: 5 minutes, someone uses it for real work; 4 minutes, a team uses it regularly; 3 minutes, it runs a business process for 3 months; 2 minutes, it runs that process for 6 months; 1 minute, a business depends on it for 12 months.
- People achieving a meaningful public-benefit outcome in a year: 5 minutes, 1; 4 minutes, 10; 3 minutes, 100; 2 minutes, 500; 1 minute, 1,000.

What to gather

1. Build it: List the main user tasks in [product name]. Identify any existing evidence of people outside the build completing them without assistance and understanding the results. Separate observed use by real users from automated tests and from the builder’s own testing. Paid or incentivized participation alone does not establish that people used or understood the results.

2. Prove it: Summarize the current evidence that calculations and results are correct; information is saved, changed, and deleted as intended; access restrictions and privacy protections work; failures are handled without misleading results or damaged records; and the implementation can be understood and maintained. Distinguish what code inspection shows from behavior verified by existing test results. Give dates or versions for those results where available. List unresolved findings without exploitable detail.

3. Run it: Identify existing evidence of how long the product has operated; successful and failed main-task attempts; production updates, urgent repairs, and reversals; and backup restoration or other recovery exercises. Separate monitoring that exists from measurements actually collected. Separate recovery procedures from recovery that has been demonstrated.

4. Make it matter: Identify any evidence of revenue, active use, return visits, business use, or useful outcomes. Distinguish seeded or test data, paid participation, test accounts, and ordinary users where possible.

Report format

For each lap, provide:
- What the evidence supports, with each item labeled as code inspection, existing test results, observed use (say whether by the builder or by others), or missing evidence.
- The fastest proposed level that existing evidence fully supports, or “unscored” if the evidence supports no level or is unknown.
- What the next faster level requires that is not yet met or not yet known.
- Where that evidence comes from, described in general terms.
- The smallest additional check that could resolve each important gap.

Do not round up a level, and do not fix anything as part of this request. Clearly distinguish facts, inferences, and missing evidence. Give a complete mile time only if every lap has a supported level, and label it a self-assessment against proposed thresholds.

Make the report safe to share. Leave out credentials, keys, personal information about users or workers, internal addresses and file paths, and detailed security weaknesses.

End with the product version or commit reviewed and the assessment date.

This review gathers evidence for a self-assessment. It does not independently verify or certify [product name].
Lap 1

Build it

Can people use it to do what it promises?

This is the user’s assessment. They should be able to complete the product’s main tasks and understand the results without the builder walking them through it.

Build it: proposed achievement at each time level
TimeProposed achievement
5 minutesThe builder can demonstrate one main task.
4 minutesSomeone else completes one main task without help.
3 minutesFive intended users try the main tasks. Each task succeeds at least 80% of the time.
2 minutesTen intended users try the complete workflow. Each main task succeeds at least 90% of the time.
1 minuteTwenty intended users try the complete workflow. Each main task succeeds at least 95% of the time, including correcting mistakes along the way.
What counts as success?

The person finishes the task and understands the result without the builder stepping in. Instructions built into the product are part of the experience.

The tasks should reflect what people actually came to do. Creating an account is not enough if the product’s purpose is to help someone prepare a report or compare career information.

Why these targets?

One person succeeding shows that someone besides the builder can use it. More people completing more of the workflow gives us stronger evidence that the experience works.

The proposed one-minute target is twenty people and 95% success. We should debate whether that is enough and whether different products need different targets.

This lap establishes that people can use the product. The next asks whether they can trust what happens behind it.

Lap 2

Prove it

Does the engineering support what the user sees?

A convincing screen could display invented results. A saved answer could disappear later. Information that looks private could be accessible to another account.

This is the engineering assessment: whether the implementation actually supports the product’s promises.

Prove it: proposed achievement at each time level
TimeProposed achievement
5 minutesAn initial technical review identifies strengths, problems, and unanswered questions.
4 minutesThe builder records the checks, findings, and evidence.
3 minutesChecks of the implementation behind the main tasks pass, including calculations, saved information, and access restrictions. Remaining gaps are identified.
2 minutesThe product passes the agreed engineering and security checks.
1 minuteSomeone independent of the build examines the assessment and verifies its results.
What would we check?
  • Results: Are answers produced from the right information using the intended calculations?
  • Information: Is it saved, changed, and deleted as promised?
  • Privacy: Can people access only what they are allowed to access?
  • Failures: Does the product handle problems without silently losing information or presenting misleading results?
  • Structure: Can someone understand how it works well enough to maintain and change it?

Existing software quality measures and OWASP’s application security checks give us a foundation. We should use them to define an assessment appropriate to the product.

The builder proposes the checks, and the reviewer can challenge their scope. For independent verification, both should agree that the checks address the product’s important claims and risks.

What would independent verification involve?

It could mean reviewing code, repeating tests, or examining an isolated version containing fictional information. It should not require giving a stranger production credentials or private user data.

AI can help throughout. The important distinction is between receiving another reassuring opinion and producing evidence someone can check.

The one-minute target is credible independent verification. Making that affordable is the biggest unresolved challenge in this lap.

Lap 3

Run it

Does it keep working as people use it and you improve it?

A launch shows that a product can go live. An operating record shows whether people can depend on it.

We could measure this through successful use, updates, and recovery when something fails.

Run it: proposed achievement at each time level
TimeProposed achievement
5 minutesThe product runs in its development environment.
4 minutesIt is deployed online, with its main tasks demonstrated in production.
3 minutesIt operates for 30 days, with 99% of main-task attempts succeeding and recovery demonstrated within 24 hours. The builder makes one meaningful update.
2 minutesIt operates for 90 days, with 99.5% succeeding and recovery demonstrated within four hours. The builder makes five meaningful updates.
1 minuteIt operates for 180 days, with 99.9% succeeding and recovery demonstrated within one hour. The builder makes ten meaningful updates, and at least nine need no urgent repair or reversal.
What counts as successful operation?

People can complete the product’s main tasks correctly within an acceptable time. A homepage loading does not tell us whether someone could finish what they came to do.

The number of attempts matters too. A product handling a hundred tasks and one handling a million should show that difference alongside their percentages.

Real-user activity and automated checks should be distinguishable. Missing monitoring data should remain visible.

Can it handle change?

The product should also demonstrate that it can improve without repeatedly breaking.

The three fastest levels include one, five, and ten meaningful updates, respectively. At the one-minute level, at least nine of those ten updates should need no urgent repair or reversal.

A meaningful update changes a feature, calculation, data handling, security control, or dependency. Cosmetic changes alone do not count. Count updates made during the observation period for that score.

Routine updates should not restart the operating clock. Important changes should be disclosed so readers can understand which evidence still applies.

Can it recover?

Recovery means bringing the product back into working order and checking its information after a failure. Restoring a backup or reversing a faulty update would be practical examples.

These can be controlled exercises. We do not need to wait for a real outage to find out whether recovery works.

Six months of dependable operation feels like a meaningful finish line. The proposed percentages and recovery times give us something to debate, with the product’s workload and purpose in view.

Lap 4

Make it matter

Does the product deliver value people actually use?

A product can work beautifully without making much difference to anyone. This lap should recognize the value it creates.

There should be several ways to complete it. Revenue is one. Sustained use, helping a business operate, and public benefit should count too.

Make it matter: the routes and their targets at each time level
Route5 minutes4 minutes3 minutes2 minutes1 minute
Product revenue over a yearFirst paying customer$1,000$5,000$25,000$100,000
Monthly active users101005002,50010,000
Returning during days 61–9010%15%20%25%30%
Used to run a businessSomeone uses it for real workA team uses it regularlyRuns a business process for 3 monthsRuns that process for 6 monthsA business depends on it for 12 months
People achieving a meaningful public-benefit outcome in a year1101005001,000

Product revenue over a year

TimeTarget
5 minutesFirst paying customer
4 minutes$1,000
3 minutes$5,000
2 minutes$25,000
1 minute$100,000

Monthly active users and users returning during days 61–90

TimeMonthly active usersReturning during days 61–90
5 minutes1010%
4 minutes10015%
3 minutes50020%
2 minutes2,50025%
1 minute10,00030%

Used to run a business

TimeTarget
5 minutesSomeone uses it for real work
4 minutesA team uses it regularly
3 minutesRuns a business process for 3 months
2 minutesRuns that process for 6 months
1 minuteA business depends on it for 12 months

People achieving a meaningful public-benefit outcome in a year

TimeTarget
5 minutes1
4 minutes10
3 minutes100
2 minutes500
1 minute1,000

Monthly active users and users returning during days 61–90 are paired requirements. Each level on this route needs both targets.

People pay for it

Revenue gives us a straightforward indication that someone values the product enough to buy it. We could start with the first customer and work up to $100,000 collected in a year.

That would demonstrate commercial appeal without requiring every builder to chase venture-scale growth.

People keep using it

For a free product, sustained use may say more than revenue.

This route pairs monthly active users with the percentage returning during days 61–90 after first use, and both apply at every level. The one-minute target would be 10,000 active users and 30% retention. Someone using the product to accomplish its main task tells us more than someone opening the homepage.

Some products solve a problem once, so repeat use would not be the right measure for every solution.

A business depends on it

A noncoder could build something that becomes part of how a company operates without ever selling it as a separate product.

The progression here is from someone using it for real work to a business depending on it over time. That could be scheduling, inventory, financial reporting, or another process the company needs.

Twelve months of that dependence feels like a meaningful achievement. The size and importance of the process would give the number context.

People benefit from it

A product might help people access benefits, gain a qualification, find work, or achieve another worthwhile outcome.

We could count people reaching that outcome, starting with one and building toward 1,000 in a year. We would need to explain what changed for those people and how the product helped.

The outcome matters as much as the count. Helping ten people achieve something life-changing may deserve more recognition than making a small task easier for a thousand.

What about funding and valuation?

They tell us that investors see potential. They belong in the story, but this lap focuses on value already delivered.

These are different ways of making something matter. The proposal is that a product could finish this lap through any one of them. The numbers give us something concrete to discuss: are these comparable achievements, and where should the targets sit?

Builder assessments

Here is how builders assess their own products against the proposed scorecard. Each entry distinguishes what has been demonstrated from what still needs checking. A self-assessment is a starting point for review, not an endorsement.

Builder-reported

Standing

Builder self-assessment; not independently verified. Overall time not yet established.

mystanding.ai

Status
Builder self-assessment; not independently verified
Evidence reviewed
November 11, 2026
Version reviewed
830d887
Overall time
Not yet established
How this assessment was made

Who performed it

The builder used AI assistants to inspect the implementation and assemble the evidence. Another AI helped compare the report with this proposed scorecard. No independent human engineering review has been completed.

What was examined

Checked directly on November 11, 2026

  • The code behind the main tasks, including the calculations, privacy limits, and how information is saved and deleted.
  • Read-only totals from the live database: accounts, completed question sets, anonymous visit counts, and AI request records. Only totals were reported.
  • The hosting providers’ deployment history, recent operating logs, and backup settings.
  • The code repository’s record of automated checks.

Taken from earlier notes, not repeated

  • The most recent automated test run, from November 7.
  • Founder walkthroughs, earlier AI reviews, their findings, and the corrections made.
  • How study participants were recruited and paid.

What was not established

  • Whether anyone outside the build has completed the current main tasks without help and understood the results.
  • Direct tests of several important behaviors across complete workflows.
  • Task success rates in everyday operation, which are not yet measured.
  • A demonstrated restore from backup.
  • Sustained use or useful outcomes beyond paid participation.
  • Any independent human engineering review.

Prompts used

The historical record: the two requests sent to the AI assistant that reviewed Standing on November 11, 2026. Neither contained credentials, personal information, or implementation details, so both appear exactly as sent.

Initial request, used for Standing

Public version of the assessment prompt

I’m developing a proposed “four-minute mile” scorecard for noncoder-built products with another AI. We want to assess Standing’s current state before making changes.

This request is read-only. Do not change code, configuration, data, or infrastructure. Do not run disruptive tests or initiate new production tests. Use existing evidence and code inspection.

Please produce a concise Markdown report covering these four areas:

**1. Build it: the user’s experience**

List Standing’s main user tasks. Identify any existing evidence of people completing them without assistance and understanding the results.

Separate actual user observations from automated tests and my own testing. Paid survey participation alone does not establish that participants used or understood their Standing results.

**2. Prove it: the implementation**

Summarize the current evidence that:
- Calculations and comparisons produce correct results.
- Information is saved, changed, and deleted as intended.
- Access restrictions and privacy protections work.
- Failures are handled without misleading results or damaged records.
- The implementation can be understood and maintained.

For each area, distinguish implementation found in code from behavior verified by tests. Include relevant file references, existing test results, dates or versions where available, and unresolved findings.

**3. Run it: the operating record**

Identify existing evidence of:
- How long the product has operated.
- Successful and failed main-task attempts.
- Production updates, urgent repairs, and reversals.
- Backup restoration or other recovery exercises.

Separate monitoring capabilities from measurements actually collected. Separate recovery procedures from recovery that has been demonstrated.

**4. Make it matter: actual use and value**

Identify any available evidence of revenue, active use, return visits, business use, or useful outcomes. Distinguish seeded contributions, paid participation, test accounts, and ordinary users where possible.

**Report format**

For each area, provide:
- What the evidence supports.
- Where that evidence is located.
- What remains unknown.
- The smallest additional check that could resolve each important gap.

Do not assign a score yet. Do not fix gaps as part of this request. Clearly distinguish facts, inferences, and missing evidence. Exclude credentials, personal worker information, and other secrets from the report.

End with the product version or commit reviewed and the assessment date.
Clarification request, used for Standing

Public version of the assessment prompt

Thank you. We are using the report to assess the current product, not requesting fixes yet.

Please clarify three points without changing anything:

1. For each unresolved security finding, distinguish a confirmed weakness in the live product from disabled code, an untested possibility, or a documentation issue. Identify any finding you consider critical and explain why.

2. Which existing test results remain applicable to the current main tasks? Identify the most important current claims that have no direct behavioral test. Do not use total test count as a substitute for coverage.

3. Does existing evidence establish that anyone outside the build has completed a main task on the current public version? If not, leave that unknown.

Please keep the response short. Do not include credentials or personal data.

How the results were used

The reports were compared with the proposed lap requirements. Unsupported claims remained unverified, and no complete mile time was assigned.

These prompts document the assessment process. They are not evidence that a product passed.

Standing uses information shared anonymously by workers to help people make more informed career decisions based on their standing in the job market. It was built by a noncoder with AI assistants.

Builder-reported summary, lap by lap

Build it

Demonstrated so far

Founder walkthroughs and paid participants completing the questions on earlier versions.

Still to establish

Intended users completing the current main tasks without assistance and understanding their results.

Prove it

Demonstrated so far

Repeated AI reviews, documented findings and corrections, and rule-level tests covering parts of the calculations, privacy protections, and information handling.

Still to establish

Verification of important behaviors across complete workflows and an independent engineering assessment.

Run it

Demonstrated so far

The engine has been deployed since July 2026. Of 77 deployment attempts, four failed before going live. Three of those left an existing version serving; the first occurred before initial launch. A separate September update caused about ten minutes of downtime before recovery.

Still to establish

Complete task-success measurements over the proposed observation period and a demonstrated backup restore.

Make it matter

Demonstrated so far

Paid contributions seeded the comparisons before launch, giving new visitors information to compare against.

Still to establish

Evidence of useful outcomes, sustained use, or another qualifying result.

Add your assessment

Send your product, your proposed lap times, and the evidence behind them. Unmeasured laps are welcome. You don’t need to finish the mile to take part.

Send it to support@mystanding.ai.

Assessments will be added manually, with the builder’s permission. Only send material you are comfortable sharing publicly.

Feedback

Is the four-minute mile worth measuring? Do these measures seem fair? Can we score each other’s solutions? How would we do that?

Identify the lap and time level you would change, suggest a better target, and explain what it would demonstrate.

If someone has already crossed the finish line, bring the example and the evidence.

Send it to support@mystanding.ai.

A note on affordability

Affordability is where we see the biggest hurdle. People can test each other’s user experience fairly easily. Verifying the engineering behind it takes more expertise, time, and access.

An invitation to review a product should not mean handing a stranger production credentials or private user data. Builders could share test results, selected code, or an isolated environment with fictional data. Each allows different claims to be checked, and we should be clear about what remains unverified.

The challenge is making that verification credible at a cost an independent builder can afford. Shared tests and reviews could help, but we still need to work out where specialist expertise is necessary and how to make it accessible.

Foundations and references

Our thresholds are proposals. These resources inform the assessment; they do not endorse it or prescribe our scores.