DEV Community: Joe Seabrook

I Built a GDPR Compliance Scanner Using the Claude API - Here's How It Works

Joe Seabrook — Mon, 08 Jun 2026 09:37:57 +0000

I Built a GDPR Compliance Scanner Using the Claude API - Here's How It Works

A few months ago I noticed something that kept bugging me. I was building and handing off websites for clients and every single time, GDPR compliance was either an afterthought or a panic right before launch. Privacy policies copied from templates, cookie banners slapped on at the last minute, no one really sure if the contact form was actually compliant.

The bigger problem: there was no quick, affordable way to check. Enterprise compliance tools cost hundreds per month. Legal consultants cost more. Most small businesses just crossed their fingers.

So I built ClearlyCompliant - an automated GDPR compliance scanner that analyses a website and delivers a detailed PDF report for a one-off fee. No subscription, no jargon, just a clear picture of where a site stands.

Here's how it actually works under the hood.

The Stack

Django (Python) - backend and web app
BeautifulSoup + requests - crawling and HTML parsing
Python threading - async scanning without the overhead of Celery/Redis
Anthropic Claude API (Haiku) - AI-powered policy analysis
ReportLab - PDF report generation
Stripe - payments
IONOS SMTP - email delivery
Gunicorn + Nginx on an IONOS VPS

The Scanning Pipeline

When a user submits a domain and completes payment, the scan kicks off immediately. Rather than making them wait on a loading screen, the scan runs asynchronously in a background thread and the report gets emailed when it's done.

I deliberately avoided Celery and Redis here. For the scale I needed, Python's built-in threading module was more than sufficient and kept the infrastructure simple. One less thing to maintain, one less thing to break.

import threading

def run_scan_async(domain, order_id, customer_email):
    thread = threading.Thread(
        target=run_full_scan,
        args=(domain, order_id, customer_email)
    )
    thread.daemon = True
    thread.start()

The scan itself runs 23 individual GDPR checks across several categories.

The 23 Checks

The checks are grouped into logical categories:

Cookie & Consent

Does a cookie banner exist?
Is consent required before non-essential cookies fire?
Are there pre-ticked opt-in boxes?
Is declining as easy as accepting?

Privacy Policy

Does a privacy policy exist and is it linked correctly?
Does it mention data retention periods?
Does it list third-party processors?
Does it cover user rights (access, erasure, portability)?
Does it mention the ICO / supervisory authority?

Forms & Data Collection

Do forms collect more data than necessary?
Is there a privacy policy link at the point of data collection?
Are forms served over HTTPS?

Security

Is HTTPS enforced sitewide?
Are there mixed content issues?
Are security headers present (HSTS, X-Frame-Options, CSP)?

Third-Party Scripts

Are known tracking/analytics scripts detected?
Are advertising pixels present?
Are session recording tools detected?

Technical

Is there a robots.txt?
Is there a sitemap?
Are there any obvious data leakage issues in page source?

Each check returns a pass, fail, or warning status, along with a plain-English explanation of what was found and why it matters.

The Interesting Part: Using Claude to Analyse Privacy Policies

Most of the checks are deterministic - I'm looking for specific HTML elements, HTTP headers, or known script signatures. But privacy policy analysis is different. A privacy policy is a natural language document and the question isn't just "does one exist" but "does it actually say the right things?"

This is where the Claude API comes in.

I fetch the privacy policy content and send it to Claude Haiku with a structured prompt asking it to evaluate specific GDPR requirements:

import anthropic

def analyse_privacy_policy(policy_text):
    client = anthropic.Anthropic()

    prompt = f"""
    You are a GDPR compliance analyst. Analyse the following privacy policy and evaluate 
    whether it covers each of these required elements under UK GDPR / EU GDPR:

    1. Identity and contact details of the data controller
    2. Purposes and lawful basis for processing
    3. Legitimate interests (if relied upon)
    4. Recipients or categories of recipients of personal data
    5. Details of transfers to third countries and safeguards
    6. Retention periods
    7. Rights of the data subject (access, rectification, erasure, portability, objection)
    8. Right to withdraw consent
    9. Right to lodge a complaint with a supervisory authority
    10. Whether provision of data is a statutory/contractual requirement

    For each element, respond with: PRESENT, PARTIAL, or MISSING, followed by a brief 
    one-sentence explanation.

    Respond only in the structured format requested. Do not add preamble or commentary.

    Privacy Policy:
    {policy_text[:8000]}
    """

    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=1000,
        messages=[{"role": "user", "content": prompt}]
    )

    return message.content[0].text

Haiku is fast and cost-effective for this task - I don't need Claude's full reasoning capability here, just reliable structured analysis of a document. The truncation to 8,000 characters handles the cases where policies are extremely long while keeping API costs predictable.

The response gets parsed and fed into the report alongside the deterministic checks.

Auto-Detecting the Privacy Policy URL

One thing I spent more time on than expected: finding the privacy policy in the first place.

I could have added a form field asking users to paste the URL, but that's friction and users often don't know the exact URL offhand. Instead I built an auto-detection function:

def find_privacy_policy_url(base_url, soup):
    # Common privacy policy URL patterns
    privacy_patterns = [
        r'privacy[-_]?policy',
        r'privacy[-_]?notice',
        r'data[-_]?protection',
        r'privacy',
    ]

    # Check all links on the page
    for link in soup.find_all('a', href=True):
        href = link['href'].lower()
        text = link.get_text().lower()

        for pattern in privacy_patterns:
            if re.search(pattern, href) or re.search(pattern, text):
                return urljoin(base_url, link['href'])

    # Fallback: try common paths directly
    common_paths = [
        '/privacy-policy',
        '/privacy',
        '/data-protection',
        '/legal/privacy',
    ]

    for path in common_paths:
        url = urljoin(base_url, path)
        try:
            response = requests.head(url, timeout=5)
            if response.status_code == 200:
                return url
        except:
            continue

    return None

This handles the vast majority of sites cleanly. If no policy is found, that itself becomes a finding in the report.

Generating the PDF Report with ReportLab

