Technical ideas ready for review

Say what it costs,
then why it is worth it.

Turn a technical idea into an RFC with problem, proposal, trade-offs, alternatives, risks, and open questions. Any performance conclusion you have not measured is written as “needs to be measured”, and the proposal states plainly what it does not do.

No invented numbersTrade-offs statedQuestions stay open

Review the RFC

Your result will appear here

We write the problem before the proposal, add alternatives and trade-offs, mark unmeasured performance claims as needing a test, and list every open question.

SAMPLE OUTPUT

Here is exactly what you receive.

This is the complete output for the source text in the demo above: a proposal-quality score, itemised revisions, claims marked as needing a test and why, open questions, and the drafted RFC. It is a demonstration, not a customer case.

SAMPLE

Draft result (sample)

Proposal quality score88/100

+50

Mark the unmeasured performance expectation

“Performance should improve a lot” becomes “needs to be measured”, listing the test scenario, comparison baseline, and measurement method as outstanding, so review does not orbit an unverified figure.

Add the out-of-scope section

The source had no boundary at all. It now states that the order write path is untouched, the storage layer is not restructured, and no performance improvement is promised.

Split “the risk is low” into risk and rollback items

“The risk is low” had no basis. It becomes an identified consistency risk, with rollback steps and trigger conditions marked as to be decided.

Drafted RFC

# RFC: revise the caching strategy for order queries

## Problem
The current caching strategy for order queries behaves unpredictably under high concurrency.

TODO: this lacks an observable description of the symptom. Add the specific failure mode, blast radius, and trigger conditions.

## Proposal
To be decided: the symptom needs to be pinned down before the scope of the change can be set.

TODO: the material gives no concrete proposal; this section needs content

## What this does not do
- Does not change the order write path.
- Does not restructure the storage layer.
- Does not promise any performance improvement.

## Trade-offs
To be decided: name the cost this design accepts once the proposal is settled.

## Alternatives
To be decided: add at least one candidate approach and its cost.

## Risks and rollback
- Risk: changing the caching strategy may affect data consistency.
- Rollback: to be decided — the rollback steps and trigger conditions need to be specified.

## Open questions
- “Performance should improve a lot” is an unmeasured expectation. Needs to be measured: supply the test scenario, comparison baseline, and measurement method.
- “The risk is low” has no supporting basis; a risk assessment is needed.

WHAT DRAFTING DOES

A proposal persuades by stating its own cost.

Problem before proposal

Write what fails under which conditions before describing the fix. Reverse the order and review becomes a debate about taste.

Alternatives carry a cost

“The other approach is more complex” carries no information. Say what it costs and what it buys, and readers can judge for themselves.

Unmeasured means unmeasured

“Performance should improve a lot” becomes “needs to be measured” plus the experiment required. Invent a figure and the review revolves around that fiction.

WHY IT IS WORTH DOING

Without trade-offs, review runs on instinct.

Numbers get treated as facts

Once “40% faster” is written down, nobody questions it again — and it may have been a feeling at the time.

What you skip is part of the design

Leave the boundaries unstated and each reviewer infers a different scope, which surfaces only during implementation.

Rollback needs more thought than rollout

However detailed the proposal, a missing rollback path means no way back once something goes wrong in production.

Note: common practice for technical proposals is to bound the problem and constraints first, then compare candidate designs with their respective costs, and close with open questions. Teams differ in review process and document length. This site drafts documents only; it runs no code or tests and verifies no measurement or incident data.

DRAFTING DEMO

The same idea, organised.

Before

Our current caching has problems. I suggest we adopt a new caching approach; performance should improve a lot, and the risk is low. Thoughts?

Drafted

# RFC: revise the caching strategy for order queries

## Problem
The current caching strategy for order queries behaves unpredictably under high concurrency.

TODO: this lacks an observable description of the symptom. Add the specific failure mode, blast radius, and trigger conditions.

## Proposal
To be decided: the symptom needs to be pinned down before the scope of the change can be set.

TODO: the material gives no concrete proposal; this section needs content

