A practical proposal stack: Notion, a live calculator and Stripe

A service proposal often asks a client to do three things in one sitting: understand the scope, see what it might cost, and decide how to proceed. A static PDF handles the first task. It is less useful when price changes with choices such as number of pages, data sources or delivery speed.

A small stack can make that decision clearer: put the explanation and terms in Notion, let the client test a pricing model with a MyCalculators.app calculator, and use a Stripe payment link for an agreed deposit or fixed amount. The handoff between those tools matters more than the number of tools. A calculator is not a signed scope, and a payment link is not a substitute for checking the quote.

Start with one repeatable service

Use a service where the price has a few visible drivers. For example, an analytics consultant might price onboarding as a base fee plus additional data sources and optional training. Write down the actual rules before building anything: which choices affect price, which are included, and which require a custom quote.

Keep the first version narrow. If a request depends on a discovery call, unusual integrations or uncertain data quality, do not force it into a neat calculator. Add a clear note that those cases need review. A polished number can look like a firm offer even when the underlying scope is still unknown.

Build the pricing model before placing it in the proposal

1. List the inputs. Choose only the options a prospective client can reasonably answer, such as the number of data sources or training sessions. Avoid asking for information you do not use.

2. Write the formula in plain language. State the base amount, any additions, and any limits. Check boundary cases: the smallest package, the largest supported package, and combinations that should trigger a manual review.

3. Create the calculator. MyCalculators.app offers more than 200 ready-made calculators and lets users build custom calculators from a description of what they need to work out. For a service quote, describe the inputs and pricing rules, then test the result against examples you have already calculated by hand.

4. Publish a shareable version. MyCalculators.app says calculators can be shared by link and embedded. Put the calculator link in the proposal first. If you want an inline experience, test the embed in the actual Notion page and check it as a client would. Keep the link as a fallback; an embed that fails to load is a dead end.

Do not assume the calculator will store a client’s choices in your proposal or payment system. Treat it as an interactive estimator unless you have independently confirmed the data flow you need. For a closer look at why checking formulas matters in customer-facing tools, see our guide to choosing and checking a calculator engine.

Make the Notion page do the explaining

Keep the proposal readable without the widget. Put the problem, recommended scope, deliverables, assumptions, timeline and terms in the Notion page. Then introduce the calculator with one sentence that says what it changes and what it does not. For example: “Use this estimate to compare the supported options; final scope and price are confirmed in writing.”

Place the calculator near the relevant pricing section, not at the bottom as an unrelated extra. If the embed is cramped on mobile or distracts from the scope, use a clear link instead. The trade-off is straightforward: an inline widget reduces the jump between explanation and price, while a link is usually easier to test and gives the client a direct route to the calculator.

Include a static summary of the main package or starting point as well. Clients should not have to interact with a widget just to learn what service you are proposing. And do not treat a calculator’s displayed result as acceptance of the proposal.

Use Stripe after the price is confirmed

Stripe payment links fit the final step when the amount is already settled. For a fixed package or standard deposit, add the payment link to the proposal beside the relevant terms. Make clear what the payment covers and when work begins.

Variable quotes need one more human step. Ask the client to confirm the selected options and resulting scope in writing, check the calculation, then send a payment link for the agreed amount or deposit. Do not imply that changing calculator inputs automatically changes a Stripe payment link. Keeping that confirmation step prevents a mismatch between the estimate, the proposal and the charge.

Test the handoffs, not just the arithmetic

• Open the Notion proposal as a person who has not edited it. Check that the calculator link is visible and that any embed behaves as expected.

• Run several known input combinations through the calculator and compare them with hand calculations. Check that the proposal explains exclusions and manual-review cases.

• Follow the payment link through to its payment page before sending it to a client. Confirm that the amount and description match the agreed offer.

• Decide who updates the calculator if prices or terms change. A live widget can make a proposal more useful, but it also means an outdated pricing rule can keep being shown.

This stack is most useful when the service has repeatable pricing and the buyer benefits from seeing the effect of a few choices. It adds little for bespoke work that requires a conversation before any number is meaningful. Keep the calculator honest about its limits, the Notion page clear about the scope, and Stripe at the end of the approval process.