I initially looked at WeasyPrint for PDF generation - it produces beautiful output from HTML/CSS. But it has a GTK dependency that caused headaches on my Windows development machine. ReportLab is pure Python, installs cleanly everywhere, and gives you precise control over layout.

The report is structured as:

Cover page - domain scanned, date, overall compliance score
Executive summary - high-level findings with a visual pass/fail breakdown
Detailed findings - each of the 23 checks with status, explanation, and recommendation
Priority actions - the top issues ranked by severity

from reportlab.lib.pagesizes import A4
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, Table
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
from reportlab.lib import colors

def generate_report(scan_results, domain, output_path):
    doc = SimpleDocTemplate(
        output_path,
        pagesize=A4,
        rightMargin=50,
        leftMargin=50,
        topMargin=50,
        bottomMargin=50
    )

    story = []
    styles = getSampleStyleSheet()

    # Build report sections
    story.extend(build_cover_page(domain, scan_results, styles))
    story.extend(build_executive_summary(scan_results, styles))
    story.extend(build_detailed_findings(scan_results, styles))
    story.extend(build_priority_actions(scan_results, styles))

    doc.build(story)

The overall compliance score is calculated by weighting checks by severity - a missing HTTPS is weighted higher than a missing sitemap, for example.

Payments with Stripe

Stripe handles the £29.99 one-off payment. The flow is:

User enters domain → Stripe Checkout session created
User pays → Stripe webhook fires checkout.session.completed
Webhook triggers the async scan
Report emailed on completion

Using webhooks rather than redirect-based confirmation means the scan triggers reliably even if the user closes the browser after paying.

@csrf_exempt
def stripe_webhook(request):
    payload = request.body
    sig_header = request.META.get('HTTP_STRIPE_SIGNATURE')

    try:
        event = stripe.Webhook.construct_event(
            payload, sig_header, settings.STRIPE_WEBHOOK_SECRET
        )
    except ValueError:
        return HttpResponse(status=400)
    except stripe.error.SignatureVerificationError:
        return HttpResponse(status=400)

    if event['type'] == 'checkout.session.completed':
        session = event['data']['object']
        domain = session['metadata']['domain']
        customer_email = session['customer_details']['email']
        order_id = session['id']

        run_scan_async(domain, order_id, customer_email)

    return HttpResponse(status=200)

What I'd Do Differently

Remediation guidance. The report tells you what's wrong but not always how to fix it. I deliberately left this out to ship faster, but it's the most common piece of feedback from users. It's next on the roadmap.

Recrawling sub-pages. Currently the scanner analyses the homepage and any linked pages it can find. A more thorough scan would systematically crawl deeper, particularly for e-commerce sites with checkout flows on different pages.

Caching policy analysis. If the same privacy policy URL appears in multiple scans, I'm hitting the Claude API each time. A simple hash-based cache would reduce costs significantly at scale.

The Live Product

ClearlyCompliant is live at clearlycompliant.co.uk. If you want to see what the report output looks like or run a scan on a site you're working on, the £29.99 one-off report is available directly on the site.

Happy to answer questions on any part of the build in the comments - the threading approach, the ReportLab PDF generation, the Claude API integration, or the Stripe webhook setup. All of it was figured out the hard way so ask away.

GDPR Compliance Checklist for Web Developers in 2026

Joe Seabrook — Sat, 06 Jun 2026 13:12:47 +0000

You've built the app. You've written the privacy policy. You've added a cookie banner. Job done, right?
Not quite. GDPR compliance isn't a single checkbox, it's a spread of technical, legal, and operational requirements that touch almost every layer of a web project. Fines for non-compliance can reach €20 million or 4% of global annual turnover, whichever is higher. And yes, small sites get caught too.
This checklist covers the areas developers are most commonly responsible for, or at least need to flag to their clients before handoff.

Lawful Basis for Processing Data Before you collect a single byte of personal data, you need a lawful basis under Article 6 of GDPR. The six lawful bases are:

Consent - the user has actively agreed
Contract - processing is necessary to fulfil a contract with the user
Legal obligation - you're required to process the data by law
Vital interests - processing is necessary to protect someone's life
Public task - you're carrying out a task in the public interest
Legitimate interests - you have a genuine, proportionate reason to process

Most web apps rely on consent or contract. The mistake developers make is assuming consent is implied. It isn't. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count.
Check: Have you identified and documented the lawful basis for every type of personal data your site processes?

Cookie Consent Cookies that are not strictly necessary require explicit, opt-in consent before they fire. This includes:

Analytics cookies (Google Analytics, Plausible, Fathom)
Marketing/retargeting pixels (Meta Pixel, Google Ads)
Session recording tools (Hotjar, FullStory)
A/B testing tools (Optimizely, VWO)

A compliant cookie banner must:

Present options clearly, without dark patterns
Make declining as easy as accepting (no grey-out on the reject button)
Not pre-select any non-essential categories
Allow users to withdraw consent at any time
Not block access to the site if the user declines

Check: Are all non-essential scripts blocked until consent is given? Inspect your network tab on first load with a clean session, anything firing before consent is a violation.

Who you are and how to contact you (and your DPO if applicable)
What personal data you collect and why
The lawful basis for each type of processing
How long you retain data
Who you share data with (third-party processors, sub-processors)
Users' rights under GDPR (access, rectification, erasure, portability, objection)
Whether you transfer data outside the UK/EEA, and the safeguards in place
How users can make a complaint to the ICO (or relevant supervisory authority)

Check: Is the privacy policy linked from every page that collects data (forms, checkout, sign-up)? Is it accessible before the user submits any personal information?

Data Minimisation GDPR's data minimisation principle (Article 5) requires that you only collect what you actually need. This is somewhere developers can make a real difference at the design stage. Common violations:

Contact forms asking for phone numbers that are never used
Sign-up forms requiring date of birth for no functional reason
Server logs retaining full IP addresses indefinitely
Analytics collecting more granular data than necessary

Check: Go through every form and data collection point on the site. For each field, ask: do we actually need this to deliver the service? If not, remove it.