## What this does not do
- Does not change the order write path.
- Does not restructure the storage layer.
- Does not promise any performance improvement.

## Trade-offs
To be decided: name the cost this design accepts once the proposal is settled.

## Alternatives
To be decided: add at least one candidate approach and its cost.

## Risks and rollback
- Risk: changing the caching strategy may affect data consistency.
- Rollback: to be decided — the rollback steps and trigger conditions need to be specified.

## Open questions
- “Performance should improve a lot” is an unmeasured expectation. Needs to be measured: supply the test scenario, comparison baseline, and measurement method.
- “The risk is low” has no supporting basis; a risk assessment is needed.

Demo sample: the unmeasured performance expectation is marked as needing a test, the out-of-scope and rollback items are added as open, and the missing symptom description is listed. Paste your draft to get your version (sign-in required; one credit per run).

WHY YOU CAN TRUST IT

We put “no invented numbers” into our product principles.

Performance conclusions need a test

Latency, throughput, improvement ratios, and error rates are written as “needs to be measured” unless you measured them, along with the experiment that would settle it.

What it does not do gets its own section

Which paths stay untouched, which migrations are deferred, which problems are not claimed to be solved — all written out rather than left to inference.

Alternatives carry a cost

At least one candidate is listed with what makes it expensive. A proposal without a trade-off can only be reviewed on instinct.

Content is not stored

Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.

FAQ

Ask these before you pay.

Will you estimate the performance gain?

No. Latency, throughput, and improvement ratios are written as “needs to be measured”, together with the experiment that would produce them. Invent a figure and the whole review argues about that fiction.

Do you run benchmarks?

No. This site executes no code, runs no load tests, never touches your systems, and verifies no measurement or incident data. Numbers can only come from your own tests.

Why is “what this does not do” mandatory?

Because unstated boundaries lead every reviewer to infer a different scope, and the disagreement surfaces during implementation. It is body text, not an appendix.

What does one draft cost?

One credit per run, usually done in seconds, returning the RFC, revision notes, and open questions.

Do credits expire?

No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.

Is there batch processing or an API?

Not yet. Each run processes one document and consumes one credit; there is no bulk upload or API today. Email us with your use case and we will assess it.

Is my content stored?

Not intentionally. Text is used for this single AI request only. See the Privacy Policy.

What content fits?

Architecture change proposals, technology selection comparisons, refactoring plans, improvement ideas after an incident — any technical idea a team needs to review and leave a decision record for.

SIMPLE PRICING

Prove the value before you upgrade.

Starter

$9/ month

For an occasional publishing cadence, with a focused monthly credit allocation.

50 optimization credits per monthly renewal
Complete GEO analysis
Chinese and English output
Markdown export

Pro

Recommended$29/ month

For frequent publishers who iterate on content continuously.

250 optimization credits per monthly renewal
Complete GEO analysis
Chinese and English output
Markdown export

Advanced

$79/ month

Our largest monthly credit allocation, for the heaviest continuous usage.

1,000 optimization credits per monthly renewal
Complete GEO analysis
Chinese and English output
Markdown export

Credits never expire: unused credits carry over instead of resetting. Credits apply to this site only and are not shared with other sites.

Prices shown are USD baselines; final currency, taxes, and discounts are determined by Paddle for the checkout location.

Say what it costs,then why it is worth it.

Paste draft

Review the RFC

Your result will appear here

Here is exactly what you receive.

Draft result (sample)

Mark the unmeasured performance expectation

Add the out-of-scope section

Split “the risk is low” into risk and rollback items

A proposal persuades by stating its own cost.

Problem before proposal

Alternatives carry a cost

Unmeasured means unmeasured

Without trade-offs, review runs on instinct.

Numbers get treated as facts

What you skip is part of the design

Rollback needs more thought than rollout

The same idea, organised.

We put “no invented numbers” into our product principles.

Performance conclusions need a test

What it does not do gets its own section

Alternatives carry a cost

Content is not stored

Ask these before you pay.

Prove the value before you upgrade.

Starter

Pro

Advanced

Say what it costs,
then why it is worth it.