8
5 Comments

A simple system for testing prices without chaos

It’s important for founders to experiment with pricing, but many of us forget that it isn’t just about changing the price itself.

Checkout, support, tracking, messaging, and billing all need to be checked — these are the things that founders usually miss.

Here’s a workflow that uses AI and no-code automation to keep your experiments on track. One form starts the test, AI checks what needs to be done, automation creates the tasks, and a launch gate blocks the test if key pieces are missing.

Stack

  • Jotform collects the details
  • Make (or Zapier) sends those details to the other tools
  • OpenAI checks for missing tasks and risks
  • Trello keeps the tasks organized.
  • Google Sheets keeps the experiment log
  • Slack sends the alerts
  • Stripe is used to test checkout
  • GA4 or Plausible tracks the results

Step 1 — Create the intake form

Create a Jotform called Pricing Test Intake. The form fields should collect the basic details of the test:

  • Test name
  • Test ID
  • New price
  • Who should see the price
  • Who should not see the price
  • Whether current customers are affected
  • Main metric
  • Stop rule

Also, add a checkbox field for where the price could appear. Include:

  • Pricing page
  • Checkout
  • Upgrade page
  • Signup page
  • Emails
  • FAQ
  • Support replies
  • Receipts
  • Billing settings
  • Analytics

Use the same Test ID in Trello, Google Sheets, Slack, Stripe notes, support docs, and analytics. This makes the test easier to track.

If current customers are affected, add a required field called Migration plan. This should ask:

  • Who changes?
  • Who keeps the old price?
  • When does it happen?
  • What will customers be told?

For the stop rule, go for something concrete, such as:

  • Stop if refund rate goes above 8%.
  • Stop if pricing support tickets double.

This prevents the test from running forever.

Step 2 — Connect the form to Make

Now, connect the form to the rest of the workflow.

In Make, create a new scenario. Use Jotform as the first step:

  1. Choose Watch for Submissions.
  2. Select Pricing Test Intake.
  3. Connect your Jotform account.

If Make asks for an API key, get it from: Jotform → Profile → Settings → API

Test it:

  • Click Run once in Make
  • Submit a test entry in Jotform
  • Confirm that Make receives the submission

Once Make receives the test entry, the form is connected.

Step 3 — Send the intake answers to OpenAI

Once Jotform is connected, add OpenAI.

  1. Click the plus button
  2. Search for OpenAI
  3. Choose the OpenAI module that creates a text response
  4. Connect your OpenAI account

Then write a prompt that includes the key intake details needed to review the test:

  • New price
  • Who should see the price
  • Who should not see the price
  • Where the price may appear
  • Existing customer impact
  • Migration plan
  • Main metric
  • Stop rule

Ask OpenAI to return four sections:

  • Missing details
  • Tasks to create
  • Risks to review
  • Launch blockers

Run one test submission. The result should be the checklist you use to create the Trello cards.

Step 4 — Create the Trello cards

Now, add Trello after OpenAI in the same Make scenario.

  1. Click the plus button after the OpenAI module
  2. Search for Trello
  3. Choose Create a Card.
  4. Connect your Trello account

Create the main experiment card first. Set the card up like this:

  • Board: Pricing Experiments
  • List: Intake
  • Card name: {{Experiment ID}} — {{Experiment name}}
  • Description: AI checklist from OpenAI

In Make, map the experiment ID and experiment name from Jotform into the card name. Then, map the OpenAI AI checklist into the card description.

Next, create four more Trello cards:
Copy card
Use this card to check every place where the price message may show up.
Check: Pricing page, upgrade page, signup page, FAQ, onboarding emails, support replies, receipts
Checkout card
Use this card to check the checkout setup.
Check: Product name, price, billing terms, trial, success page, cancel page, checkout URL, test checkout
Support card
Use this card to check customer support issues.
Check: Who gets the price, who does not get the price, existing customer questions, Past payments, confused customers
Tracking card
Use this card to check if the test can be measured.
Check: Pricing page visits, checkout clicks, purchases, refunds, cancellations, pricing support tickets
Add the main metric and stop rule to the tracking card.