Data Retention Storing data indefinitely is a GDPR violation. You need a retention policy that defines how long each category of data is kept, and a mechanism to delete or anonymise it after that period. Common areas to address:

User account data - what happens when an account is deleted or inactive?
Order/transaction records - often kept for tax/legal reasons, but there's still a limit
Contact form submissions - usually no reason to keep these beyond a few months
Server and application logs - consider truncating or anonymising IP addresses
Email marketing lists - unsubscribers should be purged or suppressed

Check: Do you have automated deletion or anonymisation in place, or are you relying on manual processes? Manual processes tend not to happen.

User Rights
GDPR grants users several rights that your application needs to support. Depending on your scale and tooling, some of these can be handled manually, but the process needs to exist and you need to be able to respond within 30 days.
Right of access (SAR) - Users can request a copy of all data you hold about them. You need to be able to export this.
Right to erasure - The "right to be forgotten." You must be able to delete a user's data from your systems, including backups (within reason) and any third-party processors you've passed data to.
Right to rectification - Users can ask you to correct inaccurate data.
Right to portability - Users can request their data in a machine-readable format (e.g. JSON or CSV).
Right to object - Users can object to certain types of processing, particularly direct marketing.
Check: How would you currently handle a subject access request? Do you know every place a user's data lives (database, email platform, analytics, CRM, support tool)?
Third-Party Processors
Every third-party tool you integrate with that handles personal data on your behalf is a data processor. Under GDPR, you must have a Data Processing Agreement (DPA) in place with each of them.
Most reputable SaaS providers have a DPA you can sign or accept online (Stripe, Mailchimp, AWS, Google, etc.). You also need to list them in your privacy policy.
If any of these processors are based outside the UK or EEA, you need appropriate safeguards for the transfer, usually Standard Contractual Clauses (SCCs).
Check: Make a list of every third-party tool that touches personal data. Have you signed their DPA? Are they in your privacy policy?
Forms and Data Collection Points
Every form that collects personal data needs:

