Email blacklists: Why you’re on one and how to fix it

Woman reacts to a 5% open rate after her email newsletter gets moved to spam

An email blacklist is a shared list of IP addresses or domains that mailbox providers flag as spam sources. If you’re on one, your campaigns are landing in spam, or not landing at all. The good news is, it’s rarely mysterious. Check your IP and domain separately, work through each list’s own removal process, and fix whatever got you flagged in the first place. Most first offenses clear in a day or two. Here’s the actual checklist, not the panic.

Key takeaways:

  • Blacklists (also called blocklists or denylists) target your sending IP or domain, not individual email addresses.
  • Your IP and domain are checked and listed independently. A clean domain doesn’t mean a clean IP, and vice versa.
  • Removal has to happen list by list. There’s no single form that clears every blacklist at once.
  • Fixing the root cause before you request delisting matters more than how fast you submit the request.
  • Staying off the list long-term comes down to authentication and list hygiene, not luck.

What is an email blacklist?

An email blacklist is a database that flags IP addresses or domains associated with spam, so mailbox providers can reject or filter mail from them before it reaches an inbox. 

In plain terms: you did something Gmail or Outlook didn’t like, and now they don’t trust mail from your domain or your server. 

Some of these lists are public and free to check, like Spamhaus. Others live inside a specific provider’s own filtering system, like Gmail’s Postmaster Tools reputation scoring, and you won’t find those on a public checker at all.

You’ll also see “blocklist” and “denylist” for the exact same thing. The industry’s been moving away from “blacklist” for a few years, but all three mean the same mechanism: a list telling a receiving server not to trust your source. Different word, same problem, so don’t treat a mismatched term in an article as a sign you’re reading about something else.

One quick distinction: blocking unwanted senders in your own inbox is a personal setting in your email client, not this. This article covers your domain or IP getting listed by someone else. Solid email deliverability means staying off these third-party lists, not managing your own inbox filters.

How email blacklisting actually works

A blacklist tracks sending identity. This is usually the IP address the email was sent from, the domain used to authenticate it, or a domain that appears in the message body.

Getting flagged is not always about your own behavior. Spam complaints, high bounce rates, and sending from a compromised server are the usual causes, but some blacklists target specific IP ranges outright, and if you’re on shared sending infrastructure, another sender’s bad behavior on that same IP can get you listed too.

So when you get listed, check where you’re sending from before you start changing your campaigns. If it’s a policy listing on the IP range, no amount of cleaning your list or fixing your copy will lift it. That one gets resolved by your host or ESP and the first thing you need to do is contact them. —Katerina Nikolova, CRM Manager at SiteGround

IP-based blacklisting

The older, more common type. Send enough spam from one IP, or send from a compromised server, and that IP lands on a list like Spamhaus’s SBL. From there, every mail server that checks that list rejects or flags mail from it, no matter which domain the mail claims to be from.

Domain-based blacklisting

Same mechanism, different target: your sending domain instead of your IP. This matters more now than it used to. In 2024, Gmail and Yahoo introduced bulk sender requirements that put domain authentication and reputation front and center in how they filter mail. The upshot: a shared IP with a great reputation can’t save you if your domain’s reputation is bad.

Spam traps

Spam traps are email addresses that don’t belong to real people, planted specifically to catch senders with bad list hygiene. Any mail sent to one is treated as strong evidence you’re sending to addresses you shouldn’t have, usually a sign of a purchased or scraped list.

Sudden list growth

A steep, sudden jump in your email list size looks the same to a mail server as a spammer buying a list, even when the growth is completely legitimate. If you’re about to bring in a big batch of new subscribers, space it out or explain the growth through your sending platform rather than blasting it all at once.

How a DNSBL lookup decides you’re listed

Most public blacklists work as DNSBLs (DNS-based blackhole lists). Think of DNS as the internet’s phone book, the system that looks up an address and returns an answer. A DNSBL uses that same lookup system, but instead of finding a website, it checks whether the sender’s IP is on the list. 

When a mail server gets your message, it runs one of these quick lookups. The answer comes back yes or no on your IP, and the receiving server decides what happens next: reject outright, or route to spam. All of this happens in milliseconds, before your email marketing campaign ever reaches an inbox.

The blacklists that actually matter

Not every list on a checker report deserves the same reaction. Some carry real weight with major mailbox providers. Others barely register.