Run one test submission and check Trello.

Step 5 — Add a migration card only when needed

Only create this card if existing customers are affected.

In Make, add a Router and create two paths:

  • Normal path: no migration card
  • Migration path: creates a migration card

Add this filter to the migration route: Does this affect existing customers? = Yes

Then, add Trello Create a Card to the migration route. Use:

  • List: Review
  • Card name: {{Experiment ID}} — Migration plan

The card should include:

  • Who changes
  • Who keeps the old price
  • When the change happens
  • Customer message
  • Support note
  • Billing impact
  • Complaint response

If existing customers are not affected, this card should not be created.

Step 6 — Log the experiment

Now, add Google Sheets to the intake scenario.

In Make:

  1. Click the plus button → Google Sheets
  2. Choose Add a Row
  3. Connect your Google account → Pricing Experiments spreadsheet

Create these columns in the spreadsheet:

  • Experiment ID
  • Experiment name
  • New price
  • Who sees it
  • Who does not see it
  • Where price appears
  • Existing customers affected?
  • Migration plan
  • Main metric
  • Stop rule
  • Status
  • Final pricing page URL
  • Final checkout URL
  • Final decision
    Map the matching Jotform fields into the row.

Leave these fields blank for now:

  • Final pricing page URL
  • Final checkout URL
  • Final decision

Run a test form submission. A new row should appear in Google Sheets.

Step 7 — Send the first Slack alert

Next, add Slack at the end of the intake scenario.

In Make:

  1. Click the plus button after the Google Sheets module.
  2. Search for Slack.
  3. Choose Send a Message.
  4. Connect your Slack account.
  5. Choose your pricing test channel.

Use this message (or something similar):

New pricing test created: {{Experiment ID}} — {{Experiment name}}

New price: {{New price}}
Audience: {{Who should see this price?}}
Do not show to: {{Who should not see this price?}}

Main metric: {{Main metric}}
Stop rule: {{Stop rule}}

Check Trello for the task cards.

Run a test submission and check Slack.

Step 8 — Create the pre-launch gate

Create a second Jotform form called Pricing Test Pre-Launch Check.

Add these required fields:

  • Experiment ID
  • Pricing page ready?
  • Checkout ready?
  • Support replies ready?
  • Tracking ready?
  • Does checkout match the pricing page?
  • Migration plan ready?
  • Final pricing page URL
  • Final checkout URL

Use Yes/No answers for the readiness questions. For 'migration plan ready?' Use:

  • Not needed
  • Yes
  • No

This form is completed only after the Trello tasks are done.

Step 9 — Block or approve the launch

Create a new Make scenario for the pre-launch check.

Use this trigger:

  • Jotform → Watch for Submissions
  • Form: Pricing Test Pre-Launch Check
  • Click Run once

Then fill out the pre-launch form one time to test it. Make should receive the answers.

Next, add a Router with two routes:

  • Blocked
  • Approved

Route 1: Blocked
Use this route if anything is missing.

Add a filter:

  • Name it: Block if anything is missing
  • Use: OR logic

Block the launch if any of these answers are No:

*   Pricing page ready?    
*   Checkout ready?   
*   Support replies ready?    
*   Tracking ready?   
*   Does checkout match the pricing page?    
*   Migration plan ready?

Then send this Slack message(or something similar):

Launch blocked: {{Experiment ID}}
Fix the missing items before launch:
*   Pricing page  
*   Checkout
*   Support replies   
*   Tracking    
*   Checkout and pricing page match    
*   Migration plan, if needed

Route 2: Approved
Use this route when everything is ready.

Add a filter:

  • Name it: Approve only if ready
  • Use: AND logic

Set the approved route to run only when:

*   Pricing page ready? = Yes  
*   Checkout ready? = Yes    
*   Support replies ready? = Yes_   
*   Tracking ready? = Yes   
*   Does checkout match the pricing page? = Yes    
*   Migration plan ready? is not No