A clear explanation of what the data will be used for (at the point of collection, not buried in a privacy policy)
A link to your privacy policy
Explicit consent where required (e.g. for marketing emails — a pre-ticked opt-in doesn't count)
HTTPS (non-negotiable)

Check: Audit every form on the site. Is there any form collecting data without a clear purpose statement and privacy policy link?

Security Measures GDPR requires "appropriate technical and organisational measures" to protect personal data (Article 32). For most web applications, this means:

HTTPS everywhere (HSTS is a good addition)
Passwords hashed with a modern algorithm (bcrypt, Argon2) — never stored in plain text
Access controls - does only the right people/systems have access to personal data?
Dependency management - are you keeping libraries up to date? Outdated dependencies are a common breach vector
Database security - is your database exposed to the internet? Are credentials stored securely?
Regular backups, stored securely

Check: When did you last review who has access to your production database and admin panels? Principle of least privilege applies.

Data Breach Response Plan Under GDPR, if you suffer a personal data breach, you have 72 hours to notify your supervisory authority (the ICO in the UK) if the breach is likely to result in risk to individuals. High-risk breaches also require direct notification to affected users. This means you need:

A way to detect breaches (monitoring, alerts)
A documented process for assessing severity
Clear ownership of who notifies the ICO
A record of breaches (even those you don't report)

Check: If you discovered a breach today, do you know exactly what to do and who is responsible?

Records of Processing Activities (ROPA) If your organisation has 250 or more employees, you're required to maintain a formal Record of Processing Activities under Article 30. Below that threshold it's best practice, and the ICO strongly recommends it. A ROPA documents:

What personal data you process
Why you process it
Who has access to it
Where it's stored (including third-country transfers)
How long you keep it

Check: Even if you're not required to maintain a formal ROPA, do you have enough documentation to answer an ICO enquiry confidently?

Age Verification (if applicable) If your service is directed at or likely to be used by children, you have additional obligations. In the UK, the Children's Code (Age Appropriate Design Code) sets high standards for services likely to be accessed by under-18s, including defaulting to high privacy settings and not profiling children. If there's any chance your service reaches minors, this needs specific legal advice, it's one of the more complex areas of UK data law right now. Check: Is your service likely to be used by under-18s? If so, have you addressed the Children's Code?

Wrapping Up
GDPR compliance isn't something you bolt on at the end of a project — it needs to be considered from the start. The good news is that most of it is straightforward once you know what to look for.
If you're handing off a project to a client or want a quick sense of where a site stands, ClearlyCompliant analyses your site's GDPR compliance and delivers a detailed PDF report covering the key risk areas — useful as a starting point or a sanity check before launch.

Disclaimer: This article is for informational purposes and does not constitute legal advice. For specific legal questions around GDPR compliance, consult a qualified data protection professional.

I Thought My Contact Form Was Working — It Wasn’t

Joe Seabrook — Wed, 01 Apr 2026 08:48:29 +0000

I had a contact form live on a website for months.

It looked fine.

It submitted correctly.

There were no errors.

Technically, it was working.

But there was one problem.

No leads were coming through.

Or at least… that’s what we thought.

The moment I realised something was off

After digging into it, we found something surprising.

Leads were coming in.

They were just sitting in an inbox.

Unread.

Sometimes for hours.

Sometimes for days.

And by the time they were seen, the customer had already gone somewhere else.

The mistake I made (and I see it everywhere)

As developers, we tend to think:

If the form submits successfully, the job is done.

We focus on:

validation
backend handling
successful response

But we rarely think about what happens after the submission.

That’s where things break.

Forms don’t fail at submission

This was the shift for me:

A contact form doesn’t fail when it submits.

It fails when nobody responds.

And most setups rely on one thing:

email

Why email quietly kills your leads

Email feels like the default.

But in reality:

people don’t monitor their inbox constantly
emails get buried
notifications get ignored

For a lot of businesses (especially local ones), email is checked:

once a day
or when they “get around to it”

That delay is everything.

If someone else replies faster, the lead is gone.

This is not a technical problem

Here’s the interesting part:

From a technical perspective, everything is fine.

A typical form submission looks like this:

{
  "name": "John",
  "email": "john@example.com",
  "message": "Can I get a quote?"
}

Your backend receives it.

Processes it.

Sends it somewhere.

No errors

No crashes

No bugs

And still…

no conversions

The real problem: visibility

The actual issue is simple:

The person who needs to see the message… doesn’t see it in time.

That’s it.

What changed everything for me

Once I realised this, my thinking completely shifted.

Instead of asking:

“Did the form submit?”

I started asking:

“Did the person actually see it?”

The simplest fix

You don’t need to rebuild your form.

You don’t need a complex backend.

You just need to change where the message goes.

For a lot of use cases, that means sending it somewhere like:

WhatsApp
SMS
anything real-time

Something that:

triggers a notification
gets seen instantly
is hard to ignore

Why this matters more than anything else

Most people don’t ignore leads on purpose.

They just:

don’t see them
see them too late
forget to reply

And from the user’s perspective?

It feels like the form didn’t work.

The takeaway

The biggest lesson for me wasn’t technical.

It was behavioural.

Users don’t care if your form works.

They care if you reply.

If replies are slow…

Your form might as well be broken.

Curious — what are you using?

How are you handling contact form submissions right now?

Email?
Slack?
Something custom?

And more importantly:

How fast do you actually see them?

How to Send HTML Form Submissions to WhatsApp (Without Building a Backend)

Joe Seabrook — Tue, 24 Mar 2026 10:57:22 +0000

Most contact forms don’t fail — they get missed

Most websites still send contact form submissions to email.

The problem is — email gets missed.

If you’re not checking your inbox constantly, new enquiries can sit there for hours. In a lot of cases, the first person to respond wins the lead, so that delay can cost you real opportunities.

So instead of sending submissions to email, I started looking at a better option:

👉 Send them to WhatsApp instead

Why WhatsApp works better than email

The difference is simple:

Email → checked occasionally
WhatsApp → checked instantly

That means:

faster response times
fewer missed enquiries
better conversion from your website

Option 1: Build it yourself

You can send form submissions to WhatsApp yourself.

But it usually involves:

a backend (Node, Python, etc.)
WhatsApp Business API integration
message formatting logic
handling failures and fallbacks

For most projects, this is more complexity than needed.

Option 2: Use a form backend

A simpler approach is to use a form backend that handles delivery for you.

Instead of building everything:

Keep your existing HTML form
Send submissions to a backend endpoint
Receive them instantly on WhatsApp

Example HTML form

<form action="https://web2phone.co.uk/api/v1/submit/" method="POST">
  <input type="hidden" name="public_key" value="YOUR_PUBLIC_KEY">

  <input name="name" placeholder="Your name" required>
  <input type="email" name="email" placeholder="you@example.com" required>
  <textarea name="message" placeholder="How can we help?" required></textarea>

  <button type="submit">Send</button>
</form>

Once submitted, the message is delivered directly to WhatsApp.

What the notification looks like

You receive something like:

New form submission

Name: John Smith
Email: john@example.com

Message:
Hi, I’d like to get a quote

What about failures?

A reliable setup should include a fallback.

👉 If WhatsApp delivery fails, the message should be sent to email instead

That way, you never lose a submission.

When this approach makes sense

This setup works especially well if you:

rely on contact forms for leads
need fast response times
build static sites or simple projects
want to avoid building backend form handling

Final thoughts

Most contact forms aren’t broken.

They just rely on a delivery method (email) that isn’t always seen quickly enough.

Switching to WhatsApp notifications is a simple change that can make a big difference in how quickly you respond — and how many leads you convert.

If you want a simple way to try this

I built a small tool called Web2Phone that handles this:

sends form submissions to WhatsApp
optional email fallback
works with plain HTML forms

You can also read the full step-by-step guide here:

👉 https://web2phone.co.uk/blog/send-form-to-whatsapp/?utm_source=devto&utm_medium=post&utm_campaign=whatsapp_form

Curious how others are handling this — still using email or something faster?

Most Contact Forms Don’t Fail Because of Code — They Fail Because of Human Behaviour

Joe Seabrook — Tue, 17 Mar 2026 14:35:54 +0000

Developers usually assume contact form problems are technical.

Spam protection.

Email configuration.

SMTP errors.

Backend bugs.

All of these can break a form.

But after watching hundreds of real form submissions from production websites, I’ve realised something surprising:

Most contact forms don’t fail because of code.

They fail because of human behaviour.

The problem developers usually focus on

When we build a contact form we worry about things like:

validation
spam protection
email delivery
backend processing
database storage

All important problems.

But those usually aren’t what break the system.

The real failure point happens after the form works perfectly.

What actually happens in real life

A typical workflow looks like this:

Customer submits a form
Website sends an email notification
Email lands in inbox
Business owner eventually reads it

Sounds fine.

But here’s the reality.

The email is often missed

Small business owners rarely monitor their inbox constantly.

Common scenarios include:

Email arrives while they’re working
Inbox already contains hundreds of messages
Message lands in spam
Notifications are turned off
Email gets buried under marketing emails

Sometimes the message is seen hours later.

Sometimes never.

From a developer perspective the form worked perfectly.

But from a business perspective, the lead was lost.

Speed matters more than developers realise

For many industries the first response wins the job.

Think about services like:

plumbers
locksmiths
electricians
emergency repairs
home services

When someone submits a contact form they often contact multiple businesses at the same time.

The first one to reply usually gets the work.

Not the one with the nicest website.

The hidden cost of slow responses

Imagine this scenario:

A customer submits enquiries to three companies.

Company	Response Time	Result
Company A	5 minutes	Wins the job
Company B	1 hour	Too late
Company C	Never saw the email	Lost lead

Company B and C think their website is working perfectly.

But they’re silently losing customers.

And developers often never see this part of the story.

The real lesson for developers

The lesson here isn’t about writing better form code.

It’s about delivery speed.

A form system isn’t just about collecting data.

It’s about getting that message in front of a human quickly.

The best systems don’t just send emails.

They deliver notifications somewhere people actually look immediately.

For example:

SMS
WhatsApp
Slack
CRM alerts
push notifications

Anywhere that interrupts attention.

What happened when I changed the notification method

While building websites for small businesses, I kept seeing the same problem: form enquiries sitting unread in email inboxes.

Eventually I started experimenting with sending submissions directly to WhatsApp instead.

The difference was surprisingly big.

Clients who previously responded to enquiries hours later were suddenly replying within minutes, simply because the message arrived somewhere they were already looking all day.

That observation is actually what led me to build a small tool called Web2Phone, which sends form submissions to WhatsApp instead of email.

It started as a solution to a real problem I kept seeing — not a product idea.

And honestly, the biggest lesson wasn’t technical.

It was realising that delivery speed matters more than the form itself.

A small change that makes a big difference

When enquiries arrive somewhere people already check constantly, response times drop dramatically.

In many cases I’ve seen response times go from:

hours → minutes

That one change alone can dramatically improve lead capture.

Not because the form improved.

But because the notification method improved.

Something developers often forget

Developers tend to optimise for technical correctness.

But users experience software through human behaviour.

The system isn’t complete when the form submits successfully.

It’s complete when the right person sees the message quickly.

Curious how others handle this

How do you normally deliver contact form submissions?

Email
CRM
Slack
SMS
WhatsApp
Something else?

I’m curious what developers are doing in real production systems.

How to Handle HTML Forms Without a Backend (2026 Guide)

Joe Seabrook — Tue, 10 Mar 2026 06:51:58 +0000

Collecting data from website visitors is a fundamental need for almost every website. Whether you're building a portfolio, a static site, or a landing page, you'll probably need a contact form.

But there’s a classic problem developers run into:

Where does the form submission go if you don’t have a backend?

In this guide we'll break down the main approaches developers use to handle HTML forms without a backend, and the pros and cons of each option.

Why HTML Forms Normally Require a Backend

HTML forms are designed to send data to a server using the POST request.

Normally the form action points to a backend endpoint that processes the submission.

Typical backend setups include:

PHP scripts
Node.js / Express APIs
Python (Flask or Django)
Ruby / Rails

The backend usually:

validates the data
sends email notifications
stores the submission
triggers webhooks or integrations

Without that server endpoint, the browser has nowhere to send the form submission.

That’s why developers building static sites often ask:

How do I create an HTML form without a backend?

The Problem With Email-Only Form Handling

One workaround developers sometimes use is mailto: links or simple email scripts.

Unfortunately this approach has a few issues.

Spam filtering

Messages from unknown servers or scripts often end up in spam folders.

Missed notifications

If the recipient doesn't constantly monitor their inbox, leads can be missed.

No delivery guarantees

If an email fails, there is usually no retry or fallback.

Many developers eventually move to a form backend service instead.

Option 1 — Build Your Own Backend

If you’re comfortable with server-side development, you can create your own form handler.

Common approaches include:

Node / Express

app.post('/contact', (req, res) => {
  const { name, email, message } = req.body
  // validate and send email
})

Python (Flask)

@app.route('/contact', methods=['POST'])
def contact():
    data = request.form
    # process form submission

PHP

mail($to, $subject, $message);

While this gives you full control, it also means you must manage:

hosting
security
spam protection
email delivery
maintenance

For many small projects this is unnecessary complexity.

Option 2 — Use a Form Backend Service

This is the most common solution for static sites.

A form backend service provides a hosted endpoint that receives form submissions.

Examples include:

Formspree
Basin
Formkeep
Getform

You simply update your form's action attribute to their endpoint.

Example:

<form action="https://formspree.io/f/your-form-id" method="POST">

<label>Name</label>
<input type="text" name="name" required>

<label>Email</label>
<input type="email" name="email" required>

<label>Message</label>
<textarea name="message" required></textarea>

<button type="submit">Send</button>

</form>

These services typically handle:

spam filtering
submission storage
email notifications
webhooks

If you're comparing options, you may find these breakdowns useful:

Formspree pricing explained (2026)
Formspree free plan limits

Option 3 — Messaging Notifications (WhatsApp / SMS)

Email works well in many cases, but it’s not always ideal for time-sensitive enquiries.

For example:

service businesses
agencies handling client leads
urgent support requests

Some modern form backends now deliver submissions to messaging platforms.

These may include:

WhatsApp notifications
SMS alerts
Slack or webhook integrations

This can make it much easier to see new enquiries immediately.

If you're exploring this approach, you might find this comparison useful:

👉 https://web2phone.co.uk/blog/best-form-backend-whatsapp-notifications-2026/

What To Look For In A Form Backend

Not all form services offer the same capabilities.

Here are some features developers often look for:

spam protection (CAPTCHA or honeypots)
rate limiting
webhook integrations
submission logs
multiple notification channels
domain allow-listing
reliable delivery

These features become more important as a site grows.

A WhatsApp-First Approach

One newer approach is delivering form submissions to messaging apps instead of relying on email alone.

For example, Web2Phone sends form submissions to WhatsApp first, with automatic email fallback if WhatsApp delivery fails.

The current beta plan supports:

100 WhatsApp notifications per month
100 email notifications per month
up to 3 forms

This kind of setup can be useful for teams who respond faster to messaging notifications than email.

If you're comparing tools, you can see the differences here:

👉 https://web2phone.co.uk/blog/formspree-vs-web2phone-2026/

FAQ

Can you create an HTML form without a backend?

Yes. Using a form backend service allows you to collect submissions without running your own server.

What is a form endpoint?

A form endpoint is a URL that receives form submissions via POST requests and processes the data.

What is the easiest way to handle forms on static sites?

Most developers use a hosted form backend service. It removes the need to run server-side code.

Are email notifications reliable?

Email works in many cases but can be affected by spam filters or delayed inbox checking. Some teams prefer additional notification channels like messaging apps or webhooks.

Final Thoughts

Handling HTML forms without a backend is much easier today than it was a few years ago.

Developers now have multiple options:

building a custom backend
using a hosted form service
using messaging notifications
integrating webhooks or automation tools

The best choice depends on your project, your stack, and how quickly you need to respond to submissions.

If you're building static sites or frontend-heavy projects, choosing the right form backend can save a lot of time and complexity.

Why Email-Only Contact Forms Are Failing in 2026 (And What Developers Should Do Instead)

Joe Seabrook — Mon, 02 Mar 2026 08:09:05 +0000

Email delivery isn’t the problem anymore. Visibility is.

In 2026, email-only contact forms are technically reliable but increasingly ineffective for urgent workflows. Here’s what developers should rethink.

The Illusion of Reliability

For years, most contact form systems followed the same model:

HTML form
Backend endpoint
SMTP configured
Return 200 OK

Technically, everything works. Emails are delivered. Logs are clean. No bounce issues.

And yet businesses still miss leads.

The problem isn’t deliverability. It’s visibility.

SMTP Success ≠ Human Attention

There’s a dangerous assumption built into many form backends:

If the email is delivered, the human will see it.

That assumption no longer holds.

Gmail tabs filter notifications
Spam detection is aggressive
Inbox overload hides important messages
Mobile users don’t constantly monitor email

For low-urgency contact pages, this might be fine.

But for emergency services, trades, agencies, and competitive local businesses — response time determines revenue.

The Developer Blind Spot

Developers optimise for:

API reliability
Retry logic
Queue performance
Webhook success

But the metric that matters most for many businesses is:

Response time.

If a locksmith receives an enquiry at 11pm but sees it at 7am, the job is gone.

The first responder wins.

Where Email-Only Systems Break Down

Email-only contact forms work well for:

Portfolio sites
Low-volume brochure sites
Non-urgent enquiries

They struggle in:

Emergency trades
Healthcare services
Agencies competing for inbound leads
Time-sensitive booking workflows

In these cases, the issue isn’t whether the message was sent — it’s whether it was seen in time.

What Developers Should Do Instead

1. Use Multi-Channel Delivery

Combine email with higher-visibility channels such as WhatsApp or SMS.

2. Implement Fallback Logic

If the primary channel fails, automatically retry via a secondary channel.

3. Add Domain Allow-Listing

Restrict which domains can submit to your endpoint to reduce abuse and spam.

4. Use Rate Limiting + Honeypots

Lightweight spam protection reduces malicious traffic without degrading UX.

5. Log Delivery Without Retaining PII

Store delivery metadata. Hash destination values. Remove message content after successful delivery.

Rethinking Notification Architecture

The better question is not:

Was the email delivered?

It’s:

How fast can the business actually see and respond to this enquiry?

That shift changes backend architecture decisions.

Some newer form backends now prioritise instant messaging delivery (such as WhatsApp) with automatic email fallback if delivery fails. That kind of architecture focuses on visibility rather than just SMTP success.

If you're curious about how WhatsApp-first systems compare to traditional email-first tools, I wrote a deeper technical comparison here:

https://web2phone.co.uk/blog/formspree-vs-web2phone-2026/

Final Thought

Email isn’t broken.

But email-only contact forms are increasingly incomplete for urgent workflows.

Developers have already mastered reliable delivery.

The next optimisation layer is:

Visibility
Notification priority
Response speed

In many industries, the fastest responder wins.

How to Send Contact Form Submissions to WhatsApp (No Backend Required)

Joe Seabrook — Tue, 24 Feb 2026 12:30:00 +0000

The Problem

Many websites use contact forms. Most send submissions to email. But email isn’t always reliable—messages get lost in spam, delayed, or buried under marketing clutter. For trades and service businesses, every minute counts when a lead comes in.

If you want contact form submissions delivered instantly to WhatsApp, you normally need backend logic or third-party APIs. That’s a big ask if you want something quick and simple.

Why Email Delivery Is Fragile

SMTP configuration is fiddly and easy to misconfigure
Shared hosting often means bad mail reputation
Spam filters can eat legit messages
Business owners don’t check their inboxes constantly
Important leads get buried under newsletters and promos

It’s not about scaring anyone—just reality for small teams.

The Traditional Way (Technical Explanation)

Normally, to send form data to WhatsApp, you’d need:

A server-side form handler (PHP, Node, Django, etc.)
WhatsApp Business API setup (not trivial)
Webhooks and API tokens
Hosting configuration to keep things secure

It’s not as simple as adding a form action. There’s real backend work involved—especially if you want delivery guarantees.

The Lightweight Approach

There’s a simpler way: use a form endpoint service.

Your HTML form posts to an external endpoint
The service does all the validation and delivery
No server code required on your end

For example, Web2Phone:

Accepts standard HTML form submissions
Delivers to WhatsApp (with optional email fallback)
Lets you set up domain allow-listing and rate limits
Automatically deletes successful submissions for privacy

No hype—just a practical option.

Practical Example

Here’s what it looks like in practice:

<form action="https://web2phone.co.uk/api/v1/submit/" method="POST">
  <input type="hidden" name="public_key" value="YOUR_PUBLIC_KEY">
  <input name="name" required>
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

The public_key links the form to your account (no secrets in the browser)
On submission, the service validates and delivers the message
Delivery is tracked—if WhatsApp fails, fallback to email

WhatsApp + Email Fallback

You can choose WhatsApp only, email only, or both. If WhatsApp delivery fails, it automatically sends via email. This keeps things reliable without extra logic on your end.

Who This Is For

Static site owners
Agencies and freelancers
Service businesses
Trades who need to respond fast to emergency enquiries Basically, anyone who wants instant lead alerts without backend hassle.

Security & Spam Protection

Domain allow-listing (only your sites can submit)
Rate limiting to prevent abuse
Honeypot and validation checks
GDPR: successful submissions auto-deleted after delivery

Conclusion

If you want to keep things simple and respond faster, this approach is worth a look. No backend headaches, just instant notifications where you’ll actually see them.
If you want to test this, you can create a free account and generate a public key in under a minute.

I Built the Product. Marketing Is the Part That’s Breaking Me.

Joe Seabrook — Fri, 16 Jan 2026 09:03:56 +0000

When I started building Web2Phone, I thought the hard part would be technical: infrastructure, edge cases, deliverability, security, GDPR… all the stuff that can quietly ruin your week.
Turns out I was wrong.
Building the product was the part I understand.

Marketing is the part that makes me feel like I’m guessing in public.
I’m a solo founder and fullstack developer. I can ship features, fix bugs, and make a system reliable. But the minute I need to explain what I built — clearly, consistently, and in a way that makes strangers care — I start hesitating.
And I think a lot of devs hit this wall.

The weird emotional gap between “done” and “distributed”
When you’re building, progress feels obvious:

feature shipped
tests passing
user flow improved
bug fixed
server stable But marketing progress is… foggy. You can write a post and get no response.

You can record a video and feel cringe the whole time.

You can message people and worry you’re being annoying.
And the worst part is: silence doesn’t tell you what’s wrong.
Is the product unclear?

Is the audience wrong?

Is the message boring?

Is the channel wrong?

Did you post at the wrong time?

Or did you just not do enough reps yet?

The trap: “I’ll market it when it’s ready”
I kept telling myself I’d market Web2Phone “properly” once it was ready.
But “ready” is a moving target.
There’s always another improvement you can justify:

onboarding could be smoother
dashboard could be nicer
docs could be clearer
one more feature would make it easier to sell The truth is: sometimes “not ready” is just a socially acceptable way of saying: I’m not comfortable being seen trying.

What I’ve learned (so far) as a solo dev trying to market
I don’t have a big audience. I don’t have a budget. I’m not naturally salesy.
So I’m trying to treat marketing like development: small experiments, tight feedback loops, and shipping consistently.
Here’s what’s helped:
1) I stopped trying to sound like a company
Founder voice > brand voice (at least early on).
People don’t connect with “We are excited to announce…”

They connect with: “I built this because I got tired of missing enquiries.”
2) I’m focusing on one clear outcome
For Web2Phone, it’s simple:
When someone fills your website contact form, you get a WhatsApp message instantly.
That’s the whole pitch. Everything else is supporting detail.
3) I’m aiming for conversations, not virality
I used to think marketing meant “big posts”.
Now I’m trying to win smaller:
one useful comment
one DM conversation
one beta user who actually uses it
one piece of feedback that changes the product
Because one real user beats 1,000 impressions every time.
4) I’m learning that marketing is a skill, not a personality type
I used to think some people are “marketing people” and I’m not.
But marketing is just:
clarity
repetition
empathy
distribution
iteration
It’s awkward at first because it’s unfamiliar — not because you’re incapable.

