DEV Community: staticwebapps

I Found a Way to Deploy a Static Site by Just Zipping a Folder

Samuel Aondo — Mon, 14 Sep 2026 10:29:45 +0000

I found something new this week, and it's stuck with me because of how little it asks of you: you zip a folder, drop it in, and you get a live URL with SSL already on. That's the whole deploy.

The problem it solves

Every time I've wanted to put a small static site online — a portfolio, a docs site, a landing page, a hackathon demo — the actual build was the easy part. The deploy was where I lost time: picking a host, wiring up a git integration, figuring out a build command for a project that didn't really need one.

ZipHost skips all of that. You already know how to make a zip file — that's the entire workflow:

Zip your project folder (Finder, Explorer, or a build script — doesn't matter)
Drop it into the dashboard, or run one CLI command
Get a live URL, SSL included, in about 3.8 seconds on average

What's actually included

Free SSL on every site, no setup
One-click rollbacks — every deploy is kept and versioned
Deploy previews for sharing a change before it goes live
Password-protected links for client review
CLI or GitHub push if you'd rather automate it than drag files

Where it fits

It's not trying to be a platform for full applications — there's no server-side runtime here. But for the sites that "just need to exist somewhere" — portfolios, generated docs output, one-page landing pages, hackathon demos, client previews — it removes every step between "I have a folder" and "here's the link."

How to Host php website for free

Samuel Aondo — Mon, 14 Sep 2026 10:27:30 +0000

I had a small PHP script I wanted to share with a friend. Nothing fancy — no framework, no build step, just a handful of .php files that needed to live somewhere reachable by a URL.

Every "real" option I looked at wanted me to provision a VPS, install and patch PHP and a database by hand, and generate my own TLS certs before I could even see the thing running. That's a lot of setup for a weekend project.

What I used instead

I ended up on phphost — PHP hosting built around one idea: you already know how to write PHP, you shouldn't need to know Linux to ship it.

The deploy is genuinely just:

Upload a folder, a zip, or connect a git repo
It sets up the PHP runtime and HTTPS automatically
Your site is live at a working HTTPS URL in under 10 seconds

No config file, no shell to open.

What's actually included

Automatic HTTPS on every site, from the first deploy
Cron jobs, if you need something running on a schedule
MySQL support and per-site .env variables for secrets
Staging environments — a persistent pre-prod copy that doesn't count against your site limit
Deploy history with one-click rollbacks
Uptime monitoring that pings your site and tells you before a user does

GEO for Developers: Structuring Websites for AI Search, Retrieval, and Entity Clarity

Joyno Media — Fri, 04 Sep 2026 04:01:34 +0000

Generative Engine Optimization (GEO) is not only a content-writing task. Developers influence whether AI-powered search systems can reliably access, interpret, connect, and retrieve the information published on a website.

A GEO-friendly website should make important relationships obvious:

Organization → Services → People → Locations → Topics → Supporting Content

The objective is not to manipulate AI systems or guarantee citations. It is to reduce ambiguity and create a technically accessible information architecture that helps search engines and AI-powered retrieval systems understand what the website represents.

For developers, this means thinking beyond page speed and metadata. Website architecture, semantic HTML, entity consistency, internal linking, structured data, crawlability, and content relationships all contribute to how understandable a site becomes.

Start With Crawlability and Indexability

AI-search optimization cannot compensate for important content that search systems cannot reliably access.

Before considering advanced GEO implementation, verify that important pages are:

Publicly accessible
Internally linked
Included in the intended crawl path
Not accidentally blocked
Returning the correct HTTP status
Using appropriate canonical URLs
Included in XML sitemaps where relevant
Rendered in a way search systems can process

Common problems include:

Important pages marked noindex
Incorrect canonical tags
Broken internal links
JavaScript-dependent content that fails to render reliably
Duplicate URLs
Redirect chains
Outdated XML sitemaps
Important pages buried deep in the architecture

GEO starts with technical accessibility.

If the page cannot be reliably discovered, the quality of its entity information becomes much less useful.

Create an Entity-Oriented Site Architecture

Traditional website architecture is often organized around navigation.

A GEO-focused architecture should also make the relationships between important business entities clear.

For a digital marketing business, a simplified structure might look like:

Organization

→ Digital Marketing
→ SEO
→ Generative Engine Optimization
→ Website Development
→ Branding
→ Commercial Video

Then each service can connect to supporting educational content.

For example:

Generative Engine Optimization

→ What Is GEO?
→ GEO vs SEO
→ Entity Optimization
→ AI Search Visibility
→ Structured Data
→ GEO Measurement

This creates a clearer knowledge graph within the website.

The pages do not need to describe themselves as a knowledge graph. The relationship is created through hierarchy, content, URLs, navigation, breadcrumbs, and internal links.

Give Important Entities Dedicated Pages

Important entities should not exist only as passing references inside unrelated pages.

Depending on the website, dedicated pages may be useful for:

The organization
Major services
Products
Locations
Team members
Founders
Industry solutions
Important technologies

A dedicated service page should clearly define the service instead of relying only on promotional copy.

For example:

Weak:

Transform your visibility with next-generation solutions.

Clearer:

Generative Engine Optimization helps businesses improve how clearly their brand, services, and website information can be understood by AI-powered search and answer systems.

The second version establishes an identifiable entity and its purpose.

Developers can support this clarity by ensuring each major entity has a stable URL, logical navigation position, descriptive metadata, and relevant internal links.

Use Semantic HTML to Communicate Structure

Visual design does not automatically communicate meaning to machines.

A heading that looks large because of CSS is not necessarily a semantic heading.

Use HTML structure to represent the content hierarchy accurately.

Important considerations include:

One meaningful primary heading
Logical H2 and H3 relationships
Semantic navigation
Proper lists
Tables for genuinely tabular information
Meaningful links
Appropriate article structure
Accessible labels

A page should remain structurally understandable even if its visual styling is removed.

For example, a service page may follow:

H1: Generative Engine Optimization Services

H2: What Is Generative Engine Optimization?

H2: How GEO Works

H2: What GEO Helps Businesses Improve

H2: GEO vs Traditional SEO

H2: What Businesses Should Consider

That hierarchy gives both users and machines clearer context than a collection of generic headings such as:

Discover
Transform
Grow
What's Next

Creative design language can remain, but important page structure should communicate actual meaning.

Make Important Answers Extractable

AI-powered retrieval systems may use only a small section of a page.

Developers and content teams should therefore design pages so important answers can stand on their own.

For example:

What is GEO?

Generative Engine Optimization is the process of improving digital content and website information so AI-powered search and answer systems can more accurately understand, retrieve, summarize, and potentially reference a business.

This works better than requiring the system to combine several paragraphs scattered across the page.

Useful components include:

Definition blocks
Short answer paragraphs
Step sequences
Comparison tables
Checklists
Clearly labeled FAQs

This also improves usability for people scanning the page.

Avoid Hiding Critical Information Inside Interfaces

Modern websites frequently place information inside:

Tabs
Accordions
Sliders
Modals
Interactive cards
Client-rendered components

These patterns are not automatically bad.

The problem occurs when essential business information exists only inside an interface that is difficult to render, inaccessible without interaction, or missing from the underlying document structure.

Important information such as:

Service descriptions
Location details
Company identity
FAQs
Pricing when publicly available
Product information

should remain technically accessible.

Developers should test pages beyond what appears visually in a browser.

Ask:

If an automated retrieval system accesses this page, is the important information actually present and understandable?

Strengthen Internal Linking With Context

Internal links do more than help users navigate.

They communicate relationships between entities and topics.

Consider these two anchors:

Weak:
Read more

Stronger:
Learn how structured data supports AI search visibility

The second link tells the user and the retrieval system what the destination page represents.

A GEO-friendly internal linking strategy should connect:

Service pages to supporting guides
Supporting guides back to relevant services
Topic clusters to pillar pages
Team profiles to authored content when appropriate
Location pages to genuinely available services
Related questions to deeper explanations

Avoid linking every keyword occurrence.

Internal links should describe real relationships.

Use Breadcrumbs to Reinforce Hierarchy

Breadcrumb navigation can provide another clear signal of site structure.

For example:

Home → Services → Generative Engine Optimization

or:

Home → Insights → AI Search → Entity Optimization

This makes the page's location within the broader website easier to understand.

Breadcrumbs also improve user navigation on larger websites.

When appropriate, the visible breadcrumb structure can be supported by valid BreadcrumbList structured data.

The markup should represent the actual page hierarchy rather than inventing one solely for search engines.

Implement Structured Data as Entity Support

Structured data can help machines interpret specific information about a page.

Depending on the website, useful schema types may include:

Organization
LocalBusiness
Service
Product
Person
Article
BlogPosting
BreadcrumbList
VideoObject
FAQPage when appropriate

The most important rule is accuracy.

Structured data should represent information that genuinely exists.

Do not invent:

Ratings
Reviews
Prices
Locations
Certifications
Employees
Services

For GEO, structured data should be treated as a machine-readable reinforcement of the visible content—not as a separate layer containing claims the user cannot see.

Connect Organization Information Consistently

The website should make its primary organization entity easy to identify.

Important organization information can include:

Official business name
Website
Logo
Contact information
Business description
Location
Relevant social profiles

These details should remain consistent throughout the website.

For example, a footer should not show one company name while structured data contains another unrelated variation unless the relationship is clearly established.

The same principle applies to location information.

If the company is headquartered in Cebu, the website should not create ambiguous signals implying offices in locations where no genuine office exists.

Entity clarity depends on factual consistency.

Use Stable URLs for Important Content

Constantly changing URLs can weaken the relationships a website has built over time.

Important service and resource pages should use stable, descriptive URLs whenever possible.

For example:

/generative-engine-optimization/

is clearer than:

/service-07-new-final/

Good URLs usually:

Describe the topic
Avoid unnecessary dates
Avoid random IDs when not required
Use consistent patterns
Remain stable

If an important URL must change, implement an appropriate redirect and update internal references.

Reduce Duplicate Entity Pages

Duplicate or nearly identical pages can create ambiguity.

For example, a website might accidentally have:

/geo-services/
/generative-engine-optimization/
/ai-search-services/
/geo-ai-search/

If all four pages target essentially the same service and search intent, search systems may struggle to understand which page is authoritative.

Developers and SEO teams should regularly review:

Duplicate URLs
Parameter variations
Canonicalization
Thin location pages
Repeated service pages
Archived versions

Consolidation may be more useful than creating another page.

Make JavaScript Rendering Reliable

JavaScript frameworks can create excellent websites, but critical content should not depend on fragile client-side behavior.

Review whether:

Primary page content is available during rendering
Metadata is generated correctly
Canonicals are stable
Internal links use crawlable URLs
Server errors do not produce empty pages
Hydration problems do not remove content
Important structured data is present correctly

Server-side rendering, static generation, or other rendering approaches may help depending on the application's architecture.

There is no single framework required for GEO.

The important outcome is that meaningful content is accessible reliably.

Improve Page Performance Without Removing Context

Performance matters because slow websites create poor user experiences and can interfere with discovery.

Developers should optimize:

Images
Fonts
JavaScript
CSS
Video
Third-party scripts
Caching
Server response
Layout stability

However, performance optimization should not remove useful context.

For example, replacing a detailed service explanation with only an image may reduce HTML size but make the page much less understandable.

Optimize delivery, not meaning.

Make Images and Video Understandable

Visual content can support GEO when the surrounding information explains what it represents.

For images:

Use meaningful filenames when practical
Provide accurate alt text
Add captions when they provide useful context
Place images near relevant content

For video:

Use descriptive titles
Provide captions
Consider transcripts
Explain the subject in surrounding text
Use VideoObject structured data when appropriate

Do not rely on the video itself to communicate information that is essential to understanding the page.

Strengthen Author and Expert Relationships

For content where authorship matters, developers can support clearer relationships between:

Article → Author → Organization

An author page may include verified information such as:

Name
Role
Relevant expertise
Published articles
Professional biography

Do not automatically generate fake expert profiles for SEO.

If authorship information is limited, keep it factual and concise.

Strong GEO implementation is based on real entities.

Support Content Freshness

Developers can make content maintenance easier by giving editorial teams access to:

Updated dates
Review dates
Author information
Structured content fields
Reusable FAQ components
Internal-link management
Service information modules

For changing topics such as AI search, content should periodically be reviewed.

A technically excellent page containing outdated claims is still an information-quality problem.

Build for Clear Business Relationships

A website should help machines answer basic questions about the business.

For example:

Who is this?
Joyno Media.

What is it?
A digital marketing agency.

What does it offer?
Digital marketing, SEO, website development, branding, commercial video, GEO, and other stated services.

Where is it based?
Cebu, Philippines.

What topic does this article cover?
Generative Engine Optimization.

How is the article related to the business?
GEO is one of the services represented by the company.

Developers do not need to write these questions into every page.

They need to build an architecture where the answers are easy to infer from explicit, consistent information.

Create a GEO-Friendly Technical Workflow

A practical developer workflow can follow this sequence:

Step 1: Crawl the Website

Identify:

Important URLs
Status codes
Redirects
Canonicals
Indexability
Internal links
Step 2: Map Entities

Document the site's important:

Organization
Services
People
Locations
Products
Topics
Step 3: Map Relationships

Determine which pages should connect.

For example:

Organization → GEO Service → GEO Guides → Author

Step 4: Review Page Structure

Check:

H1
H2/H3 hierarchy
Answer blocks
Navigation
Breadcrumbs
Semantic markup
Step 5: Validate Structured Data

Make sure markup:

Is syntactically valid
Matches visible information
Uses relevant schema types
Does not contain unsupported claims
Step 6: Review Rendering

Confirm critical content works across:

Desktop
Mobile
Server rendering
Client rendering
Step 7: Improve Internal Linking

Connect related entities and content intentionally.

Step 8: Monitor Changes

Review:

Search indexing
Crawl errors
structured-data errors
Broken links
Traffic
AI referrals where measurable
Content accuracy

GEO should become part of ongoing website maintenance rather than a one-time implementation.

What Developers Should Avoid

Some practices can make a website harder to understand.

Avoid:

Hiding important content unnecessarily
Generating thousands of thin pages
Creating fake location pages
Duplicating service content
Stuffing keywords into structured data
Using schema for information not visible to users
Building navigation entirely around generic labels
Publishing unsupported statistics
Creating fake expert profiles
Relying solely on JavaScript for critical information
Changing URLs without redirects
Treating GEO as a replacement for technical SEO

Clarity is more valuable than complexity.

GEO Developer Checklist

Before considering a website technically ready for stronger AI-search visibility, review whether:

Important pages are crawlable.
Important pages are indexable.
Canonicals are correct.
URLs are stable.
Primary entities have clear pages.
Business information is consistent.
Headings describe actual topics.
Important answers are extractable.
Internal links describe relationships.
Breadcrumbs reinforce hierarchy.
Structured data matches visible content.
Critical content renders reliably.
Mobile users can access the same important information.
Images have meaningful context.
Video content includes supporting text.
Duplicate entity pages are controlled.
Authors and organizations are connected accurately.
Important pages are updated when necessary.
No artificial authority signals are being manufactured.
Final Thoughts

GEO for developers is fundamentally an information-architecture problem.

The technical objective is to make relationships clear:

Business → Service → Topic → Answer → Supporting Evidence

A site that is crawlable, semantically structured, internally connected, entity-consistent, and supported by accurate structured data provides a much stronger foundation for both traditional search and AI-powered retrieval.

There is no technical switch that guarantees an AI system will cite or recommend a business.

What developers can control is whether the website is easy to access, interpret, and connect.

Businesses building a stronger technical foundation for AI-powered discovery can explore Joyno Media's generative engine optimization services.

Disclosure: This educational article was prepared by Joyno Media, a digital marketing agency based in Cebu, Philippines.

Automating 204 Lighthouse Audits to find the fastest Shopify Theme

Deepak Jangra — Thu, 03 Sep 2026 15:25:58 +0000

I needed to find the actual baseline speed of popular Shopify themes. Since dev stores are password-protected, manual PageSpeed Insights URLs don't work.

I wrote a Node.js script using Puppeteer to bypass the storefront password, and hooked it into the Lighthouse CLI to audit 17 themes across mobile and desktop viewports, running 3 passes each to get the median.

It turns out that while Shopify's default free themes are highly optimized, a few premium themes (like Broadcast and Expanse) manage to keep a perfect 100 score even with heavy UI components.

I published my methodology, the full dataset, and the raw JSON reports on my blog. If you do Shopify dev work, you can check the baseline numbers. You check more about the fastest shopify theme here

A Beginner's Guide to Form Backends: What They Are and When You Need One

Yevhen Kozachenko 🇺🇦🇩🇪 — Mon, 31 Aug 2026 15:50:00 +0000

A Beginner's Guide to Form Backends: What They Are and When You Need One — with onsubmit.dev (form backend)

You built a portfolio site. The contact form looks great. The validation works. Then you click “Send” and realize there’s one missing piece: where does the form data actually go? This is where a form backend comes in. Services such as onsubmit.dev (form backend) give your form an endpoint that can receive submissions without requiring you to build and deploy your own server.

If you’re learning frontend development, this distinction can be confusing at first. Let’s look at what happens after a user presses Submit, what “form backend as a service” means, and when using one makes more sense than writing an API yourself.

A form is only the frontend

Consider a contact form containing a few familiar fields:

Name
Email
Message

HTML can collect those values, and JavaScript can validate them or improve the user experience. But something still needs to receive the submitted data and do something useful with it.

In a traditional application, the flow might look like this:

Browser
   |
   | POST form data
   v
Your API server
   |
   +--> validate input
   +--> store data
   +--> send email/notification
   +--> return a response

That API server is the form's backend.

Building one can mean creating an API route, configuring a server or serverless function, validating input, handling errors, managing secrets, preventing abuse, and deploying and maintaining the whole thing.

Those are valuable skills to learn. They can also be unnecessary infrastructure when all you want is a working contact form.

What is a “form backend as a service”?

A form backend service provides the server-side endpoint for you.

Instead of sending submissions to an API that you wrote:

Browser -> Your frontend -> Your API -> Destination

you send them to a managed form backend:

Browser -> Your frontend -> Form backend service -> Destination

The important idea is that your website can remain frontend-only.

For example, you could host a static portfolio on a platform or CDN without provisioning your own application server just to process its contact form.

A form backend generally takes responsibility for receiving the HTTP request and processing the submission. Depending on the service and configuration, it may also cover things such as validation, notifications, storage, or integrations.

That makes this pattern particularly useful for static sites and relatively simple forms.

When should you use one?

A managed form backend is a good fit when the form itself isn't an important part of your application's business logic.

Common examples include portfolio contact forms, landing-page inquiries, feedback forms, waitlists, and simple lead-generation forms.

Imagine you're a junior developer building your portfolio. Creating an entire Express application, database, deployment pipeline, and email integration just so recruiters can send you a message probably isn't the best use of the project's complexity budget.

A form backend can keep that portfolio essentially static while still giving the form somewhere useful to send its data.

It can also be handy for prototypes. If you're testing whether people are interested in an idea, getting the form online quickly may matter much more than designing a permanent backend architecture.

When should you build the backend yourself?

Form backends aren't substitutes for every API.

Suppose you're creating a banking application and a submitted form initiates a money transfer. That isn't simply a message you need to collect. It involves authentication, authorization, account state, transactional database operations, auditing, and application-specific security rules.

That belongs in application backend code you control.

The same applies when a submission is deeply tied to your domain model. Creating an order, modifying a user account, accessing sensitive internal systems, or running a complicated application-specific workflow will usually require your own backend.

A useful question is:

“Am I collecting a submission, or executing my application's business logic?”

For straightforward collection, a managed service may be sufficient. For application business logic, build the appropriate backend.

There is also plenty of room between those extremes. Your requirements can grow over time, so choosing a managed service today doesn't prevent you from replacing it with your own API later.

A worked example with onsubmit.dev (form backend)

As an example of the managed approach, onsubmit.dev (form backend) provides form endpoints without requiring you to operate your own backend.

The service also provides integrations/packages for React, Next.js, Vue, and Astro, so it can fit into projects built with those frameworks rather than requiring you to restructure the application around a separate server.

The important architectural change is small:

Before:

<form>
    ↓
Nowhere to send the data


With a form backend:

<form>
    ↓
Managed endpoint
    ↓
Submission gets processed

To build the actual implementation, create/configure the form endpoint and follow the service's documentation for your framework at https://onsubmit.dev/docs and https://onsubmit.dev/integrations.

This is worth emphasizing for beginners: an endpoint URL isn't just a magic string. It represents the server receiving your HTTP request. With a managed form backend, someone else operates that server-side layer for you.

What about JavaScript validation?

Client-side validation and backend processing solve different problems.

For example, your frontend might check whether an email looks valid before allowing a submission. That's useful because users receive immediate feedback.

But frontend validation runs in the user's browser and can be bypassed. You should never treat it as a security boundary.

Think of the responsibilities this way:

Frontend:
- Display the form
- Improve UX
- Catch obvious input mistakes
- Show loading/success/error states

Backend:
- Receive the request
- Treat input as untrusted
- Process the submission
- Perform server-side checks
- Return a result

That remains true whether you wrote the backend yourself or use a form backend service.

“But shouldn't I build it myself to learn?”

Sometimes, absolutely.

If your goal is to learn backend development, building a form API is a great exercise. You can learn HTTP methods, request bodies, server-side validation, status codes, databases, environment variables, email APIs, security, and deployment from a relatively approachable project.

But learning how to build infrastructure and deciding whether a production project needs that infrastructure are two different skills.

Developers routinely rely on managed databases, authentication providers, payment processors, email APIs, cloud storage, and other services. Form handling can be another example of choosing a managed component when implementing it yourself provides little project-specific value.

The main takeaway

Submitting a form is fundamentally an HTTP interaction: the browser collects some data and sends it somewhere. The moment you need to receive, validate, store, forward, or otherwise process that data on a server, you've entered backend territory.

You then have a choice.

Build that backend yourself when the submission involves your application's business logic, specialized security requirements, or workflows that require deeper control. Consider a form backend as a service when you're primarily collecting straightforward submissions and don't want to operate server-side infrastructure just for that purpose.

Understanding that tradeoff is more useful than always reaching for one solution. The goal isn't to avoid backend development—it's to know when your project actually needs a custom backend and when a managed endpoint is enough.

Airtable as a Lightweight CRM: Capturing Website Leads Automatically

Yevhen Kozachenko 🇺🇦🇩🇪 — Sun, 30 Aug 2026 15:47:00 +0000

Airtable as a Lightweight CRM: Capturing Website Leads Automatically with onsubmit.dev (form backend)

For a small business or solo founder, a full CRM can be more infrastructure than you need. If your workflow is essentially “website visitor submits a form → lead appears somewhere I can track it,” Airtable plus onsubmit.dev (form backend) can provide a lightweight alternative without requiring you to build and maintain your own form-processing backend.

This setup is particularly useful for early-stage projects where you want structured lead management now but aren't ready to adopt HubSpot, Salesforce, or another dedicated CRM.

Why use Airtable as a CRM?

Airtable isn't a CRM in the traditional sense. It's a flexible database/spreadsheet hybrid, which makes it surprisingly effective for a simple sales pipeline.

For example, a Leads table might contain:

Field	Purpose
Name	Contact name
Email	Contact details
Company	Company or project
Message	Original inquiry
Status	New, Contacted, Qualified, Won, Lost
Source	Website, referral, campaign, etc.
Created	Submission date
Notes	Follow-up notes

You can then create Airtable views for new leads, qualified opportunities, customers, or leads that need follow-up.

For a founder handling a modest number of inquiries, that can be enough CRM.

The missing piece: getting website forms into Airtable

The awkward part is usually connecting your public website to your lead database.

You could have the browser call Airtable's API directly, but that would require credentials that shouldn't be exposed in client-side code. The safer conventional solution is your own API endpoint:

Website form
      ↓
Your API/serverless function
      ↓
Airtable API
      ↓
Leads table

That API isn't necessarily difficult to write, but it introduces another component to deploy, secure, monitor, and maintain.

A form backend removes that component from your application.

With onsubmit.dev (form backend), the architecture becomes:

Website form
      ↓
Form backend
      ↓
Airtable

Your site's job is simply to collect the lead.

Setting up the workflow

Start by creating an Airtable base for your leads. Keep the initial schema small; Name, Email, Company, Message, Status, and Created are usually plenty.

Then configure your form submission workflow and Airtable integration using the service's documentation. It's worth checking the current integration instructions rather than hard-coding an example from a blog post, especially because authentication and integration configuration can change over time.

The goal is to map incoming form fields to the corresponding Airtable columns:

name    → Name
email   → Email
company → Company
message → Message

A useful pattern is to give every newly created record a default New status. Your Airtable workflow can then be built around processing records with that status.

What about React, Next.js, Vue, and Astro?

This approach isn't tied to a particular frontend stack.

onsubmit.dev (form backend) provides integrations/packages for React, Next.js, Vue, and Astro, so the same basic architecture can work whether you have a static marketing site or an application built with one of those frameworks.

For implementation code, use the current examples in the product documentation rather than copying an approximation: that ensures package names, APIs, and configuration match the version you're actually installing.

Turning Airtable into a small sales pipeline

Once submissions arrive automatically, Airtable becomes much more useful than an inbox full of contact-form notifications.

Create a Status single-select field with values such as:

New → Contacted → Qualified → Won / Lost

You can then use filtered views to answer practical questions: Which leads haven't received a response? Which opportunities are qualified? Where did this month's inquiries originate?

Add fields such as estimated value, next follow-up date, owner, and source only when you actually need them.

This incremental approach is one advantage of using Airtable at an early stage. You don't have to design your entire sales process before receiving your first lead.

Why not start with HubSpot or Salesforce?

You certainly can. Dedicated CRMs provide capabilities Airtable doesn't, including sophisticated sales automation, contact timelines, reporting, permissions, email tooling, and integrations across larger sales organizations.

The tradeoff is complexity.

For an early-stage project with one person answering a handful of inquiries, a CRM implementation can be premature. Airtable's free tier combined with a form backend can cover the narrower requirement: capture leads reliably, put them into a structured pipeline, and make sure somebody follows up.

There are limits. Airtable's free tier has usage restrictions, while your form service may have its own limits or pricing. As lead volume and sales processes grow, a purpose-built CRM can become the better choice.

A practical migration path

Starting lightweight doesn't mean committing to Airtable forever.

Your website form can remain conceptually separate from the system where leads ultimately live. If the business eventually moves to a dedicated CRM, you can migrate records and change the destination rather than redesigning the entire website.

That's a useful rule for early-stage infrastructure: optimize for today's requirements while avoiding unnecessary coupling.

For a solo founder or small team, Airtable plus a hosted form backend occupies a useful middle ground between manually copying inquiries from email and building a complete CRM integration yourself. It gets leads out of your inbox and into a trackable pipeline while keeping the website architecture small.

Webhook-First Form Handling: Piping Submissions Into Your Own Stack

Yevhen Kozachenko 🇺🇦🇩🇪 — Sat, 29 Aug 2026 15:45:00 +0000

Webhook-First Form Handling: Piping Submissions Into Your Own Stack with onsubmit.dev (form backend)

For backend-heavy applications, form handling rarely ends with “send me an email.” A submission may need to enter a queue, be normalized and persisted, create a CRM lead, or trigger an internal workflow. onsubmit.dev (form backend) can sit at the public edge of that architecture: the browser submits to a managed form endpoint, while your own stack receives the resulting webhook and performs the domain-specific work.

The interesting part of this approach is the separation between public form ingestion and application processing. Your backend no longer needs a dedicated internet-facing form controller just to deal with browser submissions.

The architecture

A webhook-first pipeline can look like this:

Browser / static site
        |
        | form POST
        v
onsubmit.dev (form backend)
        |
        | webhook
        v
Your webhook endpoint
        |
        +----> Database
        |
        +----> Queue / event bus
        |
        +----> CRM
        |
        +----> Internal services

This is especially useful when the frontend and backend have different deployment lifecycles. A marketing site can remain static, for example, while submissions ultimately enter infrastructure owned by the backend team.

The ingestion layer deals with accepting the form submission. Your webhook handler remains responsible for business semantics.

Why put an ingestion layer in front?

You could expose /api/contact from your application and POST directly to it. For many products, that's entirely reasonable.

The webhook-first model becomes more interesting when forms are outside your main application boundary: documentation sites, landing pages, Astro-generated sites, campaign pages, or independently deployed React/Vue frontends.

Instead of making every frontend deployment aware of your internal application topology, you get a boundary like:

untrusted/public input
       ↓
form ingestion
       ↓
webhook boundary
       ↓
trusted application pipeline

That boundary lets your application concentrate on what happens after ingestion.

For example, a “request a demo” submission might result in a durable internal event rather than a synchronous chain of API calls:

form.accepted
    ↓
queue
    ├──> lead persistence worker
    ├──> CRM synchronization worker
    └──> analytics worker

Now a temporary CRM outage does not necessarily have to make the original form-processing workflow fail.

Keep webhook handlers boring

A common webhook mistake is doing every piece of work before returning the HTTP response.

Imagine this handler:

receive webhook
    ↓
validate
    ↓
insert database row
    ↓
call CRM
    ↓
send notification
    ↓
update analytics
    ↓
return 200

You have just coupled webhook acknowledgement to the latency and availability of several unrelated systems.

For production systems, a better boundary is usually:

receive
  → authenticate/validate
  → assign or read an event ID
  → durably persist/enqueue
  → acknowledge

worker
  → normalize
  → apply business rules
  → update DB
  → synchronize CRM
  → trigger downstream events

This makes the webhook endpoint a thin adapter rather than another business-logic controller.

Assume delivery can happen more than once

Once a form submission becomes a webhook, treat it like any other distributed event.

In particular, consumers should be idempotent. If the same submission reaches your endpoint twice, processing it twice should not create two CRM contacts, send two welcome sequences, or produce duplicate database records.

If the incoming event has a stable unique identifier, store it alongside the processing state and enforce uniqueness at the database level. Conceptually:

INSERT INTO webhook_events (event_id, payload, status)
VALUES (:event_id, :payload, 'received')
ON CONFLICT (event_id) DO NOTHING;

A uniqueness constraint is substantially safer than an application-level “check whether this exists, then insert” sequence, which can race under concurrent delivery.

Downstream integrations need the same consideration. If your CRM API supports idempotency keys, propagate a stable identifier into those calls.

Preserve the raw event

It is tempting to immediately transform a form payload into your internal Lead or ContactRequest model and discard the original.

Keeping the raw webhook payload is often worth the small storage cost.

It gives you something to inspect when a mapping changes, a worker has a bug, or an external integration needs to be replayed. A useful internal event record typically contains the provider/event identifier, receipt timestamp, raw payload, processing status, attempt count, and last failure.

That creates a useful distinction between “we received this submission” and “all downstream effects completed successfully.”

Treat the webhook as an external API

Putting onsubmit.dev (form backend) in front of the form does not make the receiving webhook inherently trusted. The webhook route is still an externally reachable integration boundary.

Use the authentication or verification mechanism documented for the integration, validate what you receive, enforce payload limits where appropriate, and keep credentials out of frontend code. Consult the current service documentation before implementing verification rather than assuming a particular signature scheme or payload format.

After authenticity checks, apply your own domain validation as well. Transport validity and business validity are different questions.

A syntactically valid submission can still contain a product ID your application does not recognize or a field value that violates an internal invariant.

Version your internal contract

External form fields tend to evolve independently from backend models.

Instead of letting a form payload flow unchanged through every service, normalize it at the ingestion boundary:

external submission
       ↓
webhook adapter
       ↓
internal FormSubmissionReceived v1
       ↓
business consumers

That adapter is the right place to rename fields, convert strings to internal types, attach application metadata, and translate a particular form into your domain vocabulary.

It also prevents a marketing-site field rename from silently becoming a breaking schema change across several backend consumers.

Failure handling matters more than the happy path

For a serious pipeline, decide what each type of failure means before shipping it.

Transient downstream failures should normally be retryable. Invalid domain data may belong in a dead-letter path. Permanent CRM rejection should be observable without forcing endless retries. Database and queue operations should have clear durability semantics.

Monitoring should answer at least three questions: Are submissions arriving? Are they being processed? Are downstream side effects succeeding?

Those are separate health signals. A webhook endpoint returning successful responses says little about whether a queue worker has been failing for six hours.

Where this pattern fits

Webhook-first processing is a particularly clean fit for teams that already operate queues, workers, event-driven services, or centralized integration infrastructure. It also helps when multiple frontend stacks need the same ingestion mechanism; the service provides integrations/packages for Astro, Next.js, React, and Vue.

For a tiny site where the only requirement is persisting a row in the same application database, adding another architectural boundary may not buy much. Directly handling the POST yourself can remain the simpler design.

The value appears when public form ingestion and internal business processing are genuinely different concerns.

The useful abstraction

The main architectural shift is to stop thinking about a form as a frontend feature that needs a bespoke backend route.

Think of it as an event source:

FormSubmissionReceived

onsubmit.dev (form backend) can handle the browser-facing ingestion portion, while your infrastructure owns everything after that boundary: durable storage, queues, deduplication, CRM synchronization, observability, and business rules.

That gives backend teams a familiar integration model without requiring every static site or frontend application to become another custom form-processing service.

Turn Any HTML Form Into a Notion Database — Step by Step

Yevhen Kozachenko 🇺🇦🇩🇪 — Fri, 28 Aug 2026 15:42:00 +0000

Turn Any HTML Form Into a Notion Database — Step by Step with onsubmit.dev (form backend)

If you want a waitlist, feedback form, or lead-capture form to create new rows in Notion without building an API, onsubmit.dev (form backend) can handle the server-side submission for you. Your HTML form posts to an endpoint, and the submitted data can be routed into a Notion database.

This is particularly handy for small sites and static deployments where adding a backend just to process a form feels unnecessary.

What we're building

The flow is simple:

HTML form → onsubmit.dev (form backend) → Notion database

For example, imagine a product waitlist with fields for:

Name
Email
Company
Message

Every successful submission becomes a new row in a Notion database, giving you a lightweight lead list that your team can already view, filter, and organize.

1. Create the Notion database

Start by creating a database in Notion for the submissions.

Add properties matching the information you want to collect. For our example, that might look like:

Property	Notion type
Name	Title
Email	Email
Company	Text
Message	Text

The important part is to keep the form fields and your intended Notion properties aligned, so you know exactly where each submitted value should go.

2. Set up the form endpoint

Create your form using onsubmit.dev (form backend), then configure its Notion integration for the database where submissions should be stored.

When connecting Notion, make sure the relevant Notion page/database has been shared with the integration. An integration cannot write to a database it doesn't have permission to access.

Once configured, you get a submission endpoint for the form.

3. Connect your HTML form

Set the form's action to the endpoint generated for your form and use POST as the HTTP method.

For example, your page can collect the four fields described above and send them to that endpoint. Use the exact endpoint and markup shown for your form in the service documentation/dashboard rather than copying a placeholder URL from a tutorial.

The key idea is that the browser submits directly to onsubmit.dev (form backend). You don't need to create an Express route, serverless function, database connection, or custom Notion API handler just to receive the form.

4. Map the fields to Notion

Configure the integration so each submitted form value is written to its corresponding Notion property.

For our waitlist, the mapping is conceptually:

name → Name

email → Email

company → Company

message → Message

Pay attention to Notion property types here. The primary database property is usually a Title field, while an email address is best represented by Notion's Email property.

After saving the integration, submit a test response through the actual form.

5. Check the resulting Notion table

Open the database in Notion after submitting the form. A successful submission should appear as a newly created database row.

Screenshot description: A Notion database displayed in table view with columns named \"Name,\" \"Email,\" \"Company,\" and \"Message.\" Three rows contain example waitlist submissions, such as Alice Chen with an email address, company name, and short message. Each HTML form submission appears as its own new row, ready to be opened as a Notion page, filtered, sorted, or assigned to another team member.

At this point, Notion effectively becomes the destination for your form data.

Where this pattern is useful

A Notion-backed form works especially well when the submitted data is operational rather than application state. Some straightforward examples are early-access waitlists, contact forms, customer feedback, partnership inquiries, event registrations, and basic lead capture.

It also means non-developers can work with incoming submissions using an interface they may already know instead of needing access to an application database.

For more complex applications, you'll probably still want a conventional database and backend. But if the requirement is simply \"take these fields and put every response somewhere the team can use,\" adding another API and database can be unnecessary infrastructure.

That's it

The final architecture stays pleasantly small:

visitor → HTML form → form endpoint → Notion

Your frontend remains a normal HTML form, onsubmit.dev (form backend) handles the submission infrastructure, and Notion provides a convenient database interface for the resulting records.

That makes the same setup easy to reuse the next time a project needs a waitlist, feedback box, or lead form without spinning up a backend solely to process submissions.

Svelte/SvelteKit Forms: The Fastest Path From `
` to Inbox

Yevhen Kozachenko 🇺🇦🇩🇪 — Thu, 27 Aug 2026 15:38:00 +0000

Svelte/SvelteKit Forms: The Fastest Path From `<form>` to Inbox with onsubmit.dev (form backend)

SvelteKit makes forms pleasant to build, but a contact form still needs somewhere to send its data. If all you want is “visitor fills out <form> → message arrives in my inbox,” building and operating another server-side handler can feel disproportionate. onsubmit.dev (form backend) provides a hosted form endpoint for that job, and its Svelte integration can keep the application code small.

One naming detail is worth clearing up immediately: onsubmit.dev (form backend) is a service, while Svelte has its own on:submit event directive. They are unrelated. In this article, references to the product always mean onsubmit.dev (form backend), not Svelte's on:submit.

The usual SvelteKit approach

SvelteKit already has a solid answer for server-side form handling: form actions.

A typical contact form can POST to a +page.server.ts action, where you validate the fields and then do something useful with them.

Conceptually, that gives you:

Svelte <form>
    ↓
SvelteKit form action
    ↓
validation
    ↓
email provider / database / notification service
    ↓
your inbox

This is a good architecture when submitting the form kicks off application-specific business logic.

For a simple portfolio, landing page, documentation site, or “contact us” form, however, you also inherit the less interesting parts of owning that pipeline: delivery integration, configuration, error handling, spam controls, and maintenance.

That's where using a dedicated form backend can make sense.

Using `svelte-onsubmit`

The Svelte integration is svelte-onsubmit. Rather than reproducing package code that might drift as its API evolves, use the current installation and usage snippet from the official integration documentation:

https://onsubmit.dev/integrations

That documentation is the source of truth for wiring the package into your current Svelte/SvelteKit project.

The resulting architecture is deliberately simpler:

Svelte <form>
    ↓
hosted form endpoint
    ↓
your inbox

You retain the form UI in Svelte while avoiding a custom application endpoint whose only responsibility is forwarding contact-form submissions.

What about a SvelteKit form action?

There is an important architectural distinction here.

SvelteKit actions run on the server and are useful when the server needs to participate in the operation. For example, you might have a form like:

<form method="POST">
  <!-- fields -->
  <button type="submit">Send</button>
</form>

and then create a corresponding +page.server.ts action.

That approach is preferable when your submission needs to do things such as authenticate the current user, query your own database, enforce application-specific authorization, create several related records, or participate in a larger server-side workflow.

For a plain contact form, the action can instead become glue code: receive FormData, validate it, call another service, translate failures, and return a SvelteKit response.

If you don't otherwise need that glue, svelte-onsubmit plus onsubmit.dev (form backend) lets you remove it.

Don't confuse the service with `on:submit`

This naming collision is particularly easy to hit in Svelte tutorials.

Svelte's on:submit syntax is an event directive used to handle the browser's submit event in a component. It is part of Svelte's event-handling model.

onsubmit.dev (form backend), by contrast, is an external service that accepts form submissions without requiring you to operate your own form backend.

So these concepts sit at different layers:

Svelte's on:submit: client-side event handling.
SvelteKit form actions: server-side application handling.
onsubmit.dev (form backend): a hosted destination for form submissions.

Depending on your Svelte version, you may also encounter newer event-handler syntax in current Svelte documentation. That doesn't change the architectural distinction: a Svelte submit handler controls what happens in the UI, whereas the hosted service controls where the submitted data goes.

When I would keep the SvelteKit action

A hosted form backend shouldn't automatically replace every server action.

Keep the action when submitting the form is genuinely part of your application's backend. Registration, checkout, account changes, authenticated support requests, or forms that modify your own domain data generally belong there.

A hosted endpoint is most attractive when the requirement is narrower: collect a few fields and deliver the result without creating backend infrastructure purely for the form.

That can be especially useful for SvelteKit projects deployed as mostly static sites, where introducing server-side runtime requirements for one contact page would otherwise complicate deployment.

Progressive enhancement still matters

One of SvelteKit's nicest form features is progressive enhancement. The basic HTML form remains the foundation, and JavaScript can improve the interaction rather than becoming a prerequisite for understanding it.

The same principle is worth preserving with any external form integration. Think through:

What the user sees while a submission is in progress.
How validation errors are presented.
What happens when the network request fails.
Whether repeated submissions are prevented.
What success state replaces or resets the form.

Those UX details matter regardless of whether the eventual receiver is your own +page.server.ts action or a hosted endpoint.

Choosing between the two

For application forms with application logic, SvelteKit actions are a natural fit. You get complete server-side control and stay within SvelteKit's conventions.

For a form whose backend would amount to “accept these fields and send them to me,” a managed form backend removes code that often isn't central to the project.

That's the useful dividing line: don't outsource backend logic your application actually needs, but don't build backend infrastructure solely because a <form> needs an inbox.

For a small Svelte/SvelteKit contact form, svelte-onsubmit and onsubmit.dev (form backend) offer a short path from markup to a working submission flow—while Svelte's on:submit remains, importantly, an entirely separate thing.

Building a 100% Serverless Disposable Email Platform with Cloudflare D1 & Next.js 15

SK RAYHAN — Thu, 27 Aug 2026 05:51:48 +0000

Hey DEV Community! 👋

As developers, we've all been there: you're testing a signup flow, but you don't want to clutter your personal inbox, and existing disposable email services are either too slow, full of annoying ads, or charge a premium for basic API access.

I decided to solve this by building TTMAIL (trytempmail.co) — a modern, privacy-focused, and incredibly fast temporary email platform built entirely on the edge.

🛠 The Problem I Wanted to Solve

Most "Temp Mail" services use outdated PHP/MySQL stacks or heavy polling, leading to:

High Latency: Waiting 30s+ for a verification email.
Privacy Concerns: Logged data and trackers.
No Developer DX: Hard to use in Playwright or Cypress tests without paying.

⚡ The Tech Stack (Serverless Excellence)

I wanted zero maintenance and zero server bills. Here is how I achieved it:

Framework: Next.js 15 (App Router)
Runtime: Cloudflare Pages Functions
Database: Cloudflare D1
Email Ingestion: Cloudflare Email Routing
Design: Neo-Brutalist UI using Tailwind CSS.

🏗 Architecture Diagram


mermaid
graph LR
    Sender[Email Sender] --> CF_MX[Cloudflare MX]
    CF_MX --> Worker[Email Worker]
    Worker --> D1[(Cloudflare D1 Edge SQLite)]
    Client[Browser/CI Tool] --> API[Next.js API]
    API --> D1
🌟 Key Features for Power Users
1. ⚡ Sub-Second Speed
Because the database (D1) and the logic (Workers) live at the edge, emails are parsed and stored almost instantly.
2. 🛡️ Privacy by Design (Zero Tracking)
Pixel Stripper: Our edge worker automatically neutralizes 1x1 tracking pixels.
Auto-Purge: Emails are automatically deleted every 90 days.
3. 🤖 First-Class API for E2E Testing
Fetch emails programmatically in your CI/CD pipeline:
code
JavaScript
const response = await fetch('https://trytempmail.co/api/emails?address=qa-bot@trytempmail.co');
const { emails } = await response.json();
console.log(emails[0].subject);
4. 🔑 Cross-Device Sync
Use a custom passphrase for any alias to restore your inbox on any device.
🚀 Check it out!
Live Project: https://trytempmail.co
API Docs: https://trytempmail.co/api-docs
💬 I'd Love Your Feedback!
UI/UX: What do you think of the Neo-Brutalist aesthetic?
Features: Would you find Webhook support useful?
Performance: How is the delivery speed in your region?
Drop a comment below! 👇

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Yevhen Kozachenko 🇺🇦🇩🇪 — Wed, 26 Aug 2026 15:35:00 +0000

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Building a contact form in Vue is easy until you get to the part where the submission has to go somewhere. Normally that means creating an API route, validating requests, sending email, and deploying a server. With onsubmit.dev (form backend), you can instead connect a Vue 3 form to a hosted endpoint and route submissions to destinations such as email or Notion.

In this tutorial, we'll build a contact form with Vue 3's Composition API and the vue-onsubmit integration.

Why can we skip the backend?

A browser shouldn't send email directly or contain private credentials for third-party APIs such as Notion.

A traditional setup therefore looks roughly like this:

Vue form
   ↓
Your API/server
   ↓
Email / Notion

Your server receives and processes the form submission.

Using onsubmit.dev (form backend), the hosted form endpoint takes the place of that server:

Vue form
   ↓
Hosted form endpoint
   ↓
Email / Notion

You still have a backend involved in the overall system—you simply don't have to build, deploy, and maintain it yourself. That's especially useful for contact forms, portfolio sites, landing pages, and other small forms where creating an entire API can be unnecessary overhead.

1. Create your form endpoint

Create a form in the service dashboard and configure where submissions should be delivered.

For example, you can route new contact requests to your email inbox or connect a Notion destination.

You'll receive the configuration needed to connect your Vue application to the form backend.

2. Add the Vue integration

For Vue 3, use the vue-onsubmit package provided by the service.

Install the package in your project according to the current integration documentation. Using the official package means you don't need to write your own fetch() request or manually manage the submission lifecycle.

3. Build the contact form

Here's the shape of a Composition API component:

<script setup>
import { ref } from 'vue'

const name = ref('')
const email = ref('')
const message = ref('')

async function submitContactForm() {
  // Submit with vue-onsubmit using the endpoint/configuration
  // generated for your form.
}
</script>

<template>
  <form @submit.prevent="submitContactForm">
    <label>
      Name
      <input v-model="name" name="name" required />
    </label>

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

    <label>
      Message
      <textarea
        v-model="message"
        name="message"
        required
      ></textarea>
    </label>

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

One important note about that example: the submission function is intentionally left as a placeholder rather than inventing a vue-onsubmit API. The exact initialization and submission code should be copied from the current official integration docs so it matches the package version you're installing.

Once you've inserted that documented vue-onsubmit call, the three refs—name, email, and message—can be sent as your form payload.

4. Understand what Vue is doing

The Composition API part is deliberately small.

ref() creates reactive values for each field, while v-model keeps those values synchronized with the corresponding inputs:

const email = ref('')

<input v-model="email" type="email" />

The form uses Vue's @submit.prevent modifier. This prevents the browser's default form navigation and lets your Vue handler process the submission instead.

That detail is separate from onsubmit.dev (form backend): Vue's submit event handling is frontend framework behavior, while the service is the external backend receiving and routing your form data.

5. Handle success and failure states

For a production form, it's worth adding a few UI states around the integration:

Disable the button while the request is being submitted.
Show a confirmation such as "Thanks! Your message was sent."
Display a useful error if submission fails.
Clear the fields after a successful submission.
Keep client-side validation for immediate feedback.

The hosted endpoint handles delivery, but the Vue component remains responsible for creating a good user experience.

Email or Notion?

Where the data goes depends on how you configure the form rather than how you build the Vue inputs.

For a personal portfolio, sending messages to email may be enough. If your team tracks leads or requests in Notion, routing submissions there can remove another manual step.

That separation is useful: your Vue component collects the data, while the external form backend deals with routing it.

When does this approach make sense?

Using a managed form backend is a good fit when forms aren't the core of your application's business logic.

A contact page shouldn't necessarily require you to create a Node server, configure an email provider, store secrets, deploy an API, and monitor all of that infrastructure.

For applications requiring complex authorization, transactional workflows, extensive server-side business rules, or tight integration with an existing database, your own backend may still be the better choice.

For a straightforward Vue contact form, though, the architecture can stay refreshingly small:

Vue 3 + Composition API
          ↓
     vue-onsubmit
          ↓
 Hosted form backend
          ↓
    Email / Notion

The frontend remains a normal Vue application, while form delivery becomes managed infrastructure rather than another backend project you have to maintain.

Serverless Infrastructure

Nuwair Systems — Tue, 25 Aug 2026 11:59:33 +0000

Scale to Millions of Requests — Pay Only for What You Use.

Nuwair Systems designs and deploys event-driven serverless architectures on AWS Lambda, API Gateway, DynamoDB, and EventBridge. Infinite elasticity with zero server management — and a cost model that charges only for actual compute consumed.

What We Deliver
The four delivery pillars behind every Serverless Infrastructure engagement.

Serverless Architecture Design
Event-driven diagrams and function boundary decisions before a single line is written.

Lambda & API Gateway
Versioned functions with IAM least-privilege, WAF integration, and custom domain routing.

DynamoDB & Aurora Serverless
Single-table DynamoDB or Aurora Serverless v2 with automated backups and point-in-time recovery.

IaC with CDK / Terraform
Entire stack defined as code — reproducible across all environments with a single command.

Serverless Infrastructure | Nuwair Systems

Serverless infrastructure on AWS by Nuwair Systems. Lambda, API Gateway, DynamoDB architectures that auto-scale and charge only for actual usage.

nuwair.com

DEV Community: staticwebapps

I Found a Way to Deploy a Static Site by Just Zipping a Folder

The problem it solves

What's actually included

Where it fits

How to Host php website for free

What I used instead

What's actually included

GEO for Developers: Structuring Websites for AI Search, Retrieval, and Entity Clarity

Automating 204 Lighthouse Audits to find the fastest Shopify Theme

A Beginner's Guide to Form Backends: What They Are and When You Need One

A Beginner's Guide to Form Backends: What They Are and When You Need One — with onsubmit.dev (form backend)

A form is only the frontend

What is a “form backend as a service”?

When should you use one?

When should you build the backend yourself?

A worked example with onsubmit.dev (form backend)

What about JavaScript validation?

“But shouldn't I build it myself to learn?”

The main takeaway

Airtable as a Lightweight CRM: Capturing Website Leads Automatically

Airtable as a Lightweight CRM: Capturing Website Leads Automatically with onsubmit.dev (form backend)

Why use Airtable as a CRM?

The missing piece: getting website forms into Airtable

Setting up the workflow

What about React, Next.js, Vue, and Astro?

Turning Airtable into a small sales pipeline

Why not start with HubSpot or Salesforce?

A practical migration path

Webhook-First Form Handling: Piping Submissions Into Your Own Stack

Webhook-First Form Handling: Piping Submissions Into Your Own Stack with onsubmit.dev (form backend)

The architecture

Why put an ingestion layer in front?

Keep webhook handlers boring

Assume delivery can happen more than once

Preserve the raw event

Treat the webhook as an external API

Version your internal contract

Failure handling matters more than the happy path

Where this pattern fits

The useful abstraction

Turn Any HTML Form Into a Notion Database — Step by Step

Turn Any HTML Form Into a Notion Database — Step by Step with onsubmit.dev (form backend)

What we're building

1. Create the Notion database

2. Set up the form endpoint

3. Connect your HTML form

4. Map the fields to Notion

5. Check the resulting Notion table

Where this pattern is useful

That's it

Svelte/SvelteKit Forms: The Fastest Path From `` to Inbox

Svelte/SvelteKit Forms: The Fastest Path From <form> to Inbox with onsubmit.dev (form backend)

The usual SvelteKit approach

Using svelte-onsubmit

What about a SvelteKit form action?

Don't confuse the service with on:submit

When I would keep the SvelteKit action

Progressive enhancement still matters

Choosing between the two

Building a 100% Serverless Disposable Email Platform with Cloudflare D1 & Next.js 15

🛠 The Problem I Wanted to Solve

⚡ The Tech Stack (Serverless Excellence)

🏗 Architecture Diagram

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Why can we skip the backend?

1. Create your form endpoint

2. Add the Vue integration

3. Build the contact form

4. Understand what Vue is doing

5. Handle success and failure states

Email or Notion?

When does this approach make sense?

Serverless Infrastructure

Serverless Infrastructure | Nuwair Systems

Svelte/SvelteKit Forms: The Fastest Path From `
` to Inbox

Svelte/SvelteKit Forms: The Fastest Path From `<form>` to Inbox with onsubmit.dev (form backend)

Using `svelte-onsubmit`

Don't confuse the service with `on:submit`