Then send this Slack message:

*   Pricing test approved: {{Experiment ID}}  
*   _Pricing page: {{Final pricing page URL}}    
*   Checkout: {{Final checkout URL}}
    
You may launch.

This is the key automation. It does not launch the price. It blocks or approves the launch based on the pre-launch check.

Step 10 — Add the weekly review reminder

Create one more Make scenario for weekly review.

  1. Choose Tools → Scheduler
  2. Set it to run once a week
  3. Add Slack → Send a Message
  4. Send the message to your pricing test channel

Use this Slack message (or something similar):

Weekly pricing test review

Check every live test.

Review:

*   Pricing page visits
*   Checkout clicks
*   Purchases
*   Refunds
*   Cancellations
*   Pricing support tickets_
*   Main customer objection

Decision: Keep, stop, or change.

This gives every live test a review date. It’s not fancy, but it is enough to stop pricing tests from running forever.

Step 11 — Turn the scenario on

Before going live, submit fake entries via the intake and pre-launch forms. Check that the workflow does what you expect:

  • OpenAI returns a checklist
  • Trello creates the cards
  • Google Sheets logs the test
  • Slack sends the first alert
  • Migration card only appears when existing customers are affected
  • Blocked pre-launch checks send blocked alerts
  • Approved pre-launch checks send approved alerts

When the tests work, turn the scenarios on. Now the workflow is live.

The basic logic also works in Zapier, but in this version, Make is the automation layer.

This is the system.

on June 11, 2026
  1. 1

    The piece I'd add to any "test prices without chaos" system: grandfather existing paying customers indefinitely on whatever price they signed at. Anchoring loss aversion is real — a churn spike from a price change on existing accounts will overwhelm whatever ARPU lift you get from new ones, and the math basically never works out at <$50 ARPU. Test prices on new signups only, version your pricing page (e.g. /pricing-v2), and let cohort-by-acquisition-date tell you the truth.

  2. 1

    The stop rule is the most underrated piece of this. Most founders never test pricing because it feels like an open-ended mess, and a concrete kill switch like "stop if refunds pass 8%" is what makes the test safe enough to actually run. When we raised prices at SocialPost.ai, the scary part was never the number. It was the surface area: receipts, FAQ, support replies, old screenshots in help docs. Your checkbox list of every place a price can appear is worth the whole post.

  3. 1

    Solid pattern. One thing the price-testing flow misses that AI eval workflows solved: a shadow run before you flip the segment. DSPy (https://github.com/stanfordnlp/dspy) bakes the same idea in. You run the new prompt against the same data the old one ran on, before any user sees it. For pricing this means: same intake form, same audience filter, run both prices for 48 hours in parallel where the user still sees the old price but you log the conversion as if they saw the new one. Cleaner read on the elasticity without burning customers. Worth bolting on before the segment switch ships.

  4. 1

    This is the kind of post that makes you realize how many pricing experiments are running half-blind. Most founders change the number and call it a test.
    The pre-launch gate stood out to me. Blocking the launch if something is missing instead of just flagging it is a small detail that changes everything. Warnings get ignored. Hard stops don't.
    One question: what happens when the numbers move during the test but for reasons outside your control — a competitor changes their price, a big mention sends a traffic spike? Does the stop rule still apply or do you just accept that as noise?

  5. 1

    testing before can save SO much unnecessary stress later. thanks again for this.

Trending on Indie Hackers
6 weeks solo, 2 rejections, finally live but nobody told me marketing would be this hard User Avatar 83 comments Building ExpenseSpy solo, no funding — launching June 17 on iOS & Android User Avatar 38 comments Hi IH — quick update. The MVP is live. User Avatar 34 comments Day 7: 51 people answered my question. I wasn't ready for what they said. User Avatar 18 comments I built a $5/1k-listing CRE data API because CoStar is overkill for first-pass scans User Avatar 17 comments I Was Bypassing Every App Blocker, So I Built One That Fights Back User Avatar 11 comments