Where I’m at right now
Web2Phone is in beta. I’ve got my first five active users, and I’m trying to onboard a few more.
And honestly, marketing still feels like the hardest part.
But I’m trying to show up anyway — even when it’s messy — because building something useful isn’t enough if nobody knows it exists.
If you’re a dev who’s built something and now feels stuck at the “how do I get users?” stage…
You’re not alone.
And if you’ve got any advice (or hard truths), I’d genuinely love to hear it.

The Hidden Cost of “Just Add a Contact Form”

Joe Seabrook — Tue, 30 Dec 2025 09:33:13 +0000

Every web developer has shipped this at least once:

A clean landing page
A simple contact form
A submit button that “works”

And technically, it does.

But after building sites for real people (not just demos), I’ve learned something uncomfortable:

A working form is not the same as a working enquiry system.

The illusion of “done”

When you’re learning web dev, forms feel like a finish line.

You validate the inputs.
You see the POST request hit your server.
You see the email arrive.

Job done.

But once real users are involved, that illusion breaks down fast.

I started noticing a pattern across freelance projects:

Clients saying “someone told us they messaged”

No record in the inbox

No errors on the server

No obvious failure point

Everything worked.
Yet the lead was gone.

The problem isn’t code — it’s human behaviour

This took me longer than it should have to realise.