BlacklistPriorityWho checks itWhat to do
Spamhaus (SBL)HighApple iCloud, Microsoft, Yahoo, thousands of ISPs (internet service providers)Fix immediately
Barracuda Reputation Block ListHighCorporate mail filtersFix immediately
UCEPROTECTLowFewer providers, often used as a secondary signalMonitor, usually auto-expires
CBLLowFeeds into other lists rather than being checked directlyMonitor
Gmail Postmaster Tools / Outlook SNDS ((Smart Network Data Services)Not a public listGmail and Microsoft only, internal reputation scoringCheck the dashboard directly, won’t show on a public checker

If Spamhaus or Barracuda flags you, treat it as urgent. The rest are worth knowing, not worth losing sleep over on their own.

ISP-specific blocks (Gmail, Outlook Postmaster Tools)

Gmail and Microsoft run their own internal reputation systems, separate from public blacklists entirely. Your domain can have a perfectly clean record on every public checker and still get filtered into spam by Gmail or Outlook specifically, because these providers score your sending reputation privately and never publish the result anywhere you can check. 

The first sign is usually an unexplained drop in your overall open rate and click rate, not a blacklist entry showing up anywhere. If your numbers dip and nothing else changed (no new list, no different subject lines, no send-time shift), this kind of internal filtering is worth ruling out, even though no checker tool will confirm it directly.

How to check if you’re blacklisted

You’ll know from one of two places: a bounce message that names the blocklist directly, or a checker tool that confirms it. Here’s the order that gets you an answer fastest, and why each step comes before the next.

Scan your recent bounce messages first

This costs nothing and takes no tool. A rejection message often names the exact blocklist, which skips straight past the guesswork of checking every list one by one.

Run your sending IP through a checker

MXToolbox covers the major lists in one pass. Bounce messages won’t always name a list, so this step catches what step one missed.

Check your domain separately

IP and domain blacklisting are independent, so a clean IP check doesn’t rule out a domain-level listing, and vice versa. Skipping this step is the most common reason someone thinks they’re clear when they’re not.

Check your sender reputation in Google Postmaster Tools

Save this for last since it’s the narrowest check: Gmail-specific reputation issues that never show up on any public checker.

Not every deliverability dip means you’re blacklisted. Sometimes it’s a temporary throttle from a mailbox provider, a DNS misconfiguration, or an issue on your platform’s side. Confirm the actual listing before you start the removal process below

How to get removed from a blacklist

Once you’ve confirmed a listing, the process is more methodical than it feels in the moment.

Fix the root cause before you request removal

Spamhaus and Barracuda will both deny a delisting request if the underlying problem hasn’t actually been resolved, whether that’s an open relay (a misconfigured mail server that lets anyone, including spammers, send mail through it), a compromised account, or a spike in spam complaints. Submitting a removal request before you’ve fixed the cause just gets you relisted, often within days.

Submit a removal request through the blocklist’s own site

Each list runs its own delisting process. There’s no single form that clears you everywhere at once, so work through each one your check turned up.

  • PBL (covers dynamic or residential IPs) and DBL (covers domains): self-removable through Spamhaus’s Checker tool.
  • SBL: requires your ISP or network owner to contact Spamhaus directly with evidence of remediation. Not self-service.
  • Barracuda: its own web-based removal form.

Moved the framing sentences to the top and bottom so the bullets stay scannable, and bolded the list names since those are the actual thing a reader is scanning for once they know which one applies to them.

Don’t resubmit repeatedly if it doesn’t clear right away

Filing the same request multiple times in a short window doesn’t speed anything up, and on some lists it flags the request for additional review instead. One thorough submission, filed after the cause is genuinely fixed, works better than five impatient ones.

Expect different timelines for different lists

Automated lists like SpamCop typically clear in 24 to 48 hours once complaints stop. Spamhaus’s manually reviewed listings, like SBL, generally process in 24 to 72 hours for a first offense, longer for repeat listings. Barracuda often responds within 12 to 24 hours for straightforward cases. UCEPROTECT runs on a standard 7-day period. None of this is guaranteed. Complex or repeat cases can stretch to weeks.

Monitor for a few days after removal, not just at the moment of delisting

Clearing a public blacklist doesn’t mean your deliverability recovers instantly. Mailbox provider reputation, especially at Gmail and Microsoft, tends to lag behind the public listing status by a few days, so don’t expect open rates to snap back the moment a checker tool shows you clear.

How to stay off the list for good

Most listings trace back to two things: authentication gaps and a messy list. Both are fixable before they become a problem.

Use double opt-in on your sign-up forms

Clean sign-up practices do more here than people expect. Using double opt-in for your forms keeps out the fake and mistyped addresses that generate spam complaints and hard bounces (permanent failures, like sending to an address that doesn’t exist), which are exactly the signals that get a domain flagged in the first place.

Get your authentication records set up correctly

On the infrastructure side, SiteGround creates SPF and DKIM records automatically for every domain. SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are the two records that prove an email actually came from your domain and wasn’t tampered with along the way, and that authentication piece is already in place before you send your first campaign.

Keep your unsubscribe process compliant

SiteGround Email Marketing also handles the compliance side automatically: every email goes out with an unsubscribe link built in, and opt-outs get processed immediately rather than sitting in a queue. You’ll still need to add your business address to the template yourself.

Removal is easy. Staying off is where you win.

A blacklist entry feels like an emergency the first time it happens, but it’s rarely permanent and almost never mysterious once you know what to check. Confirm the listing, fix what caused it, work through each list’s own removal process, and put authentication and list hygiene in place so you’re not back here in a month.

Ready to send campaigns with authentication handled and unsubscribes processed automatically? SiteGround Email Marketing takes care of the setup that keeps most senders off blacklists in the first place.

[58]

Can you trust an AI-built online store with customers and payments?

Abstract of an AI-built online store you can trust

You built an online store in an afternoon. It looks great, you pat yourself on the back. But there’s one looming question: are you actually able to charge someone’s card yet? Are AI-built online stores safe for real payments? The answer is yes — if the store passes a payment-readiness check first. 

Key takeaways:

  • Are AI-built online stores safe for real payments? Yes, once you verify eight specific things before launch, not just the design.
  • Test an AI-built store before launch in order: offer, trust signals, policies and data, checkout, mobile, payment status, confirmation, then edge cases.
  • Secure online checkout means card numbers never touch your site’s own code. That’s not a promise, it’s a technical fact.
  • Coderick AI’s Stripe integration handles one-time purchases and subscriptions automatically.
  • A launch checklist only counts if you run it against a real test transaction, not a visual walkthrough.

One thing first: if you haven’t settled on a platform yet, choose the right selling path before working through the rest of this.

Are AI-built online stores safe for real payments?

Yes, but only if you check a specific set of things before you flip the switch on real payments. AI-built store safety comes down to two things: what you actually check yourself, and how much your builder already handles by default. Most of the risk lives in the first part, and that’s what the checklist below walks you through.

Indeed, an AI website builder can produce a complete-looking store in minutes: product pages, a working cart, a checkout button that appears to do its job. But speed and safety solve different problems. A finished-looking store can still fail on:

  • Payment status handling
  • Refund logic
  • A checkout that breaks the moment someone opens it on a phone

A few things make AI-built store risks a distinct category, not just the standard ecommerce checklist with an AI label stuck on it:

  • AI-generated copy can misstate a price, a shipping promise, or a product spec with total confidence and zero warning.
  • A store built in minutes rarely gets the manual walkthrough an agency-built site would get before launch, because skipping that step was the whole point.
  • The person building it is often not a technical or ecommerce professional either, so there’s no expertise in the loop to catch what a specialist would spot on sight.

None of these problems show up when you’re just poking around a finished site. All three show up the first time a customer tries to pay. That’s why the checklist below treats payment readiness as separate from design readiness.

Heads up: not every AI builder leaves all of this on you. Coderick AI closes off a chunk of it before you even start testing, more on that once you’ve gone through the list below.

AI-built store launch checklist: what to verify before taking real payment

AI-built store payments touch eight separate points before you can actually trust them. Work through each one in order:

1. Start with the offer: is it actually clear?

An AI generator, in all its cheerful optimism, will happily produce a colorful product description, a price, and a delivery promise that don’t quite agree with each other, nevermind what you can actually execute. Before you touch checkout, put yourself in a customer’s shoes landing on this page for the first time. Can they answer:

  • What am I paying?
  • What am I getting?
  • By when?

How to check: read your own product page as a stranger would. If you can’t answer all three in one glance, that’s the fix.

An unclear promise turns into payment risk costs the moment a customer disputes a charge over it. This is also the cheapest fix on the whole list, since it’s a text edit, not a technical one, so do it before anything else here.

2. Do the trust signals actually hold up?

Right after the offer, a customer checks whether you’re a real business with a safe and secure website. This is what they’re looking for:

  • Your business name matches what’s on the payment page.
  • A real contact method exists, and someone actually answers it.
  • Checkout shows a padlock and a recognizable payment brand.
  • There’s a working support channel, not just a contact page that exists for show.

How to check: use your own contact form and support channel like a stranger would, and see whether anything, or anyone, actually answers.

This matters even for businesses that don’t sell physical goods, since the same expectations apply to safe payment pages built for portfolios, restaurants, or one-off event bookings. An AI builder can generate a footer with a contact form in seconds, but it won’t notice if that form points to a dead inbox. 

3. Are your policies actually visible?

Another thing customers expect to see, and that conveys trust, is a clear answer to what happens if something goes wrong, before they hand over a card number, not after. They expect to see:

  • Your refund window is stated plainly, not brushed aside on a page nobody clicks.
  • Your delivery timeline is realistic and accessible before checkout, not just in a shipping confirmation email.
  • Any access or subscription terms are spelled out up front.
Example website with a shipping policy in the footer transmitting trust

How to check: make sure all of these details are easily visible from your product pages, or no more than one click away. 

4. Is the online checkout secure and easy to use?

A secure online checkout comes down to two separate things, and they don’t fail in the same place:

  • Security: this is solved by choosing the right foundation, not by building it yourself. Integrating with a reputable payment processor like Stripe (used as the example throughout this checklist, the same checks apply to whichever one you use) means the most sensitive part of the transaction, the actual card data, is handled by a company that specializes in exactly that: encrypted, PCI-compliant, and built for this one job. It also means checkout carries a brand your customers already trust, rather than an unfamiliar name asking for their card number.
  • Usability: if checkout runs through Stripe’s own hosted page, the payment form itself isn’t something the AI generator built, it’s Stripe’s tested interface. What the AI-built site still controls is everything around it: whether the right product, price, and currency get passed into that page, and whether the redirect back to your site after payment actually works. That hand-off, not the payment form, is where bugs tend to show up.

How to test: place a real test order with a real card, not a made-up test transaction, and confirm the product, price, and currency on Stripe’s page match exactly what you expected before payment.

5. Does checkout actually work on mobile?

We’ve all been there: mobile checkout simply fails in ways desktop checkout doesn’t. And boy is it frustrating. Make sure your mobile experience ticks these boxes:

  • The payment button stays visible instead of hiding under the on-screen keyboard.
  • The card field accepts spaces and other common formatting.
  • The confirmation page loads fully on screen, not cut off at the edge.
online store mobile website that works well and transmits trust

How to test: run the exact same test from step 4, but do it on your phone. AI-generated layouts render cleanly in a desktop preview and only reveal these problems once a thumb, not a mouse, is doing the tapping.

If most of your traffic already arrives on mobile (which, according to recent mobile commerce data, it likely does, with some estimates as high as 78% of global ecommerce traffic), this test matters more than the desktop version you keep checking instead.

6. Does the store know if the payment succeeded, failed, or was canceled?

Can an AI-built store process payments securely? Part of the answer is whether the store actually knows what happened after the customer clicked “pay.” Practically, a payment can:

  • Succeed
  • Fail on a declined card
  • Get canceled mid-checkout

How to test: use your payment processor’s test card numbers to trigger a successful payment, a decline, and a cancellation, then confirm each one redirects to the right place and shows the correct status, both what the customer sees and what your payment processor dashboard reflects.

Your store needs to get this right every time, not just on the happy path, and that consistency is what AI-built store payment security really comes down to.

If you sell subscriptions: run the same test on a renewal charge, not just the first payment. Confirm that a failed renewal actually cuts off access, using recurring access checks rather than leaving the account active by mistake.

7. What happens in the moment right after a customer pays?

Step 6 confirmed a successful payment shows the right status. This step is about whether that moment actually reassures the customer, and two different systems are behind it:

  • Your thank-you page and its next-step messaging come from your own site, not Stripe. Once payment goes through, Stripe hands control back to whatever confirmation page your site built, so a generic “thanks” instead of a real next step is your site’s copy to fix, not a Stripe default.
  • The email receipt is Stripe’s own mechanism, a dashboard toggle, sent from Stripe’s own template.

How to test: place a real test order and time it. Turn receipts on under Customer emails in your Stripe dashboard settings by toggling “Successful payments,” and separately, check that your own confirmation page actually says something useful instead of a generic thank-you.

8. Have you tested what happens when something goes wrong?

The friction-free path is 80% of testing. The other 20% is deliberately breaking things. Let’s get messy.

How to test:

  • Decline a test card
  • Cancel mid-checkout
  • Request a refund
  • Place the same order twice in a row, then check your payment records after checkout to confirm it created one order, not two.

Agencies building AI-generated stores for clients run exactly this kind of client store QA before handoff. If you can’t answer what your store does in each of these four scenarios, you haven’t tested an AI-built store before launch. You’ve only tested that it looks like one.

AreaWhat to check
OfferProduct, service, price, and promise are stated plainly.
Trust signalsBusiness identity, contact information, secure checkout, and a support path are visible.
PoliciesRefunds, delivery, access, and support expectations are clear before checkout.
Customer dataCheckout forms collect only what fulfilling the order requires.
CheckoutA customer can pay without confusion or unexplained errors.
MobileCheckout works cleanly on a phone, not just on desktop.
Payment statusThe store correctly shows success, failure, or cancellation every time.
ConfirmationThe customer gets a clear next step immediately after paying.
Edge casesFailed payments, canceled payments, refunds, and duplicate orders have all been tested.

The checklist above covers what’s specific to AI-built stores. Stripe checks before launch covers what it doesn’t: test mode, live keys, tax, and disputes.

A note on Coderick AI
If you’re building with Coderick AI, SiteGround’s AI website and app builder, checkout and payment status both come included by default, since it connects to Stripe’s own checkout page rather than a payment form built from scratch. A confirmation page comes included too, though its actual messaging (a real next step versus a generic thanks) is still yours to write well, more on that in step 7.
Start building your online store now with Coderick AI>>

What Coderick AI already handles: where a developer still needs to check the rest

A Coderick AI online store comes with a portion of the checklist above already checked off before you typing out any prose on your keyboard.

The security that comes with the site, not just the site itself

Most of the checklist above is about what you test. This part is about what’s running behind the site to keep it safe, none of which a customer ever sees:

  • Access control: user authentication is built in from the start. Weak or missing authentication is one of the most common vulnerabilities found in AI-generated code, so having it handled by default closes off a real, documented gap rather than a hypothetical one.
  • Hosting and security: SiteGround’s stack comes with it automatically, covering firewalls, malware scanning, and DDoS protection. Translation: this blocks common break-in attempts, scans for infections, and absorbs traffic spikes designed to knock a site offline.
  • Version control: every change to the site is tracked, so there’s a history to roll back to if an edit breaks something, or if an unauthorized one gets through.
  • Coderick AI payments: payments here run through Stripe’s hosted page, so card numbers never touch the platform’s underlying code. It’s one of several payment features in Coderick AI built to remove risk before you write a line of setup instructions.
Restore a previous version of project in Coderick AI

This lines up with security research on vibe-coded websites more broadly: build method is exactly why security gaps show up in the first place, which is why having some of it handled by default matters.

Where a developer still needs to check the rest

Coderick AI’s built-in Stripe checkout draws a clear line between what’s handled for you and what isn’t:

  • Handled without a developer: one-time purchases and recurring subscriptions.
  • Still needs a developer: splitting a single payment between multiple parties, a custom pricing engine, or a marketplace where customers shouldn’t see each other’s data.

Every AI website builder draws this same line somewhere, Coderick AI included. Look at code-free checkout options first to see how far you can get without a developer, then bring in one specifically for a paid app flow review once you know what needs custom logic.

Build an AI-built store your customers can trust

Are AI-built online stores safe for real payments once you’ve gone through that list? They sure can be, but only in the past tense, after you’ve actually run it against a live transaction, and not while it’s still sitting on a to-do list. Coderick AI is an AI builder with launch controls already pointed at the specific risks above: built-in authentication, inherited hosting security, version history, and Stripe checkout that never lets card data touch your code.

You’ll still want to run the checklist. Coderick AI just gets you started several items ahead, not at zero. If you’re ready to put a store in front of real customers and real payments, build your trusted AI project and run this same checklist against it before you take your first order.

[96]

Frequently asked questions

Are AI-built online stores safe for real payments?

Yes, AI-built online stores are safe for real payments when you verify checkout, payment status handling, and post-payment confirmation before launch, rather than assuming a finished-looking site is a tested one. The build method doesn’t determine safety. What you checked before your first real transaction does.

What makes an AI-built online store safe to launch?

An AI-built store is safe to launch once it passes eight checks: a clear offer, visible trust signals, upfront policies, minimal data collection, a working checkout, mobile compatibility, accurate payment status handling, and a tested confirmation flow. Skipping any one leaves a gap that only shows up once real money is involved.

Can an AI-built store process payments securely through Stripe?

Yes. An AI-built store can process payments securely through Stripe when Stripe processes the actual payment on its own PCI-compliant infrastructure, so card details never sit on your AI-built store’s servers. What still needs checking on your end is whether your store correctly reflects Stripe’s payment status back to the customer, since a secure processor doesn’t guarantee an accurate confirmation screen.

What should I test on an AI-built store before accepting real payments?

To test an AI-built store before launch, run a full transaction end to end: place a real order, use a card built to simulate a decline, cancel mid-checkout, and request a refund. Then repeat the same order on a phone. If any of those scenarios produces a confusing result for you or the customer, fix it before accepting a real payment from someone who isn’t testing.

What are the risks of using an AI-built online store?

The main AI-built store risks are unreviewed AI-generated content, like a wrong price stated with total confidence, thin post-payment handling with no clear status tracking, and gaps between what the builder covers by default and what still needs a developer, such as custom payment splits. None of these are reasons to avoid AI-built stores. They’re reasons to test one before it takes real money.

Shopify vs. WooCommerce vs. AI-built store: Choose by payments, setup, and control

Abstract of Shopify vs. WooCommerce vs. AI-built store

Searching “Shopify vs WooCommerce” for a business with no warehouse and nothing to ship, just a coaching package, a photography session, or a members-only newsletter, is the first sign you’re comparing the wrong two things. The real question is Shopify vs WooCommerce vs AI-built store, and it isn’t decided by platform popularity. What you’re actually selling decides it first, then payments, setup time, and long-term control decide it from there.

Key takeaways:

  • Shopify vs WooCommerce vs AI-built store comes down to one question: are you selling a product catalog, or something else?
  • An AI-built store skips the product catalog step and can go live with a working payment flow in hours, not weeks.
  • Coderick AI’s Stripe-based checkout accepts real payments for products, services, bookings, digital downloads, and subscriptions.
  • Service businesses, bookings, memberships, and portfolio sites rarely fit the product-catalog assumption behind a typical Shopify vs WooCommerce comparison.
  • If you need full inventory, tax, and multichannel tooling, a full platform earns its complexity. If you don’t, an AI-built selling flow usually gets you to a first sale faster.

Shopify vs. WooCommerce vs. AI-built store: What each option actually solves

Each option solves a different problem before it solves any feature comparison. Here’s what each one is actually built to do.

Shopify: a hosted, retail-ready ecommerce platform

Shopify is a hosted platform built for retail: a product catalog, cart, checkout, and fulfillment tools that work right out of the box. You don’t manage servers or software updates.

  • What’s included: Hosting, security patches, and PCI compliance, all handled inside Shopify’s own admin and theme system.
  • Entry cost: As of August 2026, the Basic plan runs $39 a month, or $29 a month billed annually, plus a 2.9% + 30 cent card transaction fee through Shopify Payments. Adding functionality beyond the core plan typically means paying for separate apps.
  • Next tier: The Grow plan, formerly called the “Shopify” plan in older comparisons, runs $105 a month (as of August 2026) and adds stronger reporting and up to five staff accounts.
  • The trade-off: A retail-ready storefront and predictable support, in exchange for a monthly subscription, a percentage of every sale, and costs that can climb quickly once you’re paying for apps to cover features the core plan doesn’t.

For a business selling 20 or 200 product variants, this level of out-of-the-box functionality is usually worth it. For a business selling one service package or a single paid course, it’s a lot of catalog infrastructure you’ll never use.

Worth knowing
SiteGround Ecommerce is a hosted, all-in-one store builder aimed at the same retail-catalog businesses Shopify serves. Instead of hunting down and paying for a separate app every time you need a new feature, the core pieces come built into the plan itself, running on SiteGround’s own hosting infrastructure for speed and uptime, with SiteGround’s support team behind it if something goes wrong.

WooCommerce: self-hosted control on WordPress

WooCommerce is a free, open-source plugin that turns a self-hosted WordPress site into a store. You own the code, the data, and the hosting account, and nothing about your setup is locked into a vendor’s theme system or app marketplace.

  • Core plugin: Free to install.
  • Real cost: A production-ready store realistically runs $500 to $3,000 a year once hosting, an SSL certificate, a premium theme, and a handful of paid extensions are stacked in, and that’s before a developer touches it.
  • Hosting range: Entry-level hosting often starts around $3 to $15 a month, though renewal rates are commonly higher, and costs climb further as a store’s traffic and resource needs grow.
  • What you get: Full code and data ownership, plus the entire WordPress plugin ecosystem, tens of thousands of extensions covering shipping, tax, subscriptions, and marketing.
  • The trade-off: Full ownership and lower platform costs, in exchange for an ongoing maintenance job and costs that climb as you add plugins to cover missing features. Plugin updates, security patches, and the odd conflict between extensions are yours to handle indefinitely, whether that’s your own time or a developer’s you’re paying for. If you haven’t run a WordPress site before, expect a real learning curve before any of it feels routine.
Adding WooCommerce as a plugin in WordPress

AI-built store: a custom selling flow, not a catalog platform

An AI online store builder isn’t a smaller Shopify or a simpler WooCommerce. It’s a custom online store with AI generating the structure from a plain-language description: tell it what you sell, and it builds the pages, forms, and checkout flow around that.

  • How it’s built: No product-catalog template to start from. The structure, pages, and forms come from your description, not a theme picker.
  • Payments: If you use a platform such as Coderick AI, the payment flow inside an AI build can run through Stripe. That means a generated site can accept cards, Apple Pay, and Google Pay directly.
  • The trade-off: Less catalog and inventory depth than Shopify or WooCommerce, in exchange for a setup that skips platform selection, theme shopping, and plugin configuration almost entirely.
An AI built website created by Coderick AI from a single prompt

Do you need a full ecommerce platform?

The fastest way to know if you need a full ecommerce platform is to count what you’re actually managing, including your catalog of physical products with variants, stock levels, and shipping rules. If that list is short, a full platform is solving problems you don’t have yet. Let’s break it down.

Signs a full platform earns its complexity

  • You stock 20 or more product variants, or manage physical inventory across more than one location.
  • You need multichannel selling: the same catalog listed on your site, a marketplace, and social shops at once.
  • You collect ecommerce sales tax across multiple states or countries and need automated calculation, not a spreadsheet.

If your business matches that list, a full platform, whether that’s Shopify, WooCommerce, or SiteGround Ecommerce is a more realistic starting point than an AI-built selling flow.

When a simple payment flow is enough

A simple payment flow is enough when your business model involves services, bookings, digital downloads, or paid access rather than a shelf of physical products. What you actually need is simply a payment-ready store, and not a complex catalog platform. That means a page that explains what you offer and a checkout that takes the payment. Easy as that.

Getting there without hiring a developer is the whole appeal of an AI-built store. You describe what you sell, and the builder generates a checkout without development and a working payment page without a line of code or an eye-crossing plugin stack to configure.

If your product list is short and stable, this is usually the faster and cheaper path to a first sale.

A website selling only one service with a simple payment flow

Shopify vs. WooCommerce vs. AI-Built Store at a glance

The table below distills payments, setup time, control, cost, and best-fit business type across all three selling setups.

DimensionShopify/ecommerce platformWooCommerceAI-built store (Coderick AI)
PaymentsShopify Payments or third-party gateways; 2.9% + 30 cents standard rateAny gateway via plugin: Stripe, PayPal, WooCommerce PaymentsPayment processor varies by builder; Coderick AI, for example, uses Stripe (and thus Apple Pay, and Google Pay)
Setup timeDays to weeks, including theme and app setupDays to weeks, plus hosting and plugin configurationHours for a basic selling flow
Control and customizationModerate; bound by themes and apps system, or more complex code editingHigh; full code and hosting ownershipLow to moderate; generated structure, limited deep customization
Ongoing maintenanceLow; handles hosting, security patches, and platform updatesHigh; you or a developer handle plugin updates, security patches, and the occasional plugin conflict indefinitelyLow; hosting and platform updates are handled by the builder
Typical annual cost$468 to $4,788+ plus transaction fees and apps$500 to $3,000+ plus developer time if neededSingle subscription; hosting included
Best-fit business typeRetail catalogs, multichannel sellersContent-and-commerce hybrids, custom integrationsServices, bookings, paid access, portfolios

Cost is rarely a single number on any of these three. The store cost tradeoffs above show why the advertised monthly price is only the starting point, not the realistic annual figure, once transaction fees, apps, extensions, or hosting are factored in.

Where Shopify and WooCommerce pull ahead of an AI-built store

The evidence here favors a full platform once a catalog gets complex enough to need real inventory and integration tooling.

Shopify vs. AI-built store: catalog, inventory, and multichannel selling

Shopify vs an AI-built store is a clear win for Shopify (or other competent ecommerce website builders) once your catalog crosses a few dozen SKUs. These are core ecommerce website builder features, not add-ons:

  • Built-in inventory tracking across multiple locations.
  • Product variants, such as size, color, and material, managed natively.
  • Native listings on sales channels such as Instagram, TikTok Shop, and Amazon, though the exact channel list varies by platform.

An AI-built store can generate a product page and working payment setup basics in an afternoon. It doesn’t come with inventory management as a built-in feature the way Shopify does, so stock tracking would have to be custom-described and built into the app itself, and keeping that in sync with a separate sales channel, a marketplace or an in-person POS, isn’t something an AI-built store can typically support. For a boutique with 200 SKUs across three sales channels, that gap will matter more than setup speed.

WooCommerce vs. AI-built store: content control and developer flexibility

WooCommerce vs an AI-built store comes down to ownership. WooCommerce gives you:

  • Full code access.
  • A WordPress content system built for long-form blogging and ecommerce SEO.
  • Access to tens of thousands of WordPress plugins, so almost any custom workflow, from a loyalty program to a booking calendar, can be built or bought (although often with added cost).
  • Straightforward payment data in your workflow: syncing orders into a CRM, an accounting tool, or a custom reporting dashboard.

That last one is harder to replicate on a generated AI build that isn’t designed for deep third-party integrations yet. If your business depends on content marketing alongside selling, or on a specific integration WooCommerce already supports, that flexibility is hard to give up.

Where an AI-built store pulls ahead of Shopify and WooCommerce

The evidence runs the other way for service-based, appointment-based, and access-based businesses, where a product catalog was never really the point.

Building an AI-built selling flow instead of a full store

Building an AI-built selling flow instead of a full store starts with a conversation and not a template picker. You describe what you’re selling and who buys it, and an AI builder for selling flows, such as Coderick AI, turns that into a custom selling flow: the pages, forms, and Stripe-based checkout built around your description. This means:

  • No theme to install.
  • No plugin stack to configure.
  • No separate hosting account: the site publishes on the builder’s own hosting the moment you’re ready.
  • Setup typically runs hours instead of the days or weeks a Shopify or WooCommerce launch usually takes once you count theme customization and app setup.

Before sending real customers to it, a short list of AI store launch checks, testing the checkout, confirming pricing and policies display correctly, and checking the mobile view, is worth running through.

For businesses that need more than a page and a checkout, such as a custom ecommerce app with account logins, saved orders, and a dashboard, the same plain-language approach applies: describe the added functionality, and it gets built into the generated site.

Creating an online store website with Coderick AI with a simple prompt

Selling services or taking paid bookings online without a product catalog

Selling services or taking paid bookings online doesn’t require a product catalog at all. It requires:

  • A page that explains the service.
  • A calendar or intake form.
  • A checkout.

An AI-built store can generate all three from a description of the service and the price. This is also where freelancers and small agencies benefit most: handling client selling projects, invoices, and one-off packages inside a generated selling flow skips the overhead of running a full store just to bill a handful of clients a month.

Choosing a platform for paid access, memberships, or gated content

The right choice here comes down to whether you need a member login and drip content, or a full store built around it.

  • Coderick AI can build a members-only area with sign-up, login, and gated pages.
  • A Stripe subscription handles the recurring charge itself.

For a creator or coach selling one membership tier, that’s a recurring revenue setup without a shopping cart, a product catalog, or checkout steps built for buying multiple physical items at once.

Running a portfolio, restaurant, or event-based business

Running a portfolio, restaurant, or event-based business rarely means managing SKUs:

  • A restaurant needs online ordering or reservations.
  • A photographer needs a booking calendar and a way to collect a deposit or shoot payment.
  • An event organizer needs ticket sales tied to a date, not a warehouse.

These are businesses built to sell without a product catalog, and an AI-built store, with Stripe handling the ticket or order payment, matches that shape more closely than a platform designed around stock-keeping units and shipping zones.

How to choose the right selling setup for a small business

Which selling setup is best for a small business depends on one thing first: what you’re actually selling, not which platform has the most reviews.

Start with your business model, not the platform

Start with your business model, not the platform name. Ask what you’re actually selling before you compare features: a product catalog points toward Shopify, WooCommerce (or other ecommerce platforms such as SiteGround Ecommerce), while services, bookings, or paid access point toward an AI-built store or a simple payment flow.

Weigh setup time against long-term control

Setup speed and long-term control rarely move together across these three options:

  • AI-built store: Live fastest, but the structure is generated from your description. A major redesign later usually means describing it again, not editing existing code.
  • WooCommerce: The most control and the most maintenance. Because the code is yours, you can move hosts or rebuild the front end later without starting over.
  • Shopify and similar hosted platforms, such as SiteGround Ecommerce: Sit in between, a subscription in exchange for less upkeep.

Plan for where you’ll need to grow

Think about how you’ll grow, and not just where you’re starting. If you’re not selling yet, or you’re not sure you’ll ever need a full product catalog, an AI-built selling flow gets you live and taking payments now instead of spending weeks setting up a platform you might not need. 

And if that product line does happen? Moving to Shopify or WooCommerce later means rebuilding there rather than exporting and continuing, which is a reasonable trade for the months you spent selling instead of waiting. A business that already knows it needs multichannel inventory can skip that step and start on the full platform directly.

If you’re selling…Start with…
A physical product catalog with 20+ SKUsAn ecommerce platform like Shopify, WooCommerce or SiteGround
A smaller catalog, with full code ownership as a priorityWooCommerce
Services, bookings, or a single paid courseAn AI-built store
Paid access, memberships, or gated contentAn AI-built store with a Stripe subscription
A portfolio, restaurant, or event-based businessAn AI-built store

Where Coderick AI fits compared to Shopify and WooCommerce

Coderick AI is built for exactly the businesses this article has been describing: services, bookings, memberships, portfolios, and short product lists that don’t need multichannel inventory or tax automation across a dozen jurisdictions. Instead of picking a theme and configuring plugins, you describe what you’re selling in plain language, and Coderick AI builds the pages, forms, and checkout around it, then keeps building as the business needs more: a booking calendar, a client portal, an invoice tracker, or an internal dashboard, all as part of the same project rather than a separate app or plugin.

It isn’t positioned as a Shopify or WooCommerce replacement for a retail catalog business; it’s a separate path for businesses that were never trying to run one.

  • How it works: Describe what you’re selling, connect a Stripe account, and Coderick AI generates the pages, forms, and checkout around that description.
  • What’s handled for you: Every project starts on a SiteGround-provided domain and publishes immediately on SiteGround’s own hosting, included in the plan, no separate hosting account to arrange. Connecting your own domain later, with SSL enabled automatically once it’s pointed, is a setting inside your account rather than a separate technical project, backed by the same support team behind SiteGround’s other hosting and ecommerce products.
  • Beyond the storefront: The same prompt-based approach can add a client portal, an invoice tracker, or an internal dashboard to the same project, not just the pages that take payment.
  • Checkout: The Coderick AI checkout setup runs on Stripe, taking cards, Apple Pay, and Google Pay for products, services, bookings, digital downloads, and subscriptions. Running through app checkout readiness, confirming the Stripe connection, testing a real charge, and checking the confirmation flow, takes a few minutes before sending customers to it.
Coderick AI SiteGrounds AI-powered platform in action creating an app

Choosing Shopify vs. WooCommerce vs. AI-built store decision comes down to fit

The right choice here was never about finding the best-reviewed platform. It comes down to naming what you’re actually selling before comparing a single feature, then letting that answer point you to Shopify, WooCommerce, or an AI-built store.

If that’s services, bookings, paid access, or a portfolio without a warehouse behind it, Coderick AI is built for exactly that path. Describe what you’re selling in plain language, and it generates the pages, forms, and Stripe-based checkout around it, with hosting and your domain already sorted. It keeps building as the business grows, too, into a client portal, an invoice tracker, or an internal dashboard, not just a bigger storefront. Create a selling flow with Coderick AI and go from a description to a working checkout in just hours.

[96]

Frequently asked questions

Should I use Shopify, WooCommerce, or an AI-built store?

Use Shopify or WooCommerce if you’re selling a physical product catalog with multiple SKUs, variants, or inventory across channels. Use an AI-built store, such as one built with Coderick AI, if you’re selling services, bookings, digital downloads, or paid access and want a working payment flow without managing a full ecommerce platform.

What’s the difference between Shopify, WooCommerce, and an AI-built store?

Shopify is a hosted, subscription-based platform built for retail catalogs. WooCommerce is a free, self-hosted plugin that turns WordPress into a store you fully control. An AI-built store generates a custom selling flow from a plain-language description instead of starting from a catalog template.

When should I choose Shopify over WooCommerce or an AI-built store?

Choose an ecommerce platform like Shopify or SiteGround when you want a hosted platform with built-in support, predictable updates, and native multichannel selling, and you’re willing to pay a monthly subscription plus transaction fees for that convenience.

When is an AI-built store enough to start selling online?

An AI-built store is enough when you need a payment-ready store for services, bookings, digital downloads, or paid access rather than a physical product catalog, and you want to accept payments without configuring a full ecommerce platform first.

Do I need a full ecommerce platform to sell online?

No. You need a full ecommerce platform only if you’re managing a product catalog with inventory, shipping, and tax across multiple channels. Services, bookings, and paid access can run on a simpler payment flow instead.

Can I sell online with a simple AI-built payment flow?

Yes. Platforms like Coderick AI can often connect to Stripe, so a generated site can accept cards, Apple Pay, and Google Pay for products, services, bookings, digital downloads, and subscriptions.

Is Shopify better for retail stores than AI-built stores?

Yes, for retail stores with a real product catalog. Ecommerce platform inventory tracking, product variants, and native multichannel listings handle catalog complexity that an AI-built store isn’t designed to manage at scale.

When is Coderick AI a better fit than Shopify or WooCommerce?

Coderick AI fits better when you’re selling services, bookings, memberships, or a short list of offerings rather than a full product catalog, and you want a working payment flow without configuring a separate ecommerce platform.

Can Coderick AI help me build a custom selling flow?

Yes, Coderick AI can help you build a custom selling flow. Describe what you’re selling and Coderick AI generates the pages, forms, and Stripe-based checkout around that description, without a theme, plugin, or template to configure first.

What should I compare before choosing an online store builder?

Compare what you’re actually selling, how much setup time you can spend before your first sale, how much control you want over code and hosting, and the realistic annual cost, not just the advertised monthly price, of each option.

Stripe CRM integration: Start accepting payments in the CRM app you already built

A digital graphic depicting payment integration and e-commerce analytics against a dark blue background. In the upper center, a floating white prompt box displays the text "Add a way for clients to pay.." next to a blue arrow action button. Below, a translucent glassmorphism dashboard shows "Monthly Shop Performance" metrics—including "Total Sales" of "USD 423.60," "Avg. Order Value" of "USD 117.67," and "Total Orders" of "24"—sitting above a "Most Recent Orders" table with highlighted order statuses like "COMPLETED." Floating on the right are payment UI elements, including a credit card icon with a green checkmark, alongside "PAID" and "UNPAID" status badges.

If you’ve already built your CRM app, payments are probably the piece you left for later. And no wonder: taking card details yourself makes you responsible for storing them safely, so you’ll probably want to hand that job to a payment provider your customers already recognize. For many CRM apps, that means integrating Stripe, one of the most trusted and widely used payment providers in the world.

Stripe CRM integration connects Stripe payments back to your customer records, so you can collect money from the same place you already track customers, and the payment status appears against the right person. It works two ways: connect Stripe to an off-the-shelf CRM, or build the payment flow into an app you own.

Key takeaways:

  • Stripe CRM integration puts payment status on the customer record. Instead of checking two systems, you see who has paid, what they bought, and what should happen next, in the place you already work.
  • Building it no longer means writing code. With an AI app builder such as Coderick AI you describe the payment behavior you want and it builds the checkout, then connects your own Stripe account.
  • The webhook is the source of truth, not the thank-you page. Stripe sends your app a separate message when a payment actually completes. Never record a payment based on the customer landing back on your site.
  • Granting access is only half the job. Refunds, disputes, and cancellations need handling too, or a refunded customer stays marked paid and keeps access indefinitely.
  • Test the whole thing before real money moves. Stripe’s test mode lets you run every path, including a card that deliberately fails, without charging anyone.

What Stripe CRM integration means

CRM payment integration means payment activity and customer records stay connected in the same system, so nobody reconciles a spreadsheet of payouts against a list of customers by hand. CRM payment processing can reach that point two ways, and which applies to you depends on where your customer data sits today.

RouteWhen it is the right answerWhat it involves
Connect Stripe to an off-the-shelf CRMYou already pay for a CRM that ships a Stripe connector, or supports one through an automation toolAuthorizing the connector and mapping fields
Build the payment flow into the app you already haveYou built your own CRM or app, your CRM has no connector, or the payment step needs to sit inside a workflow your CRM does not modelAdding a checkout step and a way for your app to record what Stripe confirms

Connecting Stripe to an existing CRM

If you already pay for a CRM that offers a Stripe connector, use it. Most major CRMs either ship one or reach Stripe through an automation tool, and setup is usually authorizing the connection and choosing which events update which fields.

Check two things first: what the connector actually syncs, since some bring across payments but not refunds or failed renewals, and whether it can trigger the workflow you care about rather than just showing a payment history.

Pro tip: Read the connector’s fine print before you rely on it. “Stripe integration” on a CRM pricing page can mean a live two-way connection, a one-way import of past payments, or just a link out to your Stripe dashboard. Only the first keeps a record current. Ask the vendor two questions before committing: does it write a refund back to the record, and can a payment trigger something, such as moving a stage or sending an email. If either answer is no, you will still be joining things up by hand.


Adding Stripe payments to the CRM app you already have

If you built the app yourself, there’s no connector to install. You’re not rebuilding anything. You’re adding a Stripe checkout step for the customer, and a way for your app to hear back from Stripe and update the right record. You can also add Stripe payments to Coderick AI projects, which puts that within reach without writing code.

This is also where an AI app builder for business workflows changes the practical difficulty, because the work is mostly wiring rather than something creating, and wiring is something you can easily describe in a sentence.

What has to happen in your CRM when a customer pays

It helps to understand the whole sequence:

  • Your app sends the customer to Stripe. They click a pay button on a customer record, an invoice, or a booking page.
  • Stripe collects the payment on its own page. Card details go to Stripe and never touch your app or its code, which is why you are not responsible for storing them.
  • Stripe sends your app a message confirming what happened. This message is called a webhook: your app has a URL that sits waiting, and Stripe posts an event to it when a payment succeeds, fails, or is refunded.
  • Your app updates the customer record. It matches the event to the right customer, marks them paid, records what they bought, and stores the Stripe reference.
  • The customer comes back to your app. They land on a confirmation page. This happens in parallel with the webhook and is not the same thing.

The customer’s return trip and Stripe’s message to your app are separate events. A customer can close the tab before returning and the payment still happened. Someone can reach your confirmation page without paying at all. Trust the webhook; the redirect exists so the customer sees something friendly.

There are two ways to take the payment, and the difference is how much of the flow lives inside your app.

A Stripe payment link is a hosted checkout page with its own URL, created in your Stripe dashboard or generated for you, with nothing to build. You can email it, put it on a booking confirmation, or store it against a customer record and send it when a job is done. Using Stripe payment links in CRM workflows is the quickest way to accept payments in CRM software you already run, and for many service businesses it is enough on its own.

The limit is that a bare payment link doesnчt know who clicked it. To have a payment land against the right record automatically, you pass an identifier through the link so the webhook can match it back, which is where the second option usually wins.

Stripe Checkout: when the payment sits inside the app

Stripe Checkout for CRM means your app creates the checkout at the moment the customer clicks and attaches your own identifiers, such as the customer ID and the job ID. Stripe still hosts the payment page, so card handling is unchanged, but the event that comes back carries those identifiers and the record updates itself.

Start with a payment link if you want money moving this week. Move to Checkout when you want the payment status to appear on the right record without anyone copying anything across.

How to add a payment flow with Coderick AI

If you build your CRM app with Coderick AI, you can add Stripe payments by describing the payment behavior you want in the chat and it builds the flow, including the products, the checkout, and the confirmation page.

A specific prompt is more useful than “add payments.” You can name the record, the trigger, and what should change afterward. Something closer to this:

“Add Stripe payments to my app so I can collect payment on a sale. Add a ‘Collect payment’ button on each sale that opens Stripe Checkout for the sale’s value, and mark the transaction as paid once the payment succeeds.“

Here’s an example of what Coderick AI gives you after this prompt: an option to integrate Stripe right in the chat.

A screenshot of the SiteGround Coderick AI web development interface showing a split view with an AI assistant on the left and a live application preview on the right. The left panel features an AI response regarding Stripe payment setup, a Stripe integration prompt with a "CONNECT" button, a credit usage alert, and a prompt input asking "What do we build next?" The right panel displays a preview of a web application titled "Ledger SALES DESK," showcasing a dark panel with the headline "Every lead, deal, and follow-up on one desk." beside a login form featuring email and password fields, a dark "Sign in" button, and a "Create an account" link.

The Collect payment button, the hand-off to Stripe, and the confirmation page are all ready; your Stripe key is what’s missing, so the chat says so plainly and shows a Connect card underneath. Click Connect and a dialog asks for your Restricted Key, which you copy from your own Stripe account. It goes in that dialog, never into the chat. A checkpoint is saved at the same moment, so you can preview what was built or roll back to it if the next change goes wrong.

Coderick AI connects to Stripe using a Restricted Key rather than your main secret key, so you choose exactly which permissions to grant, and a key beginning rk_test keeps you in test mode until you swap in rk_live. And the key goes into the connection dialog, never into the chat itself. The full setup guide covers creating the key and what each permission does.

What this doesn’t do is remove your responsibility to understand the flow. The builder handles the wiring. You still decide what happens after a refund, who can see paid features, and what the record should say.

Six CRM payment-flow mistakes that break payment status

These are the failures that cost real money, and they are the reason a payment flow can look finished while being wrong. Each one is worth checking whether you built the flow yourself, had it built, or described it to an AI builder.

What goes wrongWhat the business actually seesWhat to do instead
Duplicate webhook eventsStripe occasionally retries an event. A naive database insert records one payment twice, so two paid orders exist for one payment and CRM revenue stops matching StripeCheck whether the Stripe event ID has already been processed before acting, or make the write an update keyed on the Stripe object ID so repeats overwrite rather than duplicate
No revocation pathOnly the payment-succeeded event is handled. After a refund, a chargeback, or a failed renewal, the record stays marked paid and the customer keeps access indefinitelyHandle refund, dispute, and cancellation events too. Granting access is half the job; removing it is the half that gets forgotten
Access checked only in the browserA customer edits JavaScript in their own browser and reaches paid features without payingEnforce every paid-feature check on the server, not in frontend code
Trusting the success redirect instead of the webhookA customer closes the tab after paying and is never recorded as paid. Or the success page is reached without any payment completingTreat the webhook as the source of truth for payment state. The redirect is for the customer’s experience, not for your records
Secret key exposedThe Stripe secret key ends up in frontend code or committed to a repository, where anyone who finds it can use it against your accountKeep secret keys server-side only, never in frontend code and never committed. Prefer a restricted key scoped to just the permissions the integration needs
No webhook signature verificationA forged request marks orders as paid without any money movingVerify the webhook signing secret on every incoming event before processing it

These six mistakes cost money in more ways than the missed sale. Stripe keeps its processing fee when you refund a payment and charges a separate fee for every dispute, so a refunded customer who keeps access costs you the sale, the fee, and whatever you go on delivering to them. Factor those payment gateway fees into your prices before launch. None of this is specific to Stripe either. PayPal, Square, and most other providers also confirm payments through webhooks, retry failed deliveries, and sign their events, so the same six checks apply whichever provider you use to add payments to an AI-built app.

If the payment worked but the record didn’t update, Stripe will tell you why. Your Stripe dashboard logs every event it tried to send your app, whether your app answered, and what it said back. That log separates three very different problems: Stripe never sent the event, Stripe sent it and your app never answered, or your app answered with an error. Without it you are guessing which half of the flow is broken.

How to test before you take real money

Stripe gives you a complete test environment, so you can be wrong for free. Run all of this before a real card is involved.

  • Connect in test mode first. Keys beginning rk_test or sk_test cannot move real money, so nothing you do here can charge anyone.
  • Pay with Stripe’s test cards. Stripe publishes card numbers that always succeed, so you can complete the entire flow yourself and watch the record update.
  • Run the declined-card path deliberately. Stripe also publishes cards that always fail. Use one, and check that your app does not mark anyone paid.
  • Close the tab immediately after paying. This is the test almost nobody runs, and it is the one that catches a flow relying on the redirect. If the record still updates, your webhook is doing its job.
  • Refund the test payment in your Stripe dashboard. Then check whether the customer record went back to unpaid and whether access was removed. If it did not, you have found the revocation gap before a real customer did.

Only once all five behave correctly should you swap in your live key. On Coderick AI, that means replacing the test key from the Integrations menu, and the test to live mode guide covers the switch.

Test mode and live mode are separate worlds, and nothing crosses over. Products, prices, customers, and payment links created in test mode do not exist in live mode, and neither do your webhook settings. So the first live payment is not the test flow with real money in it, and a flow that worked on Friday can fail on Monday because what it pointed at was never created on the live side. After switching keys, run one small real payment to yourself and refund it before sending anything to a customer.

What payment status in your CRM should show after someone pays

This is what justifies having a CRM rather than just a checkout. A payment is a fact about a customer that should change what happens next.

At minimum, the customer payment status should distinguish four states rather than a single paid checkbox: unpaid, paid, refunded, and failed or overdue. A checkbox cannot represent someone who paid and was then refunded, which is the case that causes trouble later.

Alongside the status, store what they bought, the amount, the date, and the Stripe reference, so any record traces back to the transaction in your Stripe dashboard. Stripe stays the system of record for the money, and your app holds what the money means.

Then let the status do some work. Paid can trigger the onboarding email, move the deal stage, or schedule the booking. Overdue surfaces the record in a follow-up list. Refunded revokes access and flags the account. Tracking paid and unpaid customers in a CRM only pays off when the status changes something automatically, which is the reason to put payments where the customer data already lives.

Stripe handles the money, your app handles the meaning

Stripe CRM integration is easier to reason about once the division of labor is clear. Stripe takes the card, checks it, moves the money, and keeps the authoritative record of every transaction. Your app decides what that payment means for the customer: what they now have access to, what stage they are at, and what should happen next.

Almost everything that goes wrong is the second half falling out of step with the first. The payment succeeds and the record does not update, or the refund goes through and the access stays on. Build the checkout, then spend your remaining effort on the states, the revocation path, and the tests above.

[96]

FAQs

What is Stripe CRM integration?

Stripe CRM integration connects Stripe payment activity to CRM customer records, so payments can be collected from the same workflow where you already track customers and the resulting payment status appears against the right record. It can mean connecting Stripe to an off-the-shelf CRM, or building the payment flow into an app you own.

How do I add Stripe payments to a CRM?

To add Stripe payments to a CRM, either enable your CRM’s Stripe connector, or add a checkout step and a webhook handler to an app you built. The connector route is faster when it exists. The build route is what you use when the CRM is your own.

Can I connect Stripe to a CRM app I already built?

Yes. You can connect Stripe to a CRM app you already built without rebuilding it. You add a checkout step for the customer and a webhook handler that updates the customer record when Stripe confirms the payment.

Can a CRM track Stripe payment status?

Yes. A CRM can track Stripe payment status when your app listens for Stripe webhook events and writes the result to the customer record. The webhook, not the browser redirect, is what tells you a payment actually completed.

How do I connect Stripe payments to customer records?

To connect Stripe payments to customer records, pass an identifier such as the customer ID through the checkout session, then read it back from the Stripe event and update the matching record. Without that identifier, a payment arrives with no reliable way to tell whose it was.

Can Coderick AI build a CRM that accepts Stripe payments?

Yes. Coderick AI can build an AI-built CRM with Stripe payments. You describe the payment behavior you want in the chat, connect your Stripe account with a restricted key, and it builds the checkout, the products, and the confirmation flow around your existing records.

Can I use Stripe Payment Links inside a CRM workflow?

Yes. To use Stripe payment links inside a CRM workflow, store a link against a customer or job and send it when payment is due. To have payments land against the right record automatically, pass an identifier through the link or use Stripe Checkout instead.

How do I track paid and unpaid customers in a CRM?

To track paid and unpaid customers in a CRM, store a payment status on each record that covers unpaid, paid, refunded, and overdue, updated from Stripe webhook events rather than entered by hand.

What should happen in a CRM after a customer pays through Stripe?

After a customer pays through Stripe, the CRM should mark the record paid, store what they bought and the Stripe reference, and trigger whatever comes next, such as granting access, moving the deal stage, or sending onboarding. It should also be able to reverse all of that if the payment is later refunded.

Legal requirements for email marketing: 7 rules that keep you out of trouble

Man reviewing an email marketing campaign on his laptop, with an inbox preview showing a promotional email

A single non-compliant email can cost you up to $53,088 under the CAN-SPAM Act alone, and that’s before GDPR, CASL, or your state’s privacy law get involved. Here’s what each one actually requires, and how to meet every legal requirement for email marketing without a law degree.

Key takeaways:

  • The legal requirements for email marketing come from at least four sets of email marketing laws depending on your subscriber list: CAN-SPAM (US), GDPR (EU/UK), CASL (Canada), and a growing list of state privacy laws.
  • CAN-SPAM’s maximum civil penalty is $53,088 per non-compliant email, set by the FTC’s inflation adjustment effective January 2025.
  • The FTC’s largest CAN-SPAM settlement to date is $2.95 million, against a company that sent over 30 million commercial emails without a working opt-out.
  • You have 10 business days to honor an unsubscribe request under CAN-SPAM, and your opt-out link has to stay functional for at least 30 days after each send.
  • CAN-SPAM is an opt-out law; GDPR and CASL are opt-in laws. Sending the same campaign to a US list and a Canadian list can mean two different consent requirements.
  • Legal compliance and deliverability aren’t the same thing. You can meet every legal requirement and still land in spam if your content mix, image ratio, or send frequency work against you.

The legal requirements for email marketing are: an honest, non-misleading subject line, a valid physical mailing address, accurate sender information, and a working unsubscribe link you honor within 10 business days. 

Depending on where your subscribers live, you may also need documented opt-in consent before you send anything, which is the case under GDPR and CASL. Most guides treat the US baseline and the international consent rules as two separate topics. In practice, they’re one checklist to run through before every send, and which parts apply to you depends entirely on your subscribers’ location.

Email marketing laws by region: which ones apply to your list

Which of these email marketing laws applies to you depends entirely on where your subscribers live, not where your business is registered.

LawWho it coversConsent modelPenalty ceilingDistinguishing requirement
CAN-SPAMUS recipientsOpt-out$53,088 per emailNo prior consent needed to send a first email
GDPREU/UK recipientsOpt-inUp to 4% of global annual revenue or €20 millionRequires a documented lawful basis before sending
CASLCanadian recipientsOpt-inUp to $10 million CAD per violationConsent must be express or implied under narrow conditions
State privacy lawsVaries by state (e.g., California, Colorado, Virginia)VariesVaries by stateGrants recipients the right to know what data you hold and to request deletion

CAN-SPAM Act (email marketing law in the United States)

The CAN-SPAM Act doesn’t require permission before you send a first commercial email to a US address. What it requires instead is honesty and an easy way out: accurate header information, a non-deceptive subject line, a valid physical postal address, and a clear unsubscribe mechanism you have to honor within 10 business days. It applies to B2B email just as much as B2C. The FTC has said plainly that the law makes no exception for business-to-business messages.

GDPR (EU and UK subscribers)

If your list includes anyone in the EU or UK, GDPR shifts the entire model from opt-out to opt-in. You need a lawful basis, usually explicit consent, before you send anything, and you have to be able to show when and how that consent was collected. 

There are two narrower exceptions worth knowing. B2B email to a named contact at a company can sometimes rely on “legitimate interest” instead of consent. And in the UK specifically, PECR‘s “soft opt-in” lets you email existing customers about similar products without fresh consent, as long as you gave them a clear opt-out when you first collected their details.

GDPR also gives subscribers the right to request a copy of their data or ask you to delete it, which means your email platform needs a way to actually locate and remove someone’s records, not just unsubscribe them from future sends.

CASL (Canada’s anti-spam law)

Canada’s Anti-Spam Legislation is one of the stricter regimes in the world. It requires express or implied consent before you send, identification information in every message, and an unsubscribe mechanism that works immediately, not within a grace period. Penalties can reach $10 million CAD per violation, which makes CASL worth taking seriously even if Canadian subscribers are a small slice of your list.

State privacy laws (CCPA/CPRA and newer state laws)

State-level privacy laws don’t regulate email sending directly the way CAN-SPAM does, but they regulate the data behind your list. As of 2026, around 20 US states, including California (CCPA/CPRA), Colorado, Connecticut, and Virginia, have their own comprehensive privacy laws, with Indiana, Kentucky, and Rhode Island the newest additions, effective January 2026. These laws give recipients the right to know what personal data you’ve collected, opt out of its sale, and request deletion. If a subscriber invokes that right, you need a process for finding and removing their information across your entire email platform, not just your active list.

The 7 email marketing requirements every campaign must meet

Regardless of which laws apply to your list, these seven requirements cover the ground CAN-SPAM, GDPR, and CASL all care about in some form. Meet all seven and you’ve handled the overwhelming majority of what gets a business in trouble, whether the fine comes from the FTC, an EU regulator, or Canada’s CRTC.

1. Accurate header and sender information

The “From,” “To,” and routing information in your email has to accurately identify the person or business that sent it. Using a domain name or email address you don’t have the right to use, even to make a promotional email look more personal, is itself a CAN-SPAM violation.

2. Honest, non-deceptive subject lines

Your subject line has to reflect the actual content of the message. A subject line like “Re: your account” on a promotional email you’re sending cold is the kind of deception the FTC treats as a violation on its own, independent of anything else in the email.

3. A physical postal address

Every commercial email needs a valid physical postal address. This can be your current street address, a post office box registered with the USPS, or a private mailbox registered with a commercial mail-receiving agency. A missing address is one of the most common reasons the FTC cites in enforcement actions. 

If you’re using SiteGround Email Marketing, you’ll need to add your business address to your template yourself.

Recipients need an obvious, functioning way to opt out, and that mechanism has to keep working for at least 30 days after you send (60 for CASL). 

SiteGround Email Marketing includes a working unsubscribe link in every email automatically, so this one’s handled without any setup on your end.

Email newsletter template with a cafe and coffee photo, ending with an Unsubscribe link in the footer

5. Processing opt-outs within 10 business days

Once someone unsubscribes, you have 10 business days to stop emailing them under both CAN-SPAM and CASL. Under CAN-SPAM specifically, you also can’t sell or transfer their address to anyone else once they’ve opted out. GDPR doesn’t set a fixed deadline, but requires you to honor the withdrawal “without undue delay,” so treat 10 business days as the outside limit, not the standard, if any EU or UK subscribers are on your list. 

SiteGround Email Marketing processes opt-outs immediately, so there’s no delay to track manually.

For any subscriber under GDPR or CASL, you need to be able to show when and how they consented, not just that they’re currently on your list. That means storing timestamps, the specific opt-in method used, and the exact language they agreed to, since “we’ve always had them on the list” isn’t a defense under either law.

7. Distinguishing ads from other messages, where required

Some jurisdictions require commercial messages to be clearly identifiable as advertising, separate from transactional or relationship emails like receipts and password resets. Mixing promotional content into a transactional email can pull that message under commercial-email rules it wouldn’t otherwise be subject to. Getting your double opt-in process right from the start makes this distinction easier to maintain, since you’re not retrofitting consent records after the fact.

TL;DR: What this means for you

RequirementAutomationYour responsibility
Unsubscribe mechanismAutomated by some ESPs (email service providers), including SiteGround Email MarketingVerify it works and stays live 30 days (60 for CASL) if your platform doesn’t confirm this, or test regularly regardless
Opt-out processingAutomatic and immediate with SiteGround Email MarketingConfirm your platform processes opt-outs within 10 business days, or build a manual process if not
Physical postal addressNoneAdd your business address to your template yourself, regardless of platform
Consent management (GDPR)A named feature on some platforms, confirmed for SiteGround Email Marketing via its own documentationConfirm whether your platform logs timestamp, opt-in method, and consent language, since GDPR requires being able to prove this
Consent logging (CASL)Not confirmed as automated on any specific platform in this researchKeep your own log of timestamp, method, and language for Canadian subscribers
Sender info, subject lines, physical addressNot automatable, this is content you writeAccurate and honest on every send, regardless of platform
Documented consent (EU, UK, Canada)Not automatable, this is a record you keepProof of when and how each subscriber opted in

What happens if you break these email marketing laws (real penalty figures)

The FTC’s maximum CAN-SPAM penalty is $53,088 per non-compliant email, not per campaign. Send one broken unsubscribe link to 10,000 addresses, and that’s 10,000 separate violations, not one mistake.

In practice, the FTC rarely goes for the theoretical maximum. Two real cases show what actually happens:

  • $2.95 million: a company sent over 30 million commercial emails without honoring opt-outs or including a physical address.
  • $650,000: a company disguised marketing emails as account notifications, again over a missing working opt-out.

Neither case involved proof of bad intent. A broken link and an outdated template were enough.

This is also why cleaning your list regularly matters beyond deliverability: bad data is what turns one small mistake into thousands of separate violations.

Opt-in vs. opt-out: which laws require which consent model

Not every law treats permission the same way. Some let you email first and ask forgiveness later; others require a yes before you send anything at all.

LawConsent modelWhat it means in practice
CAN-SPAM (US)Opt-outYou can send a first commercial email without permission, as long as you honor opt-outs promptly and meet every other requirement.
GDPR (EU/UK)Opt-inYou need documented consent before you send anything.
CASL (Canada)Opt-inSame as GDPR: consent has to come first, and you need to be able to prove it.

If your list spans multiple regions, apply the stricter opt-in standard to everyone rather than segmenting by region. It’s simpler to manage than running separate consent processes per country, and since GDPR and CASL are both stricter than CAN-SPAM, meeting their bar automatically covers you under CAN-SPAM too.

Understanding why people unsubscribe also helps you spot when a consent problem, not a content problem, is driving your opt-out rate.

Four sending rules that keep subscribers engaged (and out of spam)

None of these sending rules are legal requirements, but ignore them and you can be fully compliant on paper and still watch your open rates drop and your emails land in spam anyway.

The 80/20 rule: balancing value and promotion

The 80/20 rule says roughly 80% of your email content should be genuinely useful to the reader, education, updates, or resources, with only about 20% direct promotion. This is a content-mix guideline, not a spam-filter rule: lists that get promotional email after promotional email tend to disengage and unsubscribe at a higher rate, which is what damages your sender reputation over time, not the ratio itself.

The 60/40 rule: why your text-to-image ratio affects deliverability

The 60/40 rule refers to keeping your email body at roughly 60% text and no more than 40% images. This one is a genuine deliverability lever: spam filters flag image-heavy emails with little text more aggressively, since that pattern historically correlates with spam. An email that’s almost entirely one large image is a common trigger for inbox providers to route a message to the promotions tab or spam folder.

Safe send frequency: how often is too often

There’s no single legal limit on how often you can email someone, but sending too frequently is the fastest way to trigger complaint rates that hurt your deliverability across your entire list, not just with one annoyed subscriber. A reasonable starting cadence for most small business lists is one to two emails per week, adjusted based on your unsubscribe and complaint rates rather than a fixed schedule. If you’re running cold email outreach alongside your list, the frequency math works differently since you’re not yet working with a warmed, consenting audience.

Gmail and Yahoo’s bulk sender rules

If you send 5,000 or more emails a day to Gmail or Yahoo addresses, there’s a fourth rule that isn’t a law but hits faster than one: authenticate your domain (SPF, DKIM, DMARC), add one-click unsubscribe headers to every marketing email, and keep your spam complaint rate under 0.3%, ideally under 0.1%. CAN-SPAM might fine you eventually. Gmail will just stop delivering your email next week.

A pre-send legal compliance checklist for legal email marketing

Before you hit send on any campaign, confirm:

  1. Your sender name and reply-to address are accurate and belong to your business.
  2. Your subject line matches the actual content of the email.
  3. A valid physical postal address appears somewhere in the email.
  4. Your unsubscribe link is visible, one-click, and tested.
  5. You have a process to honor opt-outs within 10 business days.
  6. Any EU, UK, or Canadian subscribers have documented, timestamped consent.
  7. Your list has been cleaned recently, since sending to invalid or complained-about addresses raises both legal and deliverability risk. Your email unsubscribe rate is a useful early signal that something on this list is off before it becomes an enforcement problem.

Stay compliant without hiring a lawyer

You don’t need a law degree to get this right. You need a platform that treats compliance as the default, not a plugin you have to remember to install.

Four laws, one small business, and about zero interest in reading legal text. That’s the actual math most people are working with. The good news: none of it requires memorizing statutes. It requires picking a process where the boring, easy-to-forget parts happen automatically instead of living on a sticky note.

Ready to send your next campaign without wondering if you missed something? Try SiteGround Email Marketing and get your first compliant send out the door in minutes.

[58]

What is the 80/20 rule in email marketing?

The 80/20 rule in email marketing means about 80% of your email content should provide value to the reader, like tips, updates, or resources, and no more than 20% should be direct promotion. It’s a content-mix guideline aimed at keeping subscribers engaged, not a legal requirement.

What is the 60/40 rule for email?

The 60/40 rule for emails recommends keeping your email body at roughly 60% text and 40% or less images. Image-heavy emails with little text are more likely to get flagged by spam filters, so this ratio helps protect deliverability.

Is it illegal to send emails without an unsubscribe option?

Yes, it is illegal for commercial emails sent to US recipients. CAN-SPAM requires a clear, working unsubscribe mechanism in every commercial email, and failing to include one is one of the most common reasons the FTC pursues enforcement action.

What is the 30/30/50 rule for cold emails?

The 30/30/50 rule is a cold email outreach guideline suggesting roughly 30% of your effort go toward list building and targeting, 30% toward subject lines and personalization, and 50% toward the email body and offer itself. It’s a resource-allocation framework, not a legal standard.

What email marketing laws apply in the United States?

The main federal law is CAN-SPAM, which requires accurate sender information, an honest subject line, a physical postal address, and a working unsubscribe option honored within 10 business days. On top of that, depending on where your subscribers live, state privacy laws like California’s CCPA/CPRA may also apply, giving recipients the right to know what data you’ve collected and request its deletion. CAN-SPAM applies nationwide regardless of state; state privacy laws are additional, not a replacement.

AI email subject lines: How to prompt better than everyone else

Comparison of a vague AI prompt producing a generic subject line versus a specific prompt with audience, tone, goal, and past winners producing "3 spots left for Friday"

Give AI the right inputs, and it’ll write a subject line good enough to make your best draft nervous. Skip them, and it defaults to the safest, most forgettable pattern it knows. The fix isn’t a different tool. It’s a better prompt, and that holds whether you’re using ChatGPT, Claude, Gemini, or the generator built into your email platform.

Key takeaways:

  • AI email subject lines only sound generic when the prompt behind them is generic; the tool isn’t the bottleneck.
  • A structured prompt (audience, tone, goal, and a few real examples) consistently outperforms a one-line request, in any AI tool.
  • ChatGPT, Claude, and Gemini can produce noticeably different subject lines from the identical prompt, so it’s worth testing more than one.
  • Treat every AI-generated subject line as a first draft to test, not a finished answer.
  • SiteGround Email Marketing’s built-in AI generator uses the same inputs this framework covers: tone, email type, and a short description.

Why your AI email subject lines all sound the same

AI-generated subject lines sound interchangeable because most prompts only give the model one piece of information: the topic. Ask any tool to “write a subject line for my sale” and it has to invent the audience, the tone, and the goal on its own, so it defaults to the safest, most generic pattern it knows.

What generic prompts leave out

A one-line prompt skips four things a human copywriter would be less likely to skip: who’s reading it, what tone fits the brand, what the reader should do next, and what similar lines have worked before. Without those, the AI fills the gaps with whatever’s statistically common: urgency words, vague benefit claims, and a tone that could belong to any brand. That’s why five different tools, given the same bare-bones prompt, tend to hand back five versions of the same line.

What AI tools for email subject lines actually do

An AI email subject line generator is only as good as what you feed it. The tool isn’t the problem; the input is, and that’s true whether you’re using a dedicated generator or typing straight into ChatGPT.

Most tools take one input (a topic or a pasted email) and return five to ten options in seconds. That’s genuinely useful for speed, but it comes at a cost.

What they don’t know unless you tell them

Speed doesn’t buy you relevance. A generic prompt means the tool doesn’t know your audience, your brand voice, or what’s worked before, unless you tell it. Here’s what telling it looks like in practice: SiteGround Email Marketing’s AI subject and preheader generator has a sparkle icon on the Subject field. Click it, choose “Describe your email” instead of just scanning your draft, and add a tone and email type before you generate.

SiteGround Email Marketing editor showing the Generate with AI button next to the subject line and preheader fields

Using an AI tool to optimize subject lines you’re not sold on

If you’ve drafted a subject line and it feels flat, vague, or too long, don’t ask an AI tool to write a new one from scratch. Paste in the line you have and ask it to fix a specific weakness: “This subject line is too vague. Rewrite it to name the specific offer, still under 50 characters.” Targeted edits like this outperform a fresh generation, because you’re pointing the model at exactly what’s wrong instead of hoping it guesses right.

This also works after the fact, but for your next similar campaign rather than the one that already went out. That is, if last month’s newsletter subject line got a weak open rate, paste that line in and ask the AI to fix the specific issue (too generic, too long, buried the offer) before you draft this month’s version.

The AI email subject line prompt framework: what actually changes the output

Four inputs consistently separate a sharp AI-generated subject line from a flat one: audience, tone, goal, and a few real examples to anchor the pattern. These aren’t specific to subject lines — they’re the same dos and don’ts that make any ChatGPT prompt sharper; this section applies them to one specific, high-stakes line of copy.

Audience and segment context

Name a real segment, not a generic description. “Write for our customers” tells the AI nothing useful. “Write for subscribers in the VIP group” or “for people who clicked but didn’t buy in our last campaign” gives it a specific reader to write for, and both are segments you can actually build: the first from a group you’ve already set up, the second by filtering that campaign’s Recipient Activity by action and assigning those contacts to a group.

Brand voice and tone

State the tone explicitly, and say what to avoid as clearly as what to include. “Warm, a little playful, no corporate language” works better than “professional,” which every brand claims and none of them mean the same way. Naming what you don’t want (no fake urgency, no exclamation marks, no clickbait) closes off the model’s default fallback patterns.

Campaign goal and desired emotion

Tell the AI what you want the reader to feel and do, not just what the email is about. “Get them to open out of curiosity” produces different output than “get them to open because they’re worried they’ll miss the deadline.” The goal shapes word choice more than the topic does.

Why AI puns in email subject lines fall flat

AI-generated puns read as generic more often than they read as clever, because the model reaches for the most statistically common wordplay for a given topic, and so does every other brand asking for the same thing.

A few you’ll see constantly, because every AI tool reaches for the same ones:

  • Coffee sale: “Brew-tiful savings,” “Perk up your day”
  • Summer sale: “Hot deals, cool prices,” “Sun’s out, savings out”

If a prompt calls for humor, ask for specificity instead. It lands better and reads less like a template:

  • Generic pun: “Don’t let your cart get cold”
  • Specific detail: “That candle’s been in your cart since Tuesday. We’re not judging, but we did notice.”

Show, don’t just tell, examples of what you want

Once the other three inputs are set, give the AI three to five proven subject-line patterns as examples of the shape you want, not just descriptions of a shape. Here’s what that looks like for three reliable patterns:

  • Curiosity gap: “Why your neighbor’s WiFi is faster than yours” — names a gap, doesn’t close it, and it’s specific enough to feel like it’s about you.
  • Specific number: “7 people just grabbed the last size in navy” — a real number reads as true; “almost sold out” reads as filler.
  • Direct benefit: “Your package skipped the line, arrives Thursday” — states the outcome and makes it feel a little lucky, no framing needed.

Paste three to five lines like these into the prompt (your own past lines if you have strong ones, or examples like these if you don’t) and ask the AI to write new subject lines “in this style.” This is a few-shot prompting: showing the model real examples of the pattern, rather than describing the pattern in the abstract, gets it to copy the structure instead of guessing at it.

Before and after: a staged prompt, from vague to fully structured

Watching a prompt evolve makes the mechanism visible. Start with the vague version, then add one variable at a time:

  1. Vague: “Write a subject line for our summer sale.”
  2. Add audience: “Write a subject line for our summer sale. The audience is returning customers who bought last summer.”
  3. Add tone: “…Keep the tone confident and a little playful, not salesy.”
  4. Add goal and constraint: “…The goal is to get them to shop the new collection before it sells out. No exclamation marks, no ‘don’t miss out.'”

Each stage narrows what the AI can guess at, so the output gets sharper. By stage four, the model has almost nothing left to invent.

Here’s how the results look in practice with different models:

StagePromptChatGPT (direct, benefit-led)Claude (conversational, natural)Gemini (concise, structured)
1. Vague“Write a subject line for our summer sale.”☀️ Summer sale: Hot deals, cool prices!Summer sale: up to 40% off, ends Sunday☀️ Summer Sale is LIVE: Grab your favorites before they’re gone!
2. + Audience“…The audience is returning customers who bought last summer.”☀️ Summer’s back—and so are your favorite dealsYou’re back for round two? Summer sale starts nowJust like last year, but better: Your exclusive summer deals are here!
3. + Tone“…Keep the tone confident and a little playful, not salesy.”☀️ You’re back. Summer is too.You again? Good. We saved you the good stuff.😎 Ready for round two? Let’s make this summer even better than the last.
4. + Goal and constraint“…Get them to shop the new collection before it sells out. No exclamation marks, no ‘don’t miss out.'”☀️ Your summer favorites just got a refreshYou again? Good. The new collection won’t wait.Your favorite pieces from last year are back, along with what is next.

Why ChatGPT, Claude, and Gemini don’t give you the same email subject line

As you just saw, giving ChatGPT, Claude, and Gemini the exact same structured prompt still produced three different subject lines, not because one of them failed to follow the prompt, but because each model weighs instructions and word choice differently. A thin prompt makes any tool sound generic, but even a strong prompt won’t make every tool sound identical.

What changes between models, and why

Every large language model is trained on different data and tuned with different priorities, so identical instructions land differently, as the table above shows. ChatGPT kept its emoji through every stage and leaned toward tighter, benefit-forward phrasing. Claude never used an emoji or an exclamation point, even at stage 1, and wrote the most conversational lines of the three. Gemini ran the longest, most descriptive lines and was the only one to add urgency language before the constraint told it not to.

None of these are wrong. They’re different defaults, and the only way to know which fits your brand is to test more than one.

ModelTends towardBest for
ChatGPTDirect, benefit-led phrasingFast iteration, high volume of options
ClaudeConversational, natural toneBrand voice that leans personal
GeminiLonger, descriptive phrasingDetailed context, though watch for added urgency language

Testing one prompt across models without juggling logins

Running the same prompt through multiple models used to mean separate logins and separate subscriptions. SiteGround AI Studio gives access to Gemini, Claude, and ChatGPT from one workspace, so you can run the identical prompt across all three and compare results side by side instead of settling for whichever tool you happened to open first.

How to test which AI subject line gets the most opens

There’s no subject line that wins for every list. The fastest way to find out which one wins for yours is a same-audience A/B test, not a best guess.

  1. Start with the options you already have. Most AI tools return three to five subject lines from a single prompt anyway, so you don’t need a separate step to generate variety; it’s already sitting there.
  2. Pick your two strongest. Look for the ones that feel most specific to your brand, not the most generic-sounding “safe” choice.
  3. Split a small percentage of your list (5 to 10%, if your platform allows it) and send each version to one half.
  4. Wait for a real read on opens, not just the first hour. Most lists show a meaningful open-rate gap within 2 to 4 hours.
  5. Send the winner to the rest of the list. Whichever line pulled a higher open rate on the test group is the one to trust, not the one that sounded best in the moment.

Better AI email subject lines start with a better prompt

Name the audience, state the tone, give it a goal, show it what’s worked before. Do that consistently, and the subject lines stop sounding like everyone else’s inbox and start sounding like something worth actually testing.

SiteGround Email Marketing’s built-in AI generator already runs on this logic, whether you knew it or not. Add a tone and an email type before you hit generate, then lean on “Improve Writing” instead of starting from scratch. You’ve been prompting like a pro since before you finished this article. 

And if you want the framework to go further than just the subject line, SiteGround Email Marketing’s AI email generator now builds the whole email around it. Pick a campaign type, describe your business and goal the same way you’d write a good prompt, and it hands back a subject line, preheader, and body ready to edit in the builder you already use.

[58]

Frequently asked questions about AI email subject lines

What is a catchy email subject line?

A catchy subject line gives the reader a specific reason to open the email right now, through curiosity, a clear benefit, or urgency, rather than a generic description of what’s inside. The best ones read like a message from a person, not an announcement from a brand.

What subject line gets the most opens?

There’s no single subject line that wins across every list; open rates depend on the audience, the sender’s relationship with them, and past engagement. What consistently performs is specificity: naming the actual benefit, offer, or update instead of a vague teaser.

Can AI help write better email subject lines?

Yes, AI can help write better email subject lines, but only if the prompt gives it something to work with: audience, tone, and goal. A one-line prompt like “write a subject line for my sale” produces the same generic output every generator tool already gives you.

How do I prompt AI to write an email subject line?

Give the AI four things: who the email is for, what it’s about, the tone you want, and what you don’t want (no fake urgency, no clickbait, no exclamation marks, whatever applies). The more specific the input, the less generic the output.

Which is an example of a strong subject line?

A strong subject line names a specific, real detail instead of a general claim: “Your order ships Thursday” instead of “Update on your order,” or “3 spots left for Friday’s webinar” instead of “Don’t miss out.” Specificity is what separates a strong line from a forgettable one.

Why do ChatGPT, Claude, and Gemini give different subject lines for the same prompt?

Each model was trained differently and weighs instructions differently, so identical prompts can produce noticeably different tone, length, and structure. Testing the same prompt across models, which SiteGround’s AI Studio makes possible without separate logins, is the fastest way to see which one fits your brand voice.

WordPress security maintenance with AI: A safer routine for small business sites

A digital graphic illustrating AI-powered WordPress security and maintenance against a blue gradient background. On the right, a smiling man in an olive green sweater works on a laptop. In the background, a dark WordPress dashboard features a green badge reading "Website secured" with a shield check icon. In the foreground, a floating translucent UI card displays the user prompt "Review my plugins and users..." next to his avatar, followed by an AI status reading "Reviewing..." alongside a SiteGround logo, with a white sparkle symbol floating nearby.

WordPress security maintenance is the recurring work of keeping your site’s exposure small: updating WordPress itself along with your plugins and themes, checking what’s installed, reviewing who has access to the dashboard, removing what you no longer use, and confirming your backups ran. It’s basic housekeeping, and it’s separate from the tools that guard your site, but it’s just as important.

And for small business owners who manage their own WordPress websites, it’s another nuisance to think about. Our 2026 report on AI in WordPress for small businesses found that 67% of small business owners run their site entirely themselves, with no agency or freelancer behind them, and 28.9% named security and updates among the things they find hardest. What many don’t know is that an AI assistant can now help with WordPress security maintenance by connecting to their site and carrying out recurring tasks through a simple chat.

Key takeaways:

  • Protection and WordPress security maintenance are two different jobs. Protection is your firewall, malware scanner, and host, running around the clock. Maintenance is updates, audits, and access reviews, and it basically depends on you.
  • Most small business owners handle WordPress security maintenance alone. 67% of small business owners manage their site entirely themselves, and 28.9% find security and updates among the hardest parts, as per SiteGround’s report.
  • A specialized AI assistant like SiteGround’s AI Agent for WordPress can help you complete WordPress security maintenance faster and more consistently. It can do things like update plugins and themes, check what’s installed, and review users and roles.
  • You shouldn’t postpone your WordPress security maintenance work for too long. It takes five hours between a flaw being made public and the first attack on it.

What WordPress security maintenance actually covers

Most writing on this subject blurs two things that need to stay apart: the tools that watch your site continuously, and the housekeeping that keeps its exposure minimal. They work at different levels (and can fail in different ways):

LayerWhat it coversWho or what does it
Security protectionFirewall, malware scanning, watching for newly announced weaknesses, login protection, server hardening, cleanup after a break-in, and the backup system itselfDedicated security plugins, your host, or a managed service.
Security maintenanceUpdates to WordPress, plugins, and themes; checking what is installed; reviewing who has access; removing what you do not use; checking settings; and doing it again next monthYou. An AI Agent can help you complete much of this faster and more consistently.
The overlapBackups. The system that takes them is protection, but confirming they ran and knowing how to restore is maintenanceYour host or backup tool provides it. You confirm it, with or without AI help.

Security protection: what your tools and host do

Protection runs whether or not you are paying attention:

  • A firewall sits in front of your site and checks incoming visitors before they reach it, turning away requests that match known attack patterns. You may see it called a WAF, short for web application firewall.
  • A malware scanner reads through your site’s files looking for malicious code, which is code an attacker has added to make your site do something you did not intend, such as redirecting your visitors to another site.
  • Vulnerability monitoring watches for public announcements that something you have installed has a newly discovered weakness. A vulnerability is a flaw in a piece of software that someone can misuse to get in.
  • Login protection blocks repeated password guessing, known as a brute-force attack, where software tries thousands of passwords until one works.
  • Server hardening is your hosting company tightening the settings on the machine your site runs on, so that even a successful attack has less room to move.

None of this is a daily task for you. It runs continuously and automatically, which is why it belongs to dedicated security plugins and your hosting provider.

Security maintenance: what stays your job

While security protection runs automatically, security maintenance is something that gets done, over and over, and it involves judgments about your particular site: which plugins you actually still need, who should be able to log in, what is safe to remove. That is why it stays with you even when you have good security tools running.

Four things can help explain why these tasks matter more than they look:

  • An update is a fix you have to install. When a plugin developer finds a security flaw, they fix it and release a new version. Until you install that version, your site is still running the flawed code, and by then the flaw is public knowledge. The fix existing does nothing for you. Installing it does.
  • Access only ever accumulates. Everyone who has ever needed to log in still can, unless somebody removes them. Most people get given the administrator role, the highest level of access in WordPress, because it is the fastest way to unblock someone. A WordPress user access audit is going through that list and asking who still needs to be on it.
  • An abandoned plugin looks exactly like a maintained one. Nothing in your dashboard turns red when a developer stops working on a plugin. It stops receiving updates and carries on running as before. The only way to find out is to look.
  • A backup you have never restored is unproven. Backups fail without announcing it. A setting changes, a disk fills up, a plugin interrupts the process, and the report still says the job completed. You find out whether the backup is any good at the moment you need it most.

None of these tasks is difficult, which is what makes them easy to put off. There’s no deadline, nothing visibly breaks, and skipping them appears to cost nothing. Except when it does.

Why postponing WordPress security maintenance is riskier than it used to be

Two things changed recently, and neither is about WordPress itself getting worse. The first is volume: Patchstack’s annual security report recorded 11,334 new weaknesses across WordPress plugins, themes, and WordPress itself in 2025, 42% more than the year before and roughly 200 a week. The second matters more: the dangerous share grew faster than the total. Highly exploitable flaws rose 113% in a single year, and more high-severity ones were found in 2025 than in the previous two years combined. The same monthly check now covers more ground, and more of what it covers is worth attacking.

Where those weaknesses live has not changed. 91% were in plugins, and siix were in WordPress itself, all low priority. This basically means WordPress plugin security is a big part of the problem.

About half of high-impact weaknesses are attacked within 24 hours of becoming public, and weighted by how heavily each one was targeted, the median gap between a flaw being announced and the first attack on it was five hours.

No maintenance routine closes a five-hour gap. Nobody checks their site every five hours, and 46% of flaws had no fix available from the developer when they were disclosed, so updating sooner would not have helped in almost half of cases either. That’s the argument for dedicated protection running underneath your routine.

What a routine does fix is the backlog. Every skipped week adds unpatched plugins, unreviewed accounts, and code you have forgotten is still there. Plugins are sometimes pulled from the WordPress directory over security problems that never get fixed, and if one of yours has been pulled, updating will never help.

The recurring WordPress security maintenance checklist

Six tasks make up a WordPress security checklist within any broader WordPress maintenance checklist. None is complicated on its own. The value comes from doing them regularly instead of when something goes wrong.

TaskWhat it preventsHow often
Update WordPress, plugins, and themesPublished weaknesses being used against you when a fix already existsWeekly, and straight away for anything under active attack
Check what is installedAbandoned or withdrawn plugins sitting on your site unnoticedMonthly
Run a WordPress user access auditOld accounts and contractors who still have full administrator accessMonthly
Delete plugins and themes you don’t useInactive code that can still be attacked and still needs patchingQuarterly
Confirm backups ranFinding out during an emergency that the backup you counted on was never being takenWeekly
Check your settingsOptions that were changed for a one-off reason and never changed backQuarterly

Deleting unused WordPress plugins and themes is the task many people skip, because switching a plugin off feels like enough. However, deactivated code still sits on your server, can still be reachable, and still needs patches that nobody is applying because you stopped thinking about it. Switching off is a pause, while deleting is the fix.

Where an AI Agent helps with WordPress security maintenance

A specialized AI assistant like SiteGround’s AI Agent for WordPress is connected directly to your site, so that instead of only answering questions, it can make actual changes in your dashboard when you ask. For instance, if you ask a chatbot like ChatGPT in another browser tab how to update your plugins, it will explain the steps. But if you ask an AI connected agent, it can actually update them for you.

What an AI Agent can help you complete

Every task in the checklist above is something you would otherwise do by clicking through the dashboard, which means it is something the AI Agent for WordPress can do on request:

  • Updating WordPress core, plugins, and themes, individually or in bulk, with approval for higher-risk changes.
  • Managing plugins and themes across their lifecycle: listing what is installed, explaining what each item appears to do, activating, deactivating, updating, or removing unwanted items after approval.
  • Pointing out plugins or themes that look inactive, redundant, outdated, abandoned, or suspicious, so the quarterly clear-out becomes a short list to review rather than a full investigation.
  • Reviewing and managing users and roles, from listing administrator accounts to creating users, updating profiles, changing roles, downgrading access, or removing accounts after approval and content reassignment.
  • Helping configure WordPress-level or compatible plugin-level security settings, such as login protection or hardening options, when those controls are available inside the site.
  • Repeating the same routine across multiple connected sites, instead of opening one dashboard after another.

Here’s an example prompt you can give to the AI Agent for WordPress:

“Run a WordPress security maintenance review: core, plugins, themes, users, roles, comments, and supported security settings; identify updates, risky or inactive items, admin accounts, and cleanup tasks; group everything by risk; then ask for approval before making changes.”

The AI Agent sorts what it finds into high, medium, and low risk, lists the plugins, themes, users, and settings it checked, then proposes a specific plan: deactivate this, delete those two, switch on these three settings, leave the rest alone.

A screenshot of the AI Agent by SiteGround interface displaying a Recommended cleanup plan for a WordPress website. The outlined plan categorizes tasks including deactivating the WordPress Beta Tester plugin, deleting inactive themes (Twenty Twenty-Four and Twenty Twenty-Three) while retaining Twenty Twenty-Five, enabling security settings like two-factor authentication, and noting an optional decision for inactive Akismet. At the bottom sits a text input box with the placeholder "Ask me anything WordPress related and I'll help."

Approve the plan and it works through it, then reports back on what it changed. Anything it was not sure about it leaves alone and asks about separately, so any genuine judgment calls come back to you.

A screenshot of the AI Agent by SiteGround chat interface following up on site cleanup tasks. At the top right, a user prompt reads "Proceed with the recommended changes." In response, the "WordPress Expert" assistant confirms that the approved recommendations have been completed—listing the deactivation of the WordPress Beta Tester plugin, deletion of Twenty Twenty-Four and Twenty Twenty-Three themes, enablement of two-factor authentication and readme file removal, and disabling of default pingbacks. The assistant then asks whether to delete Akismet or keep it installed for future anti-spam configuration. At the bottom, an input box sits with the placeholder "Ask me anything WordPress related and I'll help."

For more prompts you can reuse and adapt, read our guide on how to turn WordPress admin work into simple conversations.

What an AI Agent cannot do for WordPress security

An AI Agent doesn’t run a firewall, and it doesn’t scan your files for malware. It doesn’t watch vulnerability announcements overnight and wake up when something you have installed comes under attack. It doesn’t itself block password-guessing attempts in real time, although it may help configure a security tool that does. It doesn’t harden the server itself, although it may help adjust WordPress-level hardening settings.

The reason is structural rather than a gap somebody will close in the next version. An agent acts when you ask it to, working through the same WordPress controls you would use yourself.

A firewall works somewhere else entirely: it inspects every request arriving at your site, thousands of times a day, before WordPress even starts loading. A malware scanner reads every file on a fixed schedule. Vulnerability monitoring watches disclosure feeds around the clock and does not wait to be asked. Those jobs are continuous, automatic, and positioned underneath or in front of the layer an assistant works in.

How to run AI-assisted WordPress security updates without breaking your site

Applying WordPress security updates quickly matters, especially when an update fixes a security issue. But updating carelessly creates its own problems. An AI Agent can reduce the manual work, organize the process, and add approval steps before high-impact changes, but it cannot make live updates risk-free. A plugin, theme, or WordPress core update can still introduce a bug, conflict with another extension, break checkout, alter layouts, or trigger a compatibility issue.

The safest way to use AI is not to let it push every update blindly. It’s to use it as an operator with guardrails: inventory first, plan the work, update in controlled batches, and keep a rollback path ready.

  • Back up before you update, and know how to restore. A backup you have never tested is a hope rather than a plan. The AI Agent can help coordinate the update routine, but it is not the backup or restore system, so the restore point needs to exist before changes begin.
  • Test complicated or business-critical updates on a staging copy first. WooCommerce, payment plugins, page builders, membership plugins, booking systems, multilingual plugins, caching tools, and major theme updates can break important parts of a site. The AI Agent can help identify which updates belong in the staging-first group before anything touches the live site.
  • Use AI to plan and batch the work, not to remove judgment. Instead of updating everything at once, ask the agent to list available updates, group them by risk, and run smaller batches. If something breaks after one giant update batch, it is much harder to know what caused it.
  • Keep approval over anything with a large blast radius. Deleting plugins, removing themes, changing user roles, modifying security settings, and running bulk operations should pause for confirmation. A good AI-assisted workflow keeps the agent as an operator, not an unchecked autopilot.
  • Check the site after meaningful update batches. Visit key pages, test forms, confirm the dashboard is not showing new errors, and run through checkout if you sell online. The AI Agent can report which updates completed successfully, but it cannot replace checking the real user journeys your site depends on.
  • Know how to undo an update before you need to. For posts and pages, WordPress revisions may help. For plugin, theme, core, or database-impacting changes, your real rollback plan is usually a backup, restore point, staging copy, or dedicated rollback tool.

A recurring WordPress security routine you can actually keep

For a busy small business owner, the difference is not just how long each WordPress security maintenance task takes, but how much of the security maintenance routine can be organized, explained, and safely prepared before you have to make a decision.

CadenceWhat you doRoughly how long manuallyRoughly how long with AI
WeeklyReview WordPress core, plugin, and theme updates. Apply low-risk updates, test complicated or business-critical plugins on staging first, confirm your latest backup exists, and check key pages or flows after updating.30 to 60 minutes5 to 15 minutes, plus any staging or manual checks
MonthlyCheck installed plugins and themes against what you actually use. Review users and roles, especially administrator accounts, and remove or downgrade access that is no longer needed.45 to 90 minutes10 to 20 minutes, depending on how many items need approval
QuarterlyIdentify inactive, redundant, abandoned, or confirmed-unused plugins and themes, then delete what you no longer need. Review WordPress security settings, backup settings, and connected services. Restore a backup somewhere safe to prove it works.2 to 4 hours30 to 60 minutes, plus the time needed to test the backup restore
Continuously, not by youFirewall, malware scanning, vulnerability monitoring, login protection, and automated backups run underneath all of the above.Handled by your tools and hostStill handled by your tools and host


These estimates assume someone who doesn’t already know every plugin, setting, and maintenance screen by heart. The AI Agent shortens the dashboard work by inventorying, explaining, grouping, and carrying out approved changes, but it doesn’t remove the time needed for staging, backup restores, or checking the parts of the site your visitors actually use.

Close the follow-through gap

WordPress security maintenance rarely fails because someone decides it doesn’t matter. It fails because it’s never the most urgent thing on any given day, and because a neglected site can look perfectly fine for months. That is the follow-through gap: the space between knowing what should be done and actually doing it regularly.

AI does not replace the security layers that run all the time. Your firewall, malware scanner, vulnerability monitoring, backups, and host still handle the continuous work. But an AI Agent can make the recurring WordPress-side work much easier to keep: checking updates, reviewing plugins and themes, auditing users, spotting old admin accounts, cleaning up clutter, and preparing changes for approval.

FAQs

Can AI keep a WordPress site secure?

No. AI cannot keep a WordPress site secure on its own. It can help with WordPress security maintenance that reduces risk, such as updates, audits, and access reviews, but firewall, malware scanning, vulnerability monitoring, and login protection still require dedicated security tools and your host.

What is included in WordPress security maintenance?

WordPress security maintenance includes updating WordPress, plugins, and themes, checking which extensions are installed, completing a WordPress user access audit, deleting unused plugins and themes, confirming backups ran, and checking your settings on a recurring schedule.

Does an AI Agent replace a firewall or WordPress security plugin?

No. An AI Agent does not replace a firewall or security plugin. They do different jobs. A firewall and scanner watch your site continuously, while an AI Agent helps you complete the maintenance work that would otherwise be postponed.

Why should unused WordPress plugins and themes be removed?

Unused WordPress plugins and themes should be removed because inactive code can still be attacked and still needs patching. Plugins accounted for 91% of WordPress vulnerabilities recorded in 2025, and switching a plugin off does not remove its code from your server.

How often should WordPress plugins and themes be updated?

WordPress plugins and themes should be updated at least weekly, and WordPress security updates for anything under active attack should be applied as soon as you can safely test them. Patchstack measured a weighted median of five hours between a flaw becoming public and the first attack on it.

Can an AI Agent update WordPress plugins safely?

Yes, with conditions. An AI Agent can update WordPress plugins safely when you back up first, test complicated plugins such as WooCommerce or page builders on a staging copy, and keep approval over high-impact changes rather than letting anything run unattended.

What is a safe recurring WordPress security routine?

A safe recurring WordPress security routine follows a WordPress security checklist: check updates and backups weekly, review users and installed extensions monthly, and check settings and remove unused plugins and themes quarterly, with dedicated security tools running continuously underneath.

Teaser еmail еxamples: How to build anticipation without giving away the reveal

Teaser email on a phone screen with bold "This. Is. Big." text over a colorful sneaker graphic and a "Shop Now" button, next to a woman reacting with excitement while holding her phone.

A teaser email withholds one thing on purpose: the specific offer, product, or date. It names the category (a launch, a sale, an event) and stops there. The teaser email examples below show that same gap at work, and it’s what gets the next email in the sequence opened. Cliffhanger time.

Key takeaways:

  • A teaser email never reveals the product, date, or price. If any of those three appear, it has become the reveal, not the teaser.
  • Question-format subject lines average a 20% open rate compared to 12% for non-questions, based on a Klenty analysis of over 200,000 emails.
  • The reveal email’s open rate, not the teaser’s, is the real measure of whether a sequence worked.
  • Most teaser sequences run two emails before the reveal: an initial teaser and, optionally, a second one that narrows the gap slightly.
  • A teaser email creates a kind of debt with the reader. The reveal is where that debt gets paid off, and a reveal that underdelivers on the buildup costs more trust than a teaser that was never sent.

How the information gap makes a teaser email work

A teaser email works because it creates a small, specific gap between what a reader knows and what they want to know, and people act to close that gap. This is the same mechanic behind a film trailer or a locked door: enough is shown to signal what’s coming, but nothing that lets the audience guess the ending.

The gap has to be specific to work. “Something’s coming” alone is vague and easy to ignore. “Something’s coming for the ones who’ve been asking about faster shipping” names a category without naming the fix, and that specificity is what pulls the click. This is also why email copywriting for a teaser reads differently from copy for a standard promotional send. A promo email answers questions. A teaser email is built to raise exactly one.

Teaser email vs. pitch email vs. coming-soon email

These three get confused because they often arrive back to back in the same sequence. The distinction is what each one reveals and what it asks the reader to do.

Teaser emailPitch emailComing-soon email
GoalBuild curiosity about something unnamedConvert on a named offerAnnounce a fixed date or launch
What’s revealedCategory only: a launch, a sale, an eventFull offer: product, price, call to actionWhat’s coming and when
Typical CTANone, or a soft one like “Check back Thursday”Buy now, sign upGet notified, join the waitlist
Where it sits in the sequenceEarlyMid to late (the reveal itself)Can replace or precede the teaser stage

A coming-soon page often works alongside the coming-soon email, since both name the date without opening sales yet, while a teaser deliberately withholds the date too.

The three stages of a teaser email sequence

Most teaser sequences follow the same three-part shape, whether the brand is announcing a product, a sale, or an event. Understanding the job each stage does makes it easier to know when to add a second teaser and when one is enough.

  1. The setup email

The first email in the sequence. It names the category and nothing else. No product name, no date, no discount. Its only job is to plant a question in the reader’s head.

  1. The build (optional second teaser)

A second teaser, sent a few days after the first, narrows the gap slightly without closing it. This step is optional. Smaller launches and single-product announcements often skip straight from setup to reveal, while bigger campaigns use the build to sustain interest over a longer run-up.

  1. The reveal

The email where the product, date, or offer finally appears. This is where the earlier restraint pays off, or doesn’t. If the reveal underdelivers against what the teaser implied, the gap the sequence built up becomes a debt that goes unpaid, and the reader remembers that the next time a teaser lands in their inbox.

A teaser sequence is one form this can take, sitting alongside other structures covered in what email marketing is and how to get started.

Teaser email examples by use case

What differs between a product launch, a seasonal sale, and an event isn’t the mechanic, it’s what the audience already expects and how much urgency belongs in the mix.

Product launch teaser emails

Product launch teasers work by naming the category (a new release) without showing the product itself. Here’s what that looks like for a small brand adding a new item to its lineup:

Subject line: Get ready: we’re working on something big
Preheader: You’ll want to be the first to know
Body: Something new is on the way. We’re not ready to show you what it is, but we didn’t want you to hear about it anywhere else first.
Closing: Keep an eye on your inbox.

Why it works: a plain layout and a few lines of copy do the job, no product name, no image of the item itself. Readers are told a category (something new is coming from a brand they already know) and given nothing else to go on.

A brand with a more visual product can lean on imagery instead of copy to hold the same restraint:

Subject line: Shhh… coming soon
Preheader: We can’t say much, but we can show you a little
Body: [Short animated preview showing motion and color, no product visible]
Closing: More to come.

Why it works: a short animated preview shows motion and color without revealing the actual product. Both examples name the category (a new release) while keeping the specifics of what, and when, out of the email entirely. The information-gap mechanic in both cases is identical: signal scale or excitement, withhold identity. A coming-soon page is a natural next step once the teaser has done its job of gathering attention.

Seasonal campaign teaser emails

Seasonal teasers carry the extra challenge of naming an occasion without naming a price. Here’s how that plays out for Black Friday:

Subject line: Coming soon: our Black Friday sale
Preheader: Something’s about to get very good
Body: [Short animated graphic repeating “coming soon,” no discount or product shown]
Closing: Stay tuned.

Why it works: the email names the occasion (Black Friday) without naming a single price or product, which is the harder version of restraint for a seasonal sale, since sale emails almost always lead with the number.

The same restraint works just as well outside the Black Friday window, for any seasonal sale:

Subject line: Coming soon: our biggest sale of the season
Preheader: A preview, just for our subscribers
Body: [Preview of the sale catalog, no discounts listed yet]
Closing: Full details coming soon.

Why it works: a preview of the sale catalog without revealing specific discounts lets shoppers get a sense of what’s coming without giving them enough to decide whether to buy before the sale actually opens.

Seasonal teasers carry one extra pressure that product launches don’t: the calendar. A generic teaser works for a product launch whenever it’s ready. A Black Friday teaser has one shot, sent roughly a week ahead of the sale itself, since sending it too early lets the anticipation fade and sending it too late doesn’t leave enough runway to build it. This is also where seasonal campaigns benefit from a companion piece like a Black Friday ecommerce plan that maps the teaser against the rest of the sale calendar.

Event announcement teaser emails

Event teasers work a little differently, since the audience already expects a fixed date rather than a surprise. Here’s how a small business announcing a workshop or webinar could approach it:

Subject line: We’re planning something for the people who’ve been asking about [topic]
Preheader: Mark the date, details coming soon
Body: You’ve been asking about [topic] for a while, so we’re putting something together. No agenda or sign-up yet, just save the date: [date].
Closing: The full details land in your inbox next week.

Why it works: it holds a date without naming the speaker, agenda, or registration link. The reveal email that follows is where the agenda and signup link actually appear.

The gap here is narrower by design, since an event teaser can’t withhold the date the way a product teaser withholds the product, but it can withhold everything else: who’s speaking, what’s covered, and what the reader walks away with. That’s enough to justify a second email before the full event reminder email goes out closer to the date.

How to write a teaser email subject line that doesn’t give everything away

The subject line carries almost the entire weight of a teaser email, since the body rarely has more than a line or two of copy to work with. A few patterns show up across the examples above:

  • Name the category, not the contents. “Something big” or “get ready” signal scale without specifying what.
  • Ask a question instead of making a statement. Questions create the same gap in the subject line that the email body creates as a whole. Question-format subject lines average a 20% open rate against 12% for non-questions, according to a Klenty study of over 200,000 emails. The study looked at cold outreach rather than teaser campaigns specifically, but the same curiosity mechanism applies: a question creates a gap the reader wants closed.
  • Use lowercase, conversational phrasing over ALL CAPS urgency. “SHHH… COMING SOON” works because it’s an exception, not the norm. Overusing all-caps urgency in every teaser trains readers to skim past it. Urgency language does lift open rates by roughly 22% on average, according to Zippia’s subject-line research, but that effect is strongest on the reveal email, not the teaser, since urgency and curiosity pull a reader in different directions. 

Preview text (the line that shows next to the subject line in most inboxes) should extend the gap, not close it. A one-line continuation like “you’ll want to see this before Friday” adds a soft deadline without naming anything. 

Teaser email subject line templates you can copy

These fill-in-the-blank templates apply the patterns above:

  • Product launch: “Get ready: we’re working on [category]”
  • Product launch, question format: “Guess what’s coming to [brand or shop name]?”
  • Seasonal sale: “Coming soon: our [occasion] sale”
  • Seasonal sale, second teaser: “Not [current category], but you’ll still want it”
  • Event announcement: “We’re planning something for the people who’ve been asking about [topic]”

Each template names a category (a launch, a sale, an event, a topic) and stops there, which is the one rule every subject line above shares.

How many teaser emails to send (and how to space them)

How many teaser emails a sequence needs, and how far apart to send them, depends on the size of the campaign:

Campaign typeTeasers before the revealSpacing
Single-product launch1 (just the setup email)Reveal follows a few days to a week later
Bigger campaign (multi-category sale, multi-day event)2 (setup, then a second teaser)Second teaser 2–3 days after the first; reveal a few days to a week after that
Black Friday1 teaser, plus the sale’s own 3-email cadenceTeaser about a week before the sale; main promotion on sale day; last-chance reminder before it closes

SiteGround Email Marketing lets you schedule each campaign in the sequence for its specific send date in advance, so the setup email, the optional second teaser, and the reveal all go out on the days you plan for without needing to trigger each one manually on the day.

Diagram of an automated email flow, showing a trigger event followed by a sequence of timed emails sent automatically to new subscribers.

Mapping the right cadence in advance also matters for seasonal marketing campaigns, where the send dates are fixed by the calendar rather than flexible.

Common teaser email mistakes that break the payoff

Most teaser emails fail in one of three ways, all variations on the same problem: the gap and the payoff stop matching.

  • Revealing too much, too soon. If a reader can screenshot the teaser and correctly guess the product, the date, or the price, the email has already done the reveal’s job for free, and the actual reveal email has nothing left to deliver.
  • Sending too many teasers. A third or fourth teaser before the reveal usually reads as stalling rather than building anticipation, and open rates on later teasers in an overlong sequence tend to drop as readers lose patience.
  • The reveal underdelivers on the buildup. This is the costliest mistake, since it isn’t just one weak email, it changes how the reader treats every future teaser from the same sender. A teaser creates a kind of debt with the reader: it promises something worth the wait, and the reveal is where that debt gets paid. A modest reveal after a big buildup reads as a letdown even if the offer itself is reasonable on its own terms.

These same principles show up across other campaign types too, not just teasers; see 15 successful email marketing campaign examples for how buildup and payoff play out in welcome sequences, cross-sells, and other campaign formats.

A full teaser sequence, step by step

Here’s how a small ecommerce shop expanding into a new product category, say, a candle brand adding a home fragrance line, could map the same information-gap mechanic into a complete sequence, from first email to reveal:

  1. Send the first teaser 5 to 7 days out. Name the category only, a new product line, nothing about what it is or does. This is the “get ready” stage.
  2. Send a second teaser 2 to 3 days later (optional). Narrow the gap slightly, perhaps a hint at the category the new product belongs in (for the shop, something like “not candles, but you’ll still want to light it”), still nothing specific enough for a reader to guess it.
  3. Send the reveal 2 to 3 days after the last teaser. This is where the product, price, and purchase link appear for the first time. Waiting much longer than this risks losing the momentum the teasers built.
  4. Compare the reveal’s open rate against the teaser’s. If the teaser opened well but the reveal didn’t lift above a normal send to the same list, the gap was either too vague to build real curiosity or held open for too long.
SiteGround graphic showing a four-step teaser email timeline: setup teaser on day 1, optional second teaser on days 5-7, reveal on days 8-10, and a comparison of open rates between reveal and teaser emails.

The same four-step shape applies just as well to a seasonal sale or an event announcement, since the only thing that changes between categories is what gets revealed at the end, not the structure that gets you there. A holiday email marketing guide can help map this same sequence onto a specific date on the calendar, like Black Friday or a year-end sale.

Build your teaser email sequence with SiteGround Email Marketing

Every example above depends on timing: the teaser has to go out early enough to build curiosity and the reveal has to land while that curiosity is still fresh. Getting that right by hand, across a launch, a sale, or an event, means remembering exact send dates and manually triggering each email in the right order.

SiteGround Email Marketing lets you build the full sequence, from the first teaser through the reveal, and schedule every email in advance, so the cadence you plan is the cadence that actually goes out. The Generate with AI feature can draft each stage for you: describe the setup teaser in your own words to get a subject line, preheader, and body with the specifics deliberately left out, then use the Announcement or Promotional preset for the reveal once you’re ready to name the actual offer.

[58]

Frequently asked questions about teaser email campaigns

What is the purpose of a teaser?

The purpose of a teaser is to create curiosity by revealing just enough to signal that something is coming without naming what it is. A teaser’s job is to earn an open on the email that follows it, not to sell anything on its own.

What is a teaser email vs pitch email?

A teaser email withholds the offer to build curiosity, while a pitch email states the offer directly and asks for a purchase or signup. See the comparison table above for how the two differ in goal, reveal timing, and typical call to action.

What’s the difference between a teaser email and a coming-soon email?

A teaser email withholds the date along with the product or offer, while a coming-soon email typically states the date but not the specifics of what’s launching. The comparison table above breaks down where each fits in a sequence.

When should you send a teaser email before a launch?

A teaser email typically goes out five to seven days before the reveal for a single product launch, with longer campaigns sometimes adding a second teaser two to three days after the first. Waiting much longer than a week risks losing the momentum the teaser built.

How short should a teaser email be?

A teaser email should be as short as the subject line and one or two lines of body copy, since the goal is to raise a question, not answer one. Adding more copy than that risks revealing details the sequence is designed to withhold.

What are some teaser marketing campaign examples?

A product launch teaser might read “Get ready: we’re working on something big,” naming the category without the product. A seasonal teaser might say “Coming soon: our Black Friday sale,” naming the occasion without a price. An event teaser might say “We’re planning something for the people who’ve been asking about [topic],” holding back the agenda and speaker until a follow-up email. Each one names a category and stops there.

How much does it cost to build a website or web app for your business in 2026?

A digital graphic illustrating website building and development costs against a dark green grid background. In the center, a website editor preview showcases a culinary site featuring a steaming bowl of risotto garnished with herbs, where a selected white button reading "GET STARTED" sits beneath a floating text-formatting toolbar. Floating on the right are three translucent price badges with indicator arrows displaying "$6,173" with a red upward arrow, "$2,646" with a green downward arrow, and "$1,376" with a green downward arrow, anchored by a white price tag icon badge in the bottom right corner.

Search for what a website costs, and you’ll get answers ranging from nothing to $250,000, which can hardly help you. The number is that wide because the question should really be what your project costs based on the path you take to build it.

The cost to build a website in 2026 is about $200 a year on a DIY builder, $1,500 to $8,000 with a freelancer, and $6,000 to $35,000 or more at an agency. Web apps and MVPs start higher, from a few hundred dollars on no-code tools to $18,000 and up for custom development.

Key takeaways:

  • Most small businesses spend under $10,000. 61% of small business buyers spent less than $10,000 on their most recent website and 84% spent under $20,000. Professional small business website costs cluster between $3,000 and $15,000.
  • The cost to build a website or web app is set by the path, not just the project. The same brochure site can cost $200 a year on a builder or $12,000 at an agency. What changes is who does the work.
  • A web app costs more than a website because it does something. Custom web app development starts around $18,000 for an MVP, against $3,000 to $15,000 for a typical small business site.
  • AI and no-code builders are the cheapest entry. AI app builders start free, and no-code platforms now run roughly $36 to $69 per month at entry level.
  • Ongoing costs are the line most quotes leave out. Budget roughly $600 to $6,000 a year for a small business site, and 15% to 25% of the build cost annually for a web app.

What determines website and web app development cost

Many cost guides start with features: how many pages, whether you need e-commerce, how complex the design is. Those are important details, but they’re actually second-order. The variable that moves the number most is who builds it and on what.

A five-page brochure site is a five-page brochure site whether you assemble it on a template, hand it to a freelancer, or commission an agency. The work is broadly the same. But that site is about $200 a year built yourself, around $4,000 from a freelancer, and $12,000 or more from an agency. You are not buying more website at the top of that range. You are buying more of three things.

  • Time is the one people underestimate. What you don’t pay in money you pay in hours: learning the tool, writing the copy, resizing images, fixing what breaks. A DIY site isn’t free, it’s unpaid. If your hours are worth anything to the business, price them before calling the builder path cheap.
  • Judgment is knowing which decisions matter and where projects like yours usually go wrong. Someone who has built dozens of these will skip the arguments you would have had. On the DIY path, that judgment is yours to supply, which is fine when the stakes are low and expensive when they aren’t.
  • Accountability is the least visible line on any quote. It answers who fixes it when the contact form stops sending on a Tuesday. On a builder, that’s you. With a freelancer, it depends what you agreed and whether they’re free that week. With an agency on a retainer, it’s contractual.

That’s also why quotes from different paths aren’t directly comparable. A $3,000 freelancer and a $12,000 agency are often quoting different work, because content, photography, revisions, and post-launch support may be inside one number and billed separately in the other. Write down what you need first, then check each quote against the same list.

So the useful question isn’t what a website costs. It’s which path fits what your site or app has to do, and what that path costs in 2026.

How much does it cost to build a website in 2026?

It costs between roughly $16 per month and $35,000 or more to build a website in 2026, depending on the path. Most professional small business website costs land between $3,000 and $15,000. In the Clutch 2026 survey, 61% of small businesses spent under $10,000 on their most recent website. GoodFirms’ 2026 software development cost survey found 51.6% of web development agencies quoting $3,000 to $15,000 for small-scale sites.

Build pathTypical 2026 costBest forWatch for
DIY website builder (Wix, Squarespace)$16 to $50 per monthSimple brochure sites, tight budgets, fast launchLimited customization, and you build and maintain it yourself
AI website builderFree to about $50 per monthNon-technical owners who want a fast first versionOutput quality varies, and publishing or a custom domain usually needs a paid plan
Self-hosted WordPress (DIY)$100 to $500 per yearOwners comfortable with a small learning curveMore technical than a hosted builder
Freelancer$1,500 to $8,000 one-timeCustom branding without agency overheadTurnaround times and limited post-launch support
Boutique or full agency$6,000 to $35,000 and upStrategy, custom design, and ongoing supportHighest upfront cost, and scope creep adds to it

The builder prices are entry plans billed annually: Wix starts at $17 per month and Squarespace at $16 to $19, but the plan most small businesses actually need sits closer to $29 to $39 once you add selling or remove transaction fees. And the agency range is wide because it covers everything from a boutique studio’s $6,000 template build to a $35,000 custom project with strategy and content included.

AI website builders sit alongside the DIY tier rather than replacing it, and the sticker price is rarely the whole bill. Our guide to AI website builder pricing covers plans, renewals, limits, and the fees that appear when you try to publish.

How much does it cost to build a web app or MVP in 2026?

Web app development cost starts where website cost tops out. An MVP built with no-code tools can cost a few hundred dollars a year, while custom development for the same idea starts around $18,000. The cost to build a web app depends on the same build path question, with an extra tier at the top that websites do not have.

Build pathTypical 2026 costBest forWatch for
AI app builderFree to about $300 per year to startValidating an idea fast, cheapest entryA complexity ceiling you may eventually outgrow
No-code platform (Bubble, Adalo, FlutterFlow)About $430 to $2,400 per yearFounders needing more logic than a builder allowsYou rent it, expect 100 to 300 hours to learn it, and per-seat costs climb
Hybrid no-code plus custom work$1,000 to $5,000MVPs expected to scale to real usersNeeds some technical help at the edges
Agency-built MVP$5,000 to $25,000 with a productized or offshore teamFunded teams wanting a polished first versionUS agencies commonly quote $25,000 and up for the same scope
Custom development (agency or team)$18,000 to $60,000 for an MVP; $45,000 to $150,000+ for a full appGenuinely complex or large-scale softwareMost expensive by far, and typically three to six months

No-code platforms are the tier most often misquoted in older guides. Entry plans currently run roughly $36 to $69 a month, with Adalo at the lower end and Bubble at the upper, and FlutterFlow’s Basic plan at $39. FlutterFlow raised that from $30 during 2026, so check current pricing rather than trusting a figure from last year’s roundup.

Note also how wide the agency MVP band is. Productized offers and offshore teams genuinely deliver at $5,000 to $25,000, while US agency quotes for a lean MVP commonly start at $25,000 and run past $100,000. If you are scoping an MVP, our guide to building an MVP with vibe coding covers what to include and what to cut.

“MVP” has no agreed meaning, which is why the quotes vary so much. One agency’s MVP is a landing page with a signup form. Another’s is a working product with accounts, payments, and an admin panel. When quotes for the same idea come back at $8,000 and $60,000, they are usually pricing different products, not the same product at different rates. Write the feature list yourself first, in plain language, and send the identical list to everyone. The spread shrinks immediately.

Why a web app costs more than a website

A web app costs more than a website because it does something, while a website mostly shows something. That single distinction explains most of the gap between the two tables.

A website presents information: pages, images, a contact form, maybe a shop. The work is largely design and content, and once built it mostly sits there. A web app has users who log in, data belonging to each of them, rules about who can see and change what, and logic that has to be right every time. All of that needs designing, building, and testing, and testing is where the hours go. Custom web app costs also carry a longer tail than custom website costs, because logic touching real customer data has to keep working as payment providers and integrations change around it.

What increases the cost

Within any path, five things move you from the bottom of the range to the top.

  • Design originality. A template build and a custom design are different products. This is the single biggest gap between a $3,500 site and a $14,000 one.
  • Page count and feature complexity. Bookings, e-commerce, and third-party integrations push toward the top of every range, because each one is a system that has to be configured and tested.
  • Who writes the content. Writing it yourself is free and slow. Done-for-you copy and photography are often quoted separately, and they are a common reason a quote comes in higher than expected.
  • User roles, data, and logic. This is the dividing line between website pricing and web app pricing. The moment people log in and the site remembers things about them, you have crossed into the second table.
  • Ongoing costs. Hosting, security, backups, maintenance, and tool subscriptions are rarely in the headline quote, and they run for as long as the site does.

On the AI and DIY paths there is a sixth cost that does not appear on any invoice, which is your own time. AI builders produce a first version quickly, then you iterate, and the number of rounds is where the hours accumulate. Describing what you want precisely cuts that down, and our guide to writing better prompts for building is the practical version of that skill.

Which path is right for your budget

One question routes you faster than any feature checklist: how much of your revenue depends on this site or app? Not how much you like it, or how much you want it to impress people. How much money moves through it or because of it.

If the site is a low-cost small business site or an early test

Stay in the DIY and AI builder tier, free to about $50 per month. This covers a local service business that needs to be findable and credible, a portfolio, a landing page for something you are still validating, or a first version of an app idea. Paying $8,000 for a site that supports a business but does not drive it is a poor trade.

This is also where an all-in-one AI builder earns its keep on cost. For instance, SiteGround’s Coderick AI sits on this line: you describe what you want, and building, hosting, SSL, version control, and publishing come in the same plan rather than as five separate subscriptions you assemble and pay for individually.

If the site is one of several lead sources

Look at freelancers and small agencies, roughly $1,500 to $10,000. This is the tier where custom design starts paying for itself, because the site is doing real work in a real sales process and looking like everyone else’s template costs you something measurable. A freelancer at $1,500 to $8,000 gets you custom branding without agency overhead. A boutique agency from around $6,000 adds strategy and a process, which matters more as the site gets more complicated.

If the site or app is revenue-critical

Budget for an agency or custom website or web app development: $6,000 to $35,000 and up for websites, $18,000 and up for web apps. If the site is the storefront, if downtime costs money by the hour, or if the app is the product itself, the cost of getting it wrong is larger than the cost of building it properly. This is also the tier where the ongoing budget stops being optional, because software that carries revenue needs someone responsible for it.

Pro tip: Count the weeks, not just the money. A site built with an AI builder can be live in a few days. An agency project commonly runs eight to sixteen weeks, and a custom web app three to six months. If the site or app brings in customers, every month of delay is revenue you didn’t earn, and that rarely appears in any comparison. It can flip the maths entirely: a cheaper build that starts working in March may beat a better one that starts in July.

Ongoing website and web app costs to budget for

Ongoing website costs, including website maintenance costs, are the line most quotes leave out, and they are why a build that looked affordable becomes a problem in year two. Website maintenance cost covers:

  • Hosting. The largest recurring line for most sites, and the one that scales as traffic grows.
  • Domain renewal. Small and annual, and easy to forget until the site goes down.
  • SSL certificate. Usually included with hosting now, but worth confirming rather than assuming.
  • Software and plugin updates. Free if you do them yourself, billed if somebody else does.
  • Security and backups. Sometimes bundled with hosting, sometimes a separate subscription.
  • Content edits. The line that grows fastest if you cannot make changes yourself.

For a small business site, expect roughly $600 to $6,000 a year in total, with full-service maintenance plans commonly landing at $95 to $195 per month. If the site is simple and you handle updates yourself, you can run it for well under $100 a year in domain and hosting alone, but you are paying in hours instead.

Ongoing web app costs work differently and are higher. Web app maintenance costs are usually estimated as a percentage of the build rather than a flat fee, at roughly 15% to 25% of the original cost every year, because the code has to keep working as the services around it change. On a $40,000 MVP that is $6,000 to $10,000 a year, indefinitely. Add hosting, monitoring, and any AI or third-party services the app depends on. If you want to see how those separate subscriptions add up in practice, our breakdown of AI coding and hosting costs prices a full stack line by line.

Match the path to the job, not to the lowest price

The cost to build a website or web app in 2026 spans four orders of magnitude, and every number in that range is correct for somebody. What makes it useful is the question underneath it, which is what this thing has to do for your business. A site that has to be findable and credible does not need the budget of a site that has to sell. An idea you are testing does not need the budget of a product people will pay for.

Pick the cheapest path that can genuinely do the job, then add the ongoing costs before you compare quotes. The expensive mistake is rarely overspending at the start. It’s choosing a path that cannot do what you needed, and paying to build the thing twice.

If you are not sure which tier you are in, the cheapest way to find out is to build the simple version and see where it runs out. A month with a real site teaches you more about what you need than another week of comparing quotes, and it makes the next quote a better one.

[96]

FAQs

How much does it cost to build a website in 2026?

It costs anywhere from about $16 per month on a DIY builder to $35,000 or more at a full agency to build a website in 2026. Most professional small business sites land between $3,000 and $15,000, and 61% of small businesses spent under $10,000 on their last site.

Why does a web app cost more than a website?

Web app development cost is usually higher than website development cost because a web app does something rather than just shows something. Websites mostly present information, while web apps handle users, data, logic, and roles, which means more design, engineering, and testing. Custom web app MVPs typically start around $18,000.

What is the cheapest way to build a business website?

The cheapest way to build a business website is a DIY or AI builder, starting free to around $50 per month. You trade customization and hands-off support for a low price, which suits simple brochure sites and early-stage testing.

Should I use an AI builder, freelancer, agency, or developer?

You should choose based on how much of your revenue depends on the site, how much customization you need, and your website development cost ceiling. An AI or DIY builder fits simple needs and tight budgets, a freelancer suits custom branding at $1,500 to $8,000, and an agency fits complex, revenue-critical projects starting around $6,000.

How much does it cost to build an MVP before hiring developers?

MVP development cost can range from nothing to a few thousand dollars before hiring developers, depending on the build path. AI app builder costs start free to about $300 per year, no-code app builder costs run roughly $430 to $2,400 per year, and hybrid builds land around $1,000 to $5,000.

How much does custom website or web app development cost?

Custom website cost is usually lower than custom web app cost, because a web app requires more logic, data handling, user interaction, and testing. Custom websites run from around $6,000 to $35,000 and up, while custom web apps start near $18,000 for an MVP and reach $150,000 or more for a full product.

What are the ongoing costs after building a website or web app?

Ongoing website costs and ongoing web app costs include hosting, domain renewal, security, backups, updates, subscriptions, and support. Budget roughly $600 to $6,000 a year for a small business site, and 15% to 25% of the build cost annually for a web app.

Can Coderick AI reduce the cost of building a website or web app?

Yes. Coderick AI can reduce the cost of building a website or web app by combining AI building, hosting, SSL, version control, and publishing in one plan, which removes several separate setup and subscription costs that a pieced-together stack would carry.

Stripe for small business: What to know before going live, from setup to testing

Abstract of Stripe for small business

Going live with Stripe for small business means real money starts moving the moment you flip one switch, and there’s no finance team or QA department standing between you and that switch. One short list catches the problems that matter: test mode, checkout, confirmation, refunds, disputes, and tax, checked once before launch.

Key takeaways:

  • Stripe for small business comes down to one go-live checklist: test mode, checkout, confirmation, refunds, disputes, and tax.
  • Your first Stripe payout typically takes 7 to 14 days after your first live payment, so plan cash flow around the delay.
  • Test and live mode run on separate keys, so nothing touches real money until you deliberately switch.
  • Refunds don’t return Stripe’s processing fee, and disputes add their own fee, around $15 in the US, on top.
  • Stripe Tax calculates the right rate automatically at checkout and can flag when you cross a threshold, but it doesn’t handle registration or filing for you.
  • Coderick AI handles checkout and confirmation for you, but live keys, payouts, receipts, and tax are still yours to set up.

Stripe for small business: what “going live” actually means

For a small business, going live with Stripe means one person wearing hats across finance, engineering, and QA. There’s no separate team to catch a misconfigured price or a forgotten test key before a customer sees it. That’s the real risk behind Stripe for small business: the checks a bigger company spreads across three departments land on you alone, with nobody double-checking your work before the switch flips.

The same short list of things to confirm applies whether you’re selling through a payment link sent in a DM, a checkout embedded on a page you built, or a full ecommerce website, even though where you go to check some of them differs. This article walks through that list once, in the order it matters, and closes with a checklist you can work through section by section. Let’s get started.

How Stripe payment processing works

The path a payment takes from checkout to your bank account

When your customer pays, Stripe allows you to accept payments online by sitting between three parties: the customer’s bank, the card network, and your bank. Stripe authorizes the charge in real time, holds the funds in your balance, and later batches them into a payout.

Diagram of the path a payment takes to your bank account

When the money actually lands: payout timing

Important to note though: new Stripe accounts don’t get paid out immediately. According to Stripe’s payout documentation, the first payout typically arrives 7 to 14 days after your first live payment, and it can be even longer depending on industry and country. After that, most US accounts settle onto a rolling two-day schedule. But that delay matters more without a cash reserve to smooth it over, so be sure to plan around it rather than the payment date.

Stripe Checkout: for a page you control

Stripe Checkout is a hosted payment page you generate through the Stripe API: you, or an AI builder like Coderick AI generating it on your behalf, create a Checkout Session with the product, price, and currency baked in, and Stripe renders a payment page that matches your branding. 

Coderick AI, in this case, is SiteGround’s AI website and app builder: you describe what you’re selling, and it builds the site around that, including this Stripe connection. Either way, it’s genuinely Stripe’s own checkout, so Stripe’s own dashboard settings, like the receipt toggle, are the ones that apply.

Worth knowing: a full ecommerce website builder like SiteGround Ecommerce works differently. It typically runs its own checkout, with Stripe plugged in as the processor underneath, so things like order confirmations and receipts usually come from the platform’s own system instead.

Enabling Stripe via the SiteGround Ecommerce platform

Stripe Payment Links skip the website entirely. That is, you can set up a product once in the Stripe dashboard, get a reusable URL, and paste it in all the places you’re already talking to customers. Think: a DM, an invoice, an email signature, or a QR code at an event. 

There’s no code and no page to build for this, which makes Payment Links the faster option for selling one thing to people you’re already in conversation with. 

Stripe test mode vs. Stripe live mode: what actually changes when you flip the switch

Abstract image of topping on Stripe integration on an ecommerce site

How does Stripe test mode work?

Test mode is a full copy of your Stripe setup that never touches real money. Here’s what that gives you:

  • Separate test keys, clearly labeled “Test” in your dashboard, so you can’t accidentally mix them up with your live ones.
  • Test card numbers, such as 4242 4242 4242 4242, that simulate successful payments, declines, and refunds.
  • A safe place to run a full purchase, a canceled checkout, and a failed payment before you launch.

Nothing you do here shows up in your live dashboard, and nothing costs you money.

What changes the moment you switch to Stripe live mode

Switching to live mode swaps your test keys for live ones, and every charge now processes against a real card and moves real money into your balance. It also requires details test mode never asked for:

  • Your legal business name and address.
  • Your tax information.
  • A bank account for payouts.

This toggle is worth checking twice, wherever it lives in your setup, before you tell anyone the store is open.

The most common go-live mistake: forgetting to swap the key

The most common go-live mistake is leaving test keys in place after flipping the switch elsewhere. Test mode and live mode both produce a checkout that looks successful, so a customer can complete a purchase and never know no real money moved. Nobody catches it because there’s no second person checking, which is exactly the risk of building without a developer: fewer people to notice the mismatch before it costs you a launch day. Reconciling your bank account is the only way you’d find out, and by then, you’ve likely already told people you’re open.

What should happen after a customer pays through Stripe

Confirmation: what the customer should see immediately

Right after payment, the customer needs a clear thank-you page or next step, not a blank redirect to your homepage. Two things make the difference:

  • Say what happened next. “Your order is confirmed, we’ll email details shortly” is a lot more confidence-inspiring than a generic “thanks.”
  • Match the reassurance to the trust gap. A stranger clicking a Payment Link needs more of it than someone checking out on an established brand’s site.

Receipts: what the customer should receive by email

Stripe can email a receipt automatically, but it isn’t switched on by default in every setup. A few things worth knowing before launch:

  • Turn it on under Customer emails in your Stripe dashboard settings, by toggling “Successful payments” on.
  • Receipts only go out for completed payments. A failed charge never generates one.
  • With no support team to catch the gap, a missing receipt becomes a support email, so confirm the toggle before a customer asks where theirs went.

What you should see on your end

A successful payment should show up in your Stripe dashboard with the customer’s details, the amount, and the payment method attached, filed under your live data, not test data. Glance at that after your first few sales: if a payment you just took shows up in test mode instead of live mode, that’s the swapped-key mistake showing up here first, before you’d otherwise catch it reconciling your bank account.

How Stripe refunds and disputes work

How refunds work and what happens to your fees

A refund returns the customer’s money in full — but important caveat: Stripe doesn’t return its processing fee from the original charge. So on a $100 sale processed at Stripe’s standard US rate of 2.9% + $0.30, you’d keep $96.80 after the sale and still lose that $3.20 if you refund it. For a large retailer, that’s a rounding error. Alone, a handful of big refunds in a launch week can start to put a dent in the numbers you expected.

How disputes are different from refunds

A dispute isn’t a refund. It’s the customer going to their card issuer instead of you, and the issuer reversing the payment immediately, before you’ve had a chance to respond. Stripe adds a separate dispute fee, around $15 in the US, on top of the disputed amount the moment a dispute is filed, and the back-and-forth can take two to three months to resolve.

Where disputes show up, and who should respond

Disputes show up in your Stripe dashboard under Disputes, with an email notification the moment one is filed. Responding means submitting evidence: proof of delivery, a signed agreement, or a support thread showing the customer got what they paid for. Someone has to gather and submit that before Stripe’s deadline, and if you’re running a service business online solo, that someone is you.

Stripe Tax as a pre-launch setting, not an afterthought

Sales tax depends on where you have “nexus,” which is the legal term for a strong enough connection to a state that it can require you to collect its sales tax. If your business is based in a state and what you sell is taxable there, that’s enough on its own, so you likely owe tax on sales into that state from day one, regardless of revenue. 

Selling into other states is a different story: there, the connection is triggered by a sales threshold instead, commonly $100,000 over 12 months, though it varies by state, and few new businesses clear it right away.

Turning on Stripe Tax handles the mechanical part of this:

  • It calculates the right rate automatically at checkout, for any state or country where you’ve told it you’re registered.
  • It monitors your Stripe-processed sales by state and can notify you once you’ve crossed a threshold in a given location, though it’s still worth checking in yourself rather than relying on it as your only signal.
  • It applies once you’re registered; it doesn’t decide where you need to register, or handle the registration and filing itself.

Registration, filing, and the full state-by-state picture are a bigger topic than this checklist covers. SiteGround’s ecommerce sales tax guide walks through all of it. For go-live purposes, the short version holds: confirm what your home state requires before your first sale, then turn on Stripe Tax so it calculates the right amount automatically at checkout, and keep an eye on other states as your sales grow.

A Stripe go-live checklist for small business

This is the payments half of a broader website launch checklist. Work through both before you tell anyone you’re open. Each row below maps to a section above, so if anything doesn’t check out yet, you’ll find the details a few paragraphs up.

Go-live itemWhat to check
CheckoutMake sure the customer sees the right product, price, currency, and payment method.
Test modeRun test purchases, cancellations, failed payments, and refunds.
Live modeConfirm the correct live key is saved in the correct place.
ConfirmationShow a clear thank-you page or next step after payment.
ReceiptsConfirm the customer receives the right email or receipt.
RefundsKnow how refunds are issued and what happens to fees.
DisputesKnow where disputes appear and who responds.
TaxConfirm what your home state requires, and keep an eye on other states as your sales grow.
SupportDecide who answers payment questions after customers pay. If it’s just you, plan for that.

Coderick AI Stripe setup: why to use it and what to check before launch

No developer? Don’t want to spend a week picking a platform and wrestling with setup? Coderick AI just builds the site for you from a description of what you’re selling, checkout and confirmation included. It won’t set up your live keys, payout account, receipt emails, or tax registration for you, though, so check those before you launch:

  • The Coderick AI Stripe connection shows live mode, not test.
  • Your payout bank account is added and verified.
  • Your confirmation page says what happens next.
  • Receipt emails are switched on in your Stripe settings.
Example of connecting Stripe payments to a client's AI built website

Skip one, and a launch day can go by without a single real payment landing in your account, and you won’t know until you reconcile your bank. Gulp.

Flip the switch with confidence

Going live with Stripe for small business isn’t complicated once you’ve checked it off in the right order: pick how customers pay, run it in test mode, swap in live keys, sort confirmation and receipts before you tell anyone you’re open, and have a plan for refunds, disputes, and tax before the first one shows up. None of that requires a finance team. It requires going through the list once.

If you’re building the site itself rather than just connecting payments to one, start your Coderick AI payment project and get checkout, confirmation, and hosting handled together from the first prompt.

[96]

Frequently asked questions

What should a small business know before going live with Stripe?

Before going live with Stripe, confirm test mode, checkout, live-mode keys, confirmation, receipts, refunds, disputes, and tax, in that order, as one connected checklist rather than separate tasks.

What should a Stripe go-live checklist include?

A Stripe go-live checklist should cover checkout accuracy, a completed test run, the live-mode key swap, a confirmation page, working receipts, a refund process, a dispute plan, and a tax decision. The table above works as a starting point.

What is the difference between Stripe test mode and live mode?

The difference comes down to the keys: test mode uses a separate set of test keys and never touches real money, while Stripe live mode uses your live keys and processes real charges.

Do I need to test Stripe before accepting real payments?

Yes. Test mode is the only way to confirm your checkout, confirmation page, and refund flow work correctly without risking a customer’s card or your own money.

What should happen after a customer pays through Stripe?

They should see an immediate confirmation, receive a receipt by email if that setting is on, and the payment should appear in your Stripe dashboard with the amount and payment method attached.

How do Stripe refunds and disputes work?

Stripe refunds return the customer’s money but not the processing fee Stripe already charged you. Disputes work differently: the card issuer reverses the payment directly, and Stripe adds its own dispute fee on top.

Do small businesses need to think about tax before taking Stripe payments?

Yes. Sales tax in your home state can apply from your first sale, while a threshold-based obligation in other states usually doesn’t kick in until much higher revenue. Stripe Tax calculates the right rate once you’re registered and can flag when you cross a threshold elsewhere.

Is Stripe for small business a good fit before going live?

Stripe for small business is a strong fit before going live, provided you complete the pre-launch checks. Skipping the checklist, not the platform itself, is where problems tend to start.

Can Coderick AI help with Stripe setup for a small business?

Yes. Coderick AI Stripe setup wires up checkout and confirmation automatically inside your project. You still confirm your live keys, payout account, receipt emails, and tax settings yourself before launch.

What should I understand before connecting Stripe to an AI-built website or app?

The AI builder typically handles checkout and confirmation, while you’re still responsible for switching to live mode, verifying your payout account, turning on receipt emails, and deciding whether tax collection applies to your sales.