Most form-handling setups assume something that just isn’t true:

That people actively monitor email.

Small business owners don’t.

They’re driving.
They’re with customers.
They’re on job sites.
Their inbox is chaos.

Even when email does arrive correctly, it often goes unseen for hours — sometimes days.

That’s not a technical bug.
It’s a workflow mismatch.

Why email-only forms are fragile

Over time I started listing every failure mode I’d seen in the wild:

Spam filtering

Full mailboxes

SMTP config drifting over time

Notifications silently disabled

Clients “testing it once” and forgetting it exists

Messages buried under newsletters and receipts

None of these show up in your console.
None throw errors.
All of them lose leads.

What actually gets seen

Here’s the uncomfortable truth:

Most clients respond faster to a WhatsApp message than an email, every single time.

Not because it’s better tech.
Because it matches how people already communicate.

It lights up the lock screen.
It feels urgent.
It gets opened.

Once I started routing form submissions somewhere clients actually look, response times improved immediately.

The mental shift that changed my builds

I stopped thinking of contact forms as:

“How do I send this somewhere?”

And started thinking:

“Where will this definitely be noticed?”

That shift changed how I design every form workflow now:

Immediate delivery

Multiple channels

A log that exists even if delivery fails

No single point of silence

Why I ended up building my own solution

After solving this problem manually across too many projects, I eventually built a small tool for myself that:

Accepts form submissions

Forwards them to WhatsApp instantly

Falls back to email

Keeps a record if delivery fails

That internal tool later became Web2Phone, but the tool itself isn’t the point.

The lesson is.

The takeaway

If you’re building sites for real people:

A form that submits ≠ a form that converts

Email is not a reliable attention channel

Speed of visibility matters more than delivery success

Silent failures are the most expensive ones

I’m curious — especially from freelancers and agency devs:
**
Have you ever had a client miss a form enquiry even though “everything was working”?**
What was the cause in your case?

I Built a Form Backend That Sends Submissions to WhatsApp — Beta Testers Wanted

Joe Seabrook — Thu, 18 Dec 2025 08:26:11 +0000

If you’ve ever shipped a simple landing page with a contact form, you know the moment.

You finish the HTML.
You add validation.
You hit “Submit”…

…and then you remember: forms don’t do anything without a backend.

For beginners, that’s where projects stall.
For freelancers, that’s where a “quick site” turns into SMTP setup, spam issues, and “why didn’t we get that enquiry?” messages from clients.

So I built Web2Phone: a lightweight form backend that forwards submissions to WhatsApp (and email as a fall back).

This week I’m looking for a few more beta users to try it on real projects and tell me what breaks, what’s confusing, and what features would make it a no-brainer.

The idea (in one sentence)

Drop in a snippet, and your form submissions get delivered to WhatsApp instantly — no server, no database, no SMTP.

Email is supported too (and it’s a great fall back), but WhatsApp is the “you’ll actually see it” channel for a lot of small businesses.

Why WhatsApp instead of “just email”

Email delivery is fragile in ways most devs only learn after a few client sites:

Messages land in spam
Mailboxes get full
Notifications get ignored
Clients don’t check inboxes during the day

WhatsApp is the opposite:

It’s on the lock screen
It gets opened fast
It feels urgent

If the goal is “respond quickly to enquiries,” WhatsApp is often the shortest path.

How it works (high level)

Web2Phone gives you:

A dashboard to create and manage forms
An endpoint that receives submissions securely
Delivery to WhatsApp
Email fall back
Failure logs so you can see any missed submissions

You keep your frontend exactly how you want it. Web2Phone handles the boring parts.

Try it in a few minutes

The beta flow is intentionally simple:

Sign up
Create a form
Paste the embed snippet into your site
Done — submissions route to WhatsApp/email

If you want to kick the tyres quickly, use it on:

a portfolio contact form
a landing page
a client “get a quote” form
any small MVP where you don’t want to build backend plumbing

What you get on the free plan

Right now the public free plan includes:
**

1 form
3 WhatsApp notifications / month
25 emails / month **

That’s enough to test the full flow end-to-end.

Beta users: I can upgrade you (Starter) while you test

I don’t have a formal “beta offer” page yet, but here’s what I’ve been doing for current beta users:
**

Upgrading them to Starter while they test
100 WhatsApp notifications / month
Unlimited emails
Up to 5 forms **

If you sign up and actually try it on a real project, comment below and I’ll sort the upgrade for you.

What I need feedback on (pick one)

If you try it, I’d love feedback on one of these (whatever you notice first):

Was setup genuinely fast?
Anything confusing in the dashboard?
What would make you trust it for client sites?
Any missing features that are deal-breakers?

Even “this is cool but I wouldn’t use it because ___” is extremely useful.

Link

If you build websites for small businesses (or you’re a frontend dev who hates backend chores), I’d love to have you as a beta tester.

Thanks — and if you’ve ever had a client miss a form enquiry, I’m curious: what was the cause in your case?

Why small business clients miss form submissions (and how to prevent it)

Joe Seabrook — Mon, 08 Dec 2025 08:35:08 +0000

If you build websites for small businesses, you have probably run into this problem at least once. The contact form works perfectly. The design is solid. You test it, your client tests it, and everyone thinks it is good to go.

Then a few weeks later you get that message.

“Hey, someone said they contacted us but we never received anything.”

At first you think it is a mistake. Then you check the server. Then the logs. Then the spam folder. And sure enough, the message is sitting there untouched.

After a couple of years of freelancing, I realised this is not a technical glitch. This is a pattern. A frustrating one. And it happens for reasons that are totally avoidable once you understand them.

Here are the most common reasons small business clients miss form submissions, based on real projects I have worked on, and what you can do to stop it happening.

1. Emails get lost in spam

This is the classic one. Even with a properly configured form, messages often get flagged. Free email providers like Gmail and Outlook are extra picky these days, and a lot of small business owners use free email accounts.

It only takes one bad flag for a message to disappear into spam for weeks.

How to reduce this:

Use SPF, DKIM and DMARC

Use a proper SMTP service

Avoid sending from generic addresses like noreply@something

Avoid subjects that look automated

These steps help, but they do not solve everything on their own.

2. Clients simply do not check their inbox

This is the part nobody likes to admit.

Most small business owners are not sitting in front of a computer checking their email all day. They are on the road, working with customers, running jobs, or juggling appointments.

Their inbox is usually overflowing. Important messages get buried within hours.

What they do check constantly:
Their phone.
More specifically, apps like WhatsApp.

This is the gap that causes so many missed leads. The message did not fail. The client just did not see it.

3. The form submission relies on only one channel

If the entire workflow depends on one thing (email), then all it takes is one small issue for a lead to be lost.

Spam filter
Full mailbox
Email app logged out
Slow server
Inbox clutter
Misconfigured SMTP
Wrong forwarding rule

Over the years I have seen all of these cause missed leads.

The safest setup is always:
Multiple delivery paths and a backup log.

If a message gets lost in one place, it survives somewhere else.

4. Clients test the form once and assume it works forever

This one surprised me at first.

A typical client tests the form on day one. They see an email arrive. They trust it. And then they never think about it again.

Months later, a misconfigured DNS record or server change causes problems, but nobody notices until a customer complains.

Automated logs and alternative notification channels prevent this awkward “your site is broken” conversation.

5. Email is slow compared to modern communication

Small business owners want to respond fast because fast responses convert.

Email is slow by nature. Notifications are delayed. Sometimes they do not show up at all. People swipe them away without thinking. It is not built for speed.

Messaging apps are instant. They buzz. They appear on the lock screen. They feel urgent in a way email never will.

That difference alone can double response times.

What I now do on every client site

After seeing these problems again and again, I changed my entire approach.

Here is the setup that has given the best results:

A simple HTML form

A honeypot to block obvious spam

Form submissions sent instantly to WhatsApp

Email as a fallback

A dashboard log for failed deliveries

This solves the speed issue. It solves the visibility issue. And it removes the dependency on a single fragile channel.

It is also what led me to build Web2Phone.co.uk, because I needed a reliable way to route form submissions where clients actually look.

If you have run into these problems too, let me know. I’m always curious how other freelancers handle contact forms and what has worked for you.