DEV Community: Allen Jones

What Actually Makes a Software Engineer Great (It's Not the Framework You Know)

Allen Jones — Tue, 25 Aug 2026 18:50:15 +0000

Learn React. Learn a backend language. Build projects. Apply to jobs. That's the advice every developer who wants to level up hears. That advice isn't wrong, but it misses the thing that actually separates a senior engineer from someone who's been writing code for six months. It's not the framework in your resume. It's whether you understand why that framework exists in the first place, and whether you can reason about a problem well enough to pick the right tool instead of the familiar one.

Here are the three things that actually move the needle.

1. Understand the "Why," Not Just the "How"

If you're learning to code today, the common advice is "learn React." Fair enough, React is popular and in demand. But if you don't understand why React had to exist, how frontend development worked before it, and what problem it was solving, you're going to hit a ceiling.

A quick example: before async/await existed, asynchronous JavaScript was written with nested callbacks, and once you had a few dependent async operations in a row, that nesting turned into what everyone just called callback hell. Promises came along to flatten that out, and async/await came after to make asynchronous code read almost like synchronous code. If you only learn async/await as "the syntax you use for async stuff," you'll be lost the moment you open an older codebase full of .then() chains or raw callbacks. Knowing what problem it replaced is what lets you actually read and work in code that predates it.

This matters because tools get chosen for reasons, and those reasons change depending on the problem. A senior engineer doesn't reach for React (or Rails, or Django, or whatever is trending) by default. They look at what the project actually needs to solve, now and as it grows, and pick technology based on that.

A Concrete Example: Node.js vs Python

This "understand the why" idea gets a lot more concrete when you compare Node.js and Python, because the two languages handle concurrency in fundamentally different ways, and that difference decides what each one is actually good at.

Node.js runs on a single thread with a non-blocking event loop. When a request comes in that needs to read a file, hit a database, or call another API, Node doesn't block that thread waiting for the response. It hands the operation off (to libuv under the hood), keeps handling other requests, and comes back to yours when the data is ready.

// Node.js: this doesn't block the event loop
app.get('/user/:id', async (req, res) => {
  const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
  res.json(user);
});

This makes Node excellent at I/O bound workloads: REST APIs, real-time apps (chat, live notifications via WebSockets), streaming services, and anything where a request spends most of its time waiting on the network or disk rather than doing heavy computation. A single Node process can juggle thousands of concurrent connections because it isn't burning CPU cycles or a full thread stack per connection.

Where Node struggles is CPU-bound work. Because everything runs on that one thread, a heavy synchronous computation (image processing, video encoding, complex encryption, large in-memory data crunching) blocks the event loop entirely. Every other request waiting on that same process just freezes until the computation finishes.

// This blocks every other request until it finishes
app.get('/process', (req, res) => {
  const result = heavyImageProcessing(req.body.image); // blocks the event loop
  res.json(result);
});

Node does have worker_threads and child_process to push CPU-heavy work off the main thread, but that's a workaround you have to reach for deliberately; it's not the default execution model.

Python's story is almost the opposite. Python has something called the GIL, the Global Interpreter Lock. It means that even if you spin up multiple threads in a single Python process, only one thread can execute Python bytecode at a time. So naive multi-threading in Python does not give you true parallelism for CPU-bound work. Adding more threads to a CPU-heavy Python task usually doesn't make it faster, because they're all waiting their turn for the same lock.

This is why Python isn't the first choice for something like a high-concurrency real-time API server written from scratch, at least not without help. Pure multi-threaded Python doesn't scale CPU work the way you'd expect.

But this is also where it gets interesting, because Python is still the dominant language in data science and machine learning, and that's not a contradiction. Two things make it work:

I/O bound work still benefits from Python's concurrency tools. The GIL is released while a thread is waiting on I/O (network calls, file reads), so Python's threading module or asyncio (which mirrors Node's event loop model) still works well for I/O heavy workloads like web scraping or calling multiple APIs concurrently.
** CPU-heavy libraries do their real work outside the GIL.** Libraries like NumPy, pandas, and PyTorch are built on C, C++, or CUDA under the hood. When you call a NumPy operation on a large array, Python hands the actual number crunching to compiled code that releases the GIL and can run in parallel or on a GPU. Python itself is just the orchestration layer; the heavy lifting happens outside the interpreter entirely.

For true CPU-bound parallelism in pure Python (not delegated to a C extension), you reach for multiprocessing, which spins up separate processes, each with its own interpreter and its own GIL, and splits the work across CPU cores. It works, but it's heavier than threading because each process has its own memory space.

Where each one fits:

	Good fit	Weak fit
Node.js	APIs and microservices with high concurrent I/O, real-time apps, streaming, chat backends, thin services with light CPU work	Heavy synchronous computation, video/image processing, CPU-heavy encryption, ML model training
Python	Data science, machine learning, scientific computing, scripting and automation, I/O bound work via asyncio, backends where the ecosystem (FastAPI, Django) fits	Raw CPU-bound parallelism using plain threads, extremely high-concurrency real-time servers without async tooling

Neither language is "better." They were built with different priorities, and picking between them for a project means understanding what kind of work that project actually does, not just which one you're more comfortable with. That's the same lesson as the React example, just at the language level instead of the framework level.

Why This Matters More With AI Tools

This "understand the why" skill matters even more now that AI coding agents can write most of the code for you. There's a real difference between telling an AI agent "add authentication to this app" and being able to tell it whether to use sessions or JWTs, how long tokens should live, whether refresh tokens belong in an httpOnly cookie or local storage, and what happens to existing logged-in users when the auth flow changes.

The AI is doing the typing. The decisions still have to come from you. If your AI agent can make a technical decision without you being able to explain why it was the right one, that's worth noticing, because it means the reasoning skill isn't being built, only the code is.

2. Product Engineering: Go Beyond Writing Code

The role of a software engineer is shifting. It used to be enough to be handed a spec and implement it well. Increasingly, engineers are expected to be part of figuring out what should be built in the first place.

That means being comfortable with things that used to sit entirely with product managers: talking to users to understand the actual problem they're facing, translating that into a roadmap or a set of tickets, tying the work back to a business goal, and collaborating with product managers and designers on how the solution should work before a single line of code gets written.

Once that planning is done, handing the implementation over to an AI agent (or just writing it yourself) becomes the easy part. The hard, valuable part is everything that happens before that: understanding the problem well enough to know what "done" actually looks like.

3. System Design: Know What's Underneath the Platform

A lot of developers can push code to a managed hosting platform and have it live in minutes without ever thinking about what's happening behind that button. That's completely fine for shipping fast, but it becomes a real gap the moment you're handed infrastructure that nobody has already wired up for you.

Picture a different scenario: you're told your application needs to handle ten times its current traffic with no downtime. Would you know whether the fix is adding more app servers behind a load balancer, moving to a bigger single server, or introducing a caching layer so the database stops doing repeated work? If terms like reverse proxy, connection pooling, or cache invalidation feel fuzzy, that's less about any one tool and more about a gap in system design fundamentals.

The fundamentals worth understanding here:

The difference between horizontal scaling (more machines) and vertical scaling (bigger machines), and when each makes sense
What a load balancer and a reverse proxy actually do, and how requests get routed across multiple app servers
Private networking and secure communication between services
Database security, connection pooling, and access patterns at scale
Managing infrastructure through code and version control versus clicking through a cloud dashboard by hand

Using a managed hosting platform because it's fast and convenient is a completely reasonable choice. The problem is only when it's the only thing you know how to do, because the moment a project needs something that platform doesn't offer, you're stuck without the fundamentals to build it yourself.

Putting It Together

None of these three things (understanding the fundamentals behind your tools, thinking like a product engineer, and understanding system design) show up on a "learn React in 30 days" course outline. They're slower to build and harder to measure. But they're also the actual difference between an engineer who can be handed any problem and figure it out, and one who can only work within the exact stack and constraints they were taught.

If you're early in your career, you don't need to master all three at once. Start by picking apart one tool or framework you already use every day and asking why it exists, what problem it solved, and what the alternative would have looked like without it. That habit, repeated across enough tools, is what builds the kind of judgment that AI can't replace for you.

The N+1 Query Problem: Why Your API Might Be Making 101 Database Queries Instead of 2

Allen Jones — Tue, 25 Aug 2026 15:55:47 +0000

If your API feels fast in development but becomes painfully slow in production as your data grows, there's a good chance you're looking at the N+1 query problem. It's one of the most common backend performance issues, and the frustrating part is that the code usually looks completely fine at first glance.

The Setup

Say you have two tables: customers and orders. Each order belongs to a customer through a foreign key.

CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255)
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INTEGER REFERENCES customers(id),
  total NUMERIC(10, 2)
);

Here's what that relationship looks like. Each row in orders points back to exactly one row in customers through customer_id, while a single customer can have many orders pointing at them. That's a classic one to many relationship.

erDiagram
    customers ||--o{ orders : "has many"
    customers {
        int id PK
        varchar name
    }
    orders {
        int id PK
        int customer_id FK
        numeric total
    }

You can also picture it as two flat tables with the foreign key drawing the line between them:

customers                      orders
+----+---------+               +----+-------------+--------+
| id | name    |               | id | customer_id | total  |
+----+---------+               +----+-------------+--------+
| 1  | Sarah   |     <---------| 1  | 1           | 42.00  |
| 2  | James   |     <---+     | 2  | 1           | 15.50  |
| 3  | Emily   |     <-+ \-----| 3  | 2           | 99.99  |
+----+---------+       \-------| 4  | 3           | 27.30  |
                                +----+-------------+--------+

Every arrow is orders.customer_id referencing customers.id. That's the foreign key. It's what makes it possible to reconstruct "this customer, with these orders" without storing the order data twice.

Now say you want to return every customer along with all the orders they've placed. A common first pass looks something like this (pseudocode, but it maps closely to a naive Prisma or ActiveRecord setup):

const customers = await db.query('SELECT * FROM customers');

for (const customer of customers) {
  customer.orders = await db.query(
    'SELECT * FROM orders WHERE customer_id = ?',
    [customer.id]
  );
}

Why It's Called N+1

This looks reasonable. You get all the customers, then loop through and grab each one's orders. But look at what's actually hitting the database:

One query to fetch all customers
One additional query per customer to fetch that customer's orders

If you have 100 customers, that's 1 query for the customers plus 100 queries for their orders: 101 total queries. Hence "N+1," where N is the number of rows from the first query.

sequenceDiagram
    participant App
    participant DB

    App->>DB: SELECT * FROM customers
    DB-->>App: 100 customers

    loop for each of the 100 customers
        App->>DB: SELECT * FROM orders WHERE customer_id = ?
        DB-->>App: orders for that customer
    end

    Note over App,DB: Total: 1 + 100 = 101 queries

This scales linearly with your data, and not in a good way. At 100 customers, 101 queries might not even show up as a bottleneck. At 100,000 customers, that's 100,001 queries per request, and your database (and your server) will not thank you for it. If this endpoint is something like an admin dashboard or a customer list page that gets hit often, that cost repeats on every single request.

The Fix: A Single SQL JOIN

Instead of fetching customers and orders separately, you can pull both in one query using a JOIN:

SELECT
  customers.id,
  customers.name,
  orders.id AS order_id,
  orders.total
FROM customers
LEFT JOIN orders ON orders.customer_id = customers.id;

This returns every customer paired with each of their orders in a single result set, one round trip to the database instead of N+1.

sequenceDiagram
    participant App
    participant DB

    App->>DB: SELECT customers.*, orders.* FROM customers LEFT JOIN orders ON orders.customer_id = customers.id
    DB-->>App: all customers with their orders, in one result set

    Note over App,DB: Total: 1 query, regardless of customer count

Your application code then just needs to group the flat rows back into a nested structure (customers with an orders array), which is a cheap in-memory operation compared to hundreds of network round trips to the database.

How Different Frameworks Solve This

Every major ORM has a built-in way to do this join for you, they just name it differently:

Framework	Feature name	Example
Django	`select_related` / `prefetch_related`	`Customer.objects.prefetch_related('orders')`
Laravel (Eloquent)	Eager loading	`Customer::with('orders')->get()`
Prisma	`include`	`prisma.customer.findMany({ include: { orders: true } })`
Rails (ActiveRecord)	Eager loading	`Customer.includes(:orders)`

Under the hood, they're all doing roughly the same thing: either issuing a single JOIN query, or batching the "get related records" step into one WHERE customer_id IN (...) query instead of N separate ones. Either approach collapses N+1 queries down to 1 or 2.

How to Catch This in Your Own Code

The tricky part about N+1 is that the code reads fine. The problem only shows up when you look at what's actually hitting the database. A few ways to catch it:

Turn on query logging in development and count how many queries a single request generates. If that number scales with the size of your dataset, that's the smell. A "get all customers" endpoint that fires 1 query with 5 test customers and 51 queries with 50 customers is the tell.
Most ORMs have a debug or profiling mode (Prisma's query logging, Laravel Debugbar, Django Debug Toolbar) that will show you the exact query count per request.
Load test with realistic data volumes, not 5 rows in a dev database. N+1 is invisible at small scale and brutal at large scale.

It Gets Worse With Nested Relationships

The two table example is the simplest case, but N+1 compounds fast once you add another level of relationships. Say each order also has line items:

const customers = await db.query('SELECT * FROM customers');

for (const customer of customers) {
  customer.orders = await db.query(
    'SELECT * FROM orders WHERE customer_id = ?',
    [customer.id]
  );

  for (const order of customer.orders) {
    order.items = await db.query(
      'SELECT * FROM order_items WHERE order_id = ?',
      [order.id]
    );
  }
}

Now you're not just paying N+1, you're paying N (customers) plus M (orders per customer) queries, nested inside each other. With 100 customers averaging 5 orders each, that's 1 query for customers, 100 queries for orders, and 500 more queries for order items: 601 queries for what should be 3.

This is exactly the shape of bug that shows up in GraphQL resolvers too. A resolver for orders that runs a query per parent customer, and a resolver for items that runs a query per parent order, will happily reproduce N+1 at every level of the graph unless something batches those calls. This is why libraries like dataloader exist in the GraphQL/Node ecosystem: they collect all the individual "get orders for customer X" calls that fire within a single tick, merge them into one WHERE customer_id IN (1, 2, 3, ...) query, and hand each caller back its slice of the result.

A Rough Sense of the Cost

Query count is only part of the story, latency per query matters too. If a single query takes even 2ms round trip (a reasonable number for a local or same region database), the difference looks like this as your customer table grows:

Customers	N+1 queries	Approx. time at 2ms/query	Join queries	Approx. time
100	101	~200ms	1	~2ms
1,000	1,001	~2s	1	~2ms
10,000	10,001	~20s	1	~2ms
100,000	100,001	~200s	1	~2ms

Those numbers are simplified (real databases pipeline and cache some of this), but the trend is the real point: N+1 turns your response time into a function of your data size, while a JOIN keeps it roughly constant regardless of how many customers you have. For something like an order history page or a checkout flow, that's the difference between a page that loads instantly and one that times out under real traffic.

Don't Forget the Index

A JOIN only stays fast if the foreign key column is indexed. Without an index on orders.customer_id, the database has to scan the entire orders table for every customer it's joining against, which can turn your one query fix into a slow one query fix on large tables.

CREATE INDEX idx_orders_customer_id ON orders(customer_id);

Most ORMs create this index automatically when you define a foreign key relationship, but it's worth checking on tables that were set up by hand or migrated from another system, since a missing index here is a common reason a JOIN based fix still feels slow.

Takeaway

N+1 is one of those bugs that doesn't look like a bug. The code is readable, it passes tests, and it works fine with a handful of records. It's only when your data grows that the query count explodes and starts dragging down response times. The fix is almost always the same: replace the loop of individual queries with a single JOIN or your ORM's eager loading feature, and let the database do the work it's actually good at.

What an idempotency key actually does

Allen Jones — Fri, 21 Aug 2026 00:34:23 +0000

A client sends a transfer request. The server debits the sender, credits the receiver, commits, and starts writing the response. The connection drops half a millisecond before the client reads it. The client, seeing no response, does the only reasonable thing a retry policy knows how to do: sends the same request again.

The server has no idea any of that happened. It just sees a second, perfectly well-formed request to move money. So it does it again.

Client                          Server
  |                                |
  |----- POST /transfers -------->|
  |                                | debit sender
  |                                | credit receiver
  |                                | commit
  |        X  (connection drops)  |
  |                                |
  | (timeout, no response seen)   |
  |                                |
  |----- POST /transfers -------->|  <-- identical request
  |                                | debit sender  (again)
  |                                | credit receiver  (again)
  |                                | commit
  |<---------- 200 OK -------------|

That is the whole problem. Not a rare one either; it's the default behavior of almost every HTTP client library the moment you add a timeout and a retry. The client did nothing wrong. It genuinely cannot tell the difference between "the server never got my request" and "the server got it, handled it, and I just never heard back."

Why "just check the balance first" doesn't work

The instinct is to guard the transfer with a check: does the sender have enough balance, is the receiver valid, and so on. None of that helps here. The retried request is not invalid. It's a completely legitimate transfer request that happens to be a duplicate of one that already succeeded. Every validation check passes, twice.

You also can't fix this by making the operation "fast enough" that retries become rare. Networks time out for reasons that have nothing to do with your server's speed: a client-side timeout fires, a proxy in the middle drops the connection, a mobile client loses signal for two seconds. The request already fully executed on your server. The client just never found out.

The fix is a key, not a check

An idempotency key is a value the client generates once per logical operation, before it ever calls the endpoint, and sends on every attempt of that same operation, retries included.

const idempotencyKey = crypto.randomUUID();

await fetch('/api/transfers', {
  method: 'POST',
  headers: { 'Idempotency-Key': idempotencyKey },
  body: JSON.stringify({ fromAccount, toAccount, amount }),
});

If the request fails or times out, the client retries with the same key. Not a new one. The key represents "this transfer," not "this HTTP request."

Client                          Server
  |                                |
  | key = "6f2a-...-91"           |
  |----- POST /transfers -------->|
  |     Idempotency-Key: 6f2a     | key seen? no
  |                                | debit sender
  |                                | credit receiver
  |                                | store result under 6f2a
  |        X  (connection drops)  |
  |                                |
  |----- POST /transfers -------->|  <-- same key, same body
  |     Idempotency-Key: 6f2a     | key seen? yes
  |                                | skip transfer logic entirely
  |<---------- 200 OK -------------|  return the stored result

On the server, before doing anything with money, check whether that key has been seen before:

CREATE TABLE idempotency_keys (
  key text PRIMARY KEY,
  request_hash text NOT NULL,
  response_status int,
  response_body jsonb,
  created_at timestamptz DEFAULT now()
);

async function handleTransfer(key: string, payload: TransferRequest) {
  const existing = await db.query(
    'SELECT * FROM idempotency_keys WHERE key = $1',
    [key]
  );

  if (existing.rows.length > 0) {
    return existing.rows[0].response_body;
  }

  const result = await executeTransfer(payload);

  await db.query(
    `INSERT INTO idempotency_keys (key, request_hash, response_status, response_body)
     VALUES ($1, $2, $3, $4)`,
    [key, hashPayload(payload), 200, result]
  );

  return result;
}

Second attempt with the same key finds the stored row and returns the original result. It never touches the transfer logic again. The money moves exactly once, no matter how many times the network makes the client ask.

Same key, different payload, is a bug, not a replay

There's a failure mode this simple version misses. What if the same key shows up with a different amount, because of a bug on the client, or someone reusing a key by accident? A naive lookup would happily return the stored response from a completely different transfer and call it correct.

That's what request_hash in the table is for. On the second request, before trusting the cached response, compare the hash of the incoming payload against what was stored the first time:

const incomingHash = hashPayload(payload);

if (existing.rows.length > 0) {
  if (existing.rows[0].request_hash !== incomingHash) {
    throw new ConflictError('Idempotency key reused with a different request');
  }
  return existing.rows[0].response_body;
}

A mismatch here should be a hard error, not a silent overwrite in either direction. It means either the client has a bug generating keys, or something worse. Either way, replaying a different transfer under an old key is exactly the kind of thing idempotency exists to prevent, so the check has to be as strict as the thing it's protecting.

Three states, not two

The lookup above only really distinguishes "never seen" from "seen and done." There's a third state hiding in between: seen, but still running. It shows up the moment two attempts overlap in time instead of arriving one after another.

              INSERT reserves the key
                        |
                        v
        +---------------------------+
        |          PENDING          |   response_body IS NULL
        |  (transfer in progress)   |
        +---------------------------+
                        |
          executeTransfer() finishes
                        |
                        v
        +---------------------------+
        |         COMPLETED         |   response_body populated
        |   (safe to replay freely) |
        +---------------------------+

        A different payload hash arriving
        against an existing key, in either
        state above, is neither of these.
        It is a CONFLICT, and should be
        rejected outright.

A lookup that only checks "does a row exist" can't tell a PENDING row from a COMPLETED one. Reading a PENDING row's response_body gets you NULL, not "please wait." The read path has to check which state it landed in and behave differently for each.

The race no one thinks about until it bites

Everything above assumes the two attempts arrive one after another. They don't have to. A client with an aggressive retry policy can fire the retry before the first attempt has finished, especially if the timeout it's reacting to was on the client side, not because the server was actually slow. Now two requests with the same key are running concurrently, and both can pass the "have I seen this key" check before either has written a row.

Time  Request A                    Request B
----  --------------------------   --------------------------
 t0   check key "6f2a"  -> none
 t1                                check key "6f2a"  -> none
 t2   begin transfer
 t3                                begin transfer      <-- !!
 t4   debit sender
 t5                                debit sender         <-- both proceed
 t6   credit receiver
 t7                                credit receiver
 t8   INSERT key "6f2a"  -> ok
 t9                                INSERT key "6f2a"  -> UNIQUE VIOLATION

Both proceed to execute the transfer. The unique constraint on key will stop the second INSERT from succeeding, but by then the second request may have already moved money, because the transfer logic and the idempotency check aren't happening atomically. The constraint catches the write collision after the damage, not before it.

The fix is to reserve the key before doing the work, not after:

async function handleTransfer(key: string, payload: TransferRequest) {
  const incomingHash = hashPayload(payload);

  try {
    await db.query(
      `INSERT INTO idempotency_keys (key, request_hash, response_status, response_body)
       VALUES ($1, $2, NULL, NULL)`,
      [key, incomingHash]
    );
  } catch (err) {
    if (isUniqueViolation(err)) {
      return await waitForCompletedResult(key, incomingHash);
    }
    throw err;
  }

  const result = await executeTransfer(payload);

  await db.query(
    `UPDATE idempotency_keys
     SET response_status = 200, response_body = $2
     WHERE key = $1`,
    [key, result]
  );

  return result;
}

Re-run the same race with the reservation moved first:

Time  Request A                    Request B
----  --------------------------   --------------------------
 t0   INSERT key "6f2a"  -> ok
 t1                                INSERT key "6f2a"  -> UNIQUE VIOLATION
 t2   begin transfer
 t3                                wait for row to complete
 t4   debit sender
 t5   credit receiver
 t6   UPDATE key "6f2a" -> done
 t7                                read completed row -> return result

Only one request ever touches the transfer logic. The other one blocks on the database's own uniqueness guarantee, which is enforced by Postgres itself, not by application code hoping nothing runs in between two steps. Whether "wait" means polling the row every hundred milliseconds or something fancier depends on how much concurrency you're actually expecting. For a personal project, polling is a perfectly honest starting point.

Idempotency is not a transaction

Worth being precise about this, because the two get blurred together.

+-----------------------------------------------------+
|                 One HTTP request                    |
|                                                       |
|   +-----------------------------------------------+ |
|   |         Database transaction (ACID)            | |
|   |                                                 | |
|   |   debit sender  -->  credit receiver  -->  ok   | |
|   |   (both happen, or neither does)               | |
|   +-----------------------------------------------+ |
|                                                       |
+-----------------------------------------------------+
                          ^
                          |
        Idempotency key wraps the OUTSIDE of this box,
        making it safe to ask for the whole box again.

A database transaction makes a single operation atomic: the debit and the credit inside executeTransfer either both happen or neither does. Idempotency is a different guarantee, layered on top: it makes repeating the same request from the outside safe, regardless of how many times it's repeated. You need both. The transaction protects the money during one execution. The idempotency key protects the money across retries of that execution.

Keys don't live forever

One thing I glossed over: the idempotency_keys table grows with every request, forever, if nothing ever removes old rows. Most systems only need a key to stay valid for as long as a client might plausibly still be retrying an hour, maybe twenty-four, not indefinitely.

DELETE FROM idempotency_keys
WHERE created_at < now() - interval '24 hours';

Run on a schedule, this keeps the table from becoming a second, ever-growing ledger sitting next to the real one. It also means a key can safely be reused after that window closes, which matters if client code ever generates keys from something less random than a UUID, a timestamp plus a user ID, say.

What I check now

Before I add a new "money moving" endpoint anywhere, I check:

Does the client generate the key before the first attempt, and reuse it on every retry, never a fresh key per retry?
Is the key reserved with a unique constraint before the operation runs, not just checked and then trusted?
Does a key collision with a different payload hash fail loudly, instead of silently returning the wrong stored result?
Does the read path distinguish pending from completed, instead of treating "row exists" as one single state?
Am I storing the actual response, so a retry gets back the same answer the original call would have given, not just a generic "already done"?
Do old keys expire, so the table isn't a permanent second ledger?

The transfer logic was never the hard part. Making it safe to ask twice was.

Embeddings are just arrays. Retrieval is the work.

Allen Jones — Thu, 20 Aug 2026 14:56:45 +0000

I delayed actually using embeddings because the word sounds like a research paper. It is not. An embedding is a list of numbers that stands in for a piece of text. Same length every time. Nearby lists mean nearby meaning, if the model is any good.

That is the whole trick. The rest is plumbing.

What I hold in my head

Take a sentence. Send it through a model. Get back 1536 floats (or 384, or 768; the number is a property of the model, not a law of nature). Store that array next to the original text.

At query time, embed the question the same way. Compare arrays. Return the texts whose arrays are closest.

No search index is required to understand this. A nested loop over ten chunks in a test file is enough:

function cosineSimilarity(a: number[], b: number[]): number {
  if (a.length !== b.length) {
    throw new Error('Vector length mismatch');
  }

  let dot = 0;
  let magA = 0;
  let magB = 0;

  for (let i = 0; i < a.length; i += 1) {
    dot += a[i] * b[i];
    magA += a[i] * a[i];
    magB += b[i] * b[i];
  }

  return dot / (Math.sqrt(magA) * Math.sqrt(magB));
}

When I could explain that function without looking it up, the libraries stopped feeling like magic.

Two arrays from two different models are not comparable

This one cost me an afternoon. I had a batch of chunks embedded with one model, then switched providers mid experiment and re-embedded only the new chunks with a different model. Same dimension count, coincidentally. The code ran. No errors. The similarity scores were just quietly wrong, every query returning a confident, meaningless top match.

Two embeddings are only comparable if the same model produced both. Not the same dimension count, the same model, ideally the same version of it. A 1536 length array from one model and a 1536 length array from another are just two arrays that happen to be the same size. They do not share a coordinate system. Cosine similarity between them is a number, but it is not a meaningful one.

The fix was boring: store the model name and version next to every embedding, and refuse to compare across a mismatch instead of letting it fail silently.

type EmbeddingRecord = {
  vector: number[];
  model: string;
  createdAt: string;
};

If I change embedding models later, I re-embed everything. There is no partial migration where old and new vectors coexist in the same comparison. That single row of metadata is what makes that decision obvious the next time, instead of a debugging session.

Chunking is the product decision

The array is only as useful as the text you fed the model. I first embedded whole markdown files. Retrieval returned "the right document" and the wrong paragraph. Then I split on headings, then on overlapping windows of ~400 tokens.

There is no universal chunk size. There is only: what question will a user ask, and how much surrounding context does an answer need?

I am treating chunking as a product decision, not a preprocessing detail. The table schema should remember that:

type Chunk = {
  id: string;
  docId: string;
  body: string;
  headingPath: string[];
  embedding: number[];
};

headingPath has already saved me once, when two chunks were numerically close and only the section title told me which one belonged in the answer.

Looking at what actually gets retrieved

Before I let anything call an LLM, I wrote a script that does nothing but print the top five matches for a hardcoded question, with their scores, and nothing else:

async function debugRetrieve(question: string, k = 5) {
  const queryVector = await embed(question);
  const results = chunks
    .map((chunk) => ({
      chunk,
      score: cosineSimilarity(queryVector, chunk.embedding),
    }))
    .sort((a, b) => b.score - a.score)
    .slice(0, k);

  for (const { chunk, score } of results) {
    console.log(score.toFixed(4), chunk.headingPath.join(' > '), '\n', chunk.body.slice(0, 120));
  }
}

Running this against a dozen questions I already knew the answers to caught more bugs than any amount of staring at the ingestion code did. It's how I found a chunking script that was silently producing empty headingPath arrays for every chunk in one document, because the regex assumed headings started at the beginning of a line and one file used a different line ending. Every chunk still embedded fine. The score still returned a number. Nothing errored. It just made every match from that document indistinguishable from every other match from that document, and I would not have noticed without reading the raw output.

An LLM sitting on top of bad retrieval will still write a fluent, confident sentence. That is exactly why I don't trust it to tell me the retrieval is broken. I have to look at the arrays and the text myself, before the LLM ever gets involved.

Brute force works until it doesn't

The nested loop above is O(n), it checks every stored vector against the query vector, every time. For ten chunks that's instant. For a few hundred, still instant. I am not optimizing this yet, on purpose.

The reason people reach for pgvector's ivfflat or hnsw indexes, or a dedicated vector database, is that brute force stops being instant somewhere in the tens or hundreds of thousands of rows, depending on hardware. Those indexes trade a small amount of accuracy (they're approximate nearest neighbor, not exact) for a large amount of speed at that scale.

I don't have that problem yet. Adding an index before you need one just adds a second thing that can be subtly wrong, on top of the chunking and the model mismatch and everything else already in the pipeline. The honest brute force loop is also the easiest thing to verify by hand, which matters more right now than the query taking two milliseconds instead of two hundred.

The embedding call is a network call

Easy to forget, since it's wrapped in a function named something friendly like embed(). It's an HTTP request to someone else's server. It has latency, it has a rate limit, and it costs a fraction of a cent every time you make it.

Re-embedding the same chunk twice because a script re-ran is a real way to burn through a rate limit for no reason. The fix is a hash of the chunk's text, stored alongside the embedding:

type Chunk = {
  id: string;
  docId: string;
  body: string;
  headingPath: string[];
  embedding: number[];
  contentHash: string;
};

Before embedding a chunk, hash its body and compare against what's stored. Same hash, skip the call. Different hash, the text changed, re-embed it. It's a caching problem wearing an AI costume.

What I am not doing yet

I am not fine-tuning. I am not swapping models every afternoon. I am not building a vector database product. I am not indexing for scale I don't have. I am trying to get one retrieval path honest: same model in, same model out, scores I can explain, chunks a human could have picked, and a debug script I actually run before trusting the output.

The arrays are the easy part. Making the surrounding system tell the truth is the work.

How to Build an AI Email Auto-Reply System with RAG and PostgreSQL

Allen Jones — Thu, 20 Aug 2026 08:50:45 +0000

I've been spending time learning how AI systems actually work under the hood, not just calling an API and hoping for the best. One of the clearest ways to understand Retrieval Augmented Generation (RAG) is to build something with a real use case: an AI system that reads a customer email, finds a similar question we've already answered, and drafts a reply using that approved answer.

Here's the full mental model, no code first, just the pieces and how they connect.

The Problem

A customer sends an email like this:

"Hey, I want to stop paying for my account. How can I do that?"

An LLM on its own has no idea that "Settings → Billing → Cancel" is how your product handles that. It only knows general language patterns, not your product's specific answers. So the LLM needs to be handed the right context before it writes a reply. That's the whole idea behind RAG: retrieve relevant information first, then generate a response using that information.

Step 1: A Table of Known Questions and Answers

Think of it like a spreadsheet with four columns:

id	question	answer	embedding
1	How do I cancel my subscription?	Go to Settings → Billing and click Cancel.	[0.12, -0.43, 0.71, ...]
2	Can I export my submissions?	Go to Submissions → Export.	[0.82, 0.14, -0.21, ...]
3	My Google Sheets sync isn't working.	Reconnect Google Sheets from Integrations.	[0.31, -0.72, 0.44, ...]

The first three columns are self explanatory. The fourth one, embedding, is the interesting part.

An embedding is a list of numbers that represents the meaning of a piece of text. Two sentences that mean similar things end up with number lists that are close together mathematically, even if the wording is completely different. "I want to stop paying for my account" and "How do I cancel my subscription?" don't share many words, but they'll produce embeddings that sit close to each other in that number space.

This is not something you calculate by hand. You send the text to an embedding model (OpenAI's text-embedding-3-small, for example) and it returns 1,536 numbers back.

In PostgreSQL, once you install the pgvector extension, you can store that directly as a column type:

CREATE TABLE knowledge (
    id SERIAL PRIMARY KEY,
    question TEXT NOT NULL,
    answer TEXT NOT NULL,
    embedding VECTOR(1536)
);

Step 2: Turning the Incoming Email into a Vector

When a new email comes in, the application sends that email's text to the same embedding model that built the table. In Node.js, that's roughly:

const embedding = await createEmbedding(email);

The model turns the customer's sentence into a list of numbers:

"I want to stop paying for my account."

      ↓
Embedding model
      ↓
[0.15, -0.38, 0.71, ...]

This is called the query vector. It's temporary. It never gets inserted into the knowledge table, it only exists to search against the rows that are already there. Once the reply is sent, it's discarded.

Step 3: The Retrieval Query, Broken All the Way Down

This next part is the piece most tutorials rush past, but it's the actual "R" in RAG, so it's worth slowing down for. Here's the full query again:

SELECT
    question,
    answer,
    1 - (embedding <=> $1::vector) AS similarity
FROM knowledge
ORDER BY embedding <=> $1::vector
LIMIT 3;

It looks intimidating the first time you see it. In plain English it's doing exactly one thing: "Take this user's email, compare its vector against every stored vector, and give me the three most similar ones."

Let's go through it piece by piece.

What `$1` actually is

$1 is a parameter placeholder, standard in parameterized SQL queries. On the Node.js side, the application passes the query vector into that placeholder when it runs the query:

db.query(sql, [JSON.stringify(embedding)]);

So conceptually, by the time this reaches PostgreSQL, it's really executing:

embedding <=> '[0.15, -0.38, 0.71, ...]'::vector

Which just means: "Compare the stored embedding column with this new vector I just generated."

What `<=>` actually does

This is a pgvector operator. It calculates cosine distance between two vectors, which is a standard way to measure how different two directions in space are.

Picture two vectors that point in nearly the same direction:

Stored vector              Query vector
[0.14, -0.40, 0.70]        [0.15, -0.38, 0.71]
             \                    /
              \                  /
               very similar

The distance between those might come out to something like 0.05.

Now picture two vectors pointing in very different directions:

Stored vector              Query vector
[-0.8, 0.2, -0.4]           [0.15, -0.38, 0.71]
             \                    /
              \                  /
                  very different

That distance might come out to 0.91.

The rule to remember: smaller distance means more similar meaning.

What `ORDER BY` does here

ORDER BY embedding <=> $1

This sorts every row in the table by its distance from the new email's vector, closest first. If PostgreSQL calculated distances like this across five stored questions:

Document                         Distance
Cancel subscription              0.08
Export submissions               0.71
Google Sheets                    0.63
Refund policy                    0.21
React documentation              0.94

after the ORDER BY, it becomes:

Cancel subscription              0.08
Refund policy                    0.21
Google Sheets                    0.63
Export submissions               0.71
React documentation              0.94

The closest matches float to the top.

What `LIMIT 3` does

Exactly what it says: keep only the first three rows after sorting. So from the list above, we'd walk away with Cancel subscription, Refund policy, and Google Sheets, and drop the rest.

Where the `similarity` score comes from

This is the part that trips people up the most:

1 - (embedding <=> $1::vector) AS similarity

Cosine distance works backwards from how humans naturally think about it. Smaller distance means more similar, but most people expect a "similarity score" to work the other way, where a bigger number means more similar. So the query flips it:

distance = 0.08
1 - 0.08
similarity = 0.92

Which lets the API return something like:

[
  {
    "question": "How do I cancel my subscription?",
    "answer": "Go to Settings → Billing.",
    "similarity": 0.92
  }
]

Now you can say "this previous question is 92% similar to the customer's question," which reads a lot more naturally in a dashboard or a log than a raw distance value would.

One caveat worth keeping in your head: don't treat that number as a calibrated probability. It's a transformed cosine-distance score, not a confidence percentage in any statistical sense. It's still genuinely useful for ranking and for sanity-checking whether a match is close enough to trust, just don't over-interpret the exact number.

Putting the whole query back together

FROM knowledge
     ↓
Look through all our stored knowledge
     ↓
embedding <=> $1
     ↓
Calculate distance between each stored vector
and the user's vector
     ↓
ORDER BY
     ↓
Put closest vectors first
     ↓
LIMIT 3
     ↓
Give me the three closest ones
     ↓
SELECT question, answer
     ↓
Return the actual useful information

Run against our example table, this returns something like:

question	answer	similarity
How do I cancel my subscription?	Go to Settings → Billing and click Cancel.	0.92
What is your refund policy?	Refunds can be requested within 30 days.	0.71
Can I change my billing plan?	You can change your plan from Settings → Billing.	0.68

That's the retrieval half of RAG, done in one query. When people talk about RAG "retrieving relevant context," this is the exact mechanism they mean. And it's also why the embedding column matters so much: without those stored vectors, PostgreSQL has nothing to compare the new email against.

Step 4: Handing the Retrieved Answers to the LLM

Now the system passes the customer's original email plus the top matched answers to the LLM, with a prompt roughly like:

Customer:
"I want to stop paying for my account. How can I do that?"

Relevant company knowledge:
"Go to Settings → Billing and click Cancel."

Write a helpful response.

The LLM isn't guessing anymore. It has the actual approved answer in front of it and just needs to phrase it as a reply:

"Hi! You can cancel your subscription by going to Settings → Billing and clicking Cancel. Let me know if you need any help."

Building It: A Minimal Working Implementation

Everything above is the mental model. Here's what it looks like as actual code, using Node.js, PostgreSQL, pgvector, and OpenAI's API. This is deliberately minimal, enough to see every piece connect, not a production-hardened system.

1. Set up the database

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE knowledge (
    id SERIAL PRIMARY KEY,
    question TEXT NOT NULL,
    answer TEXT NOT NULL,
    embedding VECTOR(1536)
);

2. Seed it with known questions and answers

This runs once, or whenever you add new approved answers to your knowledge base. Each row gets embedded before it's inserted.

import OpenAI from "openai";
import { Pool } from "pg";

const openai = new OpenAI();
const pool = new Pool();

async function createEmbedding(text) {
  const response = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input: text,
  });
  return response.data[0].embedding;
}

const knowledgeBase = [
  {
    question: "How do I cancel my subscription?",
    answer: "Go to Settings → Billing and click Cancel.",
  },
  {
    question: "Can I export my submissions?",
    answer: "Go to Submissions → Export.",
  },
  {
    question: "My Google Sheets sync isn't working.",
    answer: "Reconnect Google Sheets from Integrations.",
  },
];

async function seed() {
  for (const item of knowledgeBase) {
    const embedding = await createEmbedding(item.question);
    await pool.query(
      `INSERT INTO knowledge (question, answer, embedding)
       VALUES ($1, $2, $3::vector)`,
      [item.question, item.answer, JSON.stringify(embedding)]
    );
  }
  console.log("Knowledge base seeded.");
}

seed();

3. Handle an incoming email

This is the part that runs live, every time a new customer email arrives. It embeds the email, retrieves the closest matches, and asks the LLM to draft a reply using them.

async function draftReply(customerEmail) {
  // Step 1: embed the incoming email
  const queryEmbedding = await createEmbedding(customerEmail);

  // Step 2: retrieve the closest known questions
  const result = await pool.query(
    `SELECT question, answer,
            1 - (embedding <=> $1::vector) AS similarity
     FROM knowledge
     ORDER BY embedding <=> $1::vector
     LIMIT 3`,
    [JSON.stringify(queryEmbedding)]
  );

  const matches = result.rows;

  // Step 3: build context from the retrieved rows
  const context = matches
    .map((row) => `Question: ${row.question}\nApproved answer: ${row.answer}`)
    .join("\n\n");

  // Step 4: ask the LLM to draft a reply using that context
  const completion = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content:
          "You are a support assistant. Use the approved answers below to write a short, helpful reply to the customer. Do not invent information that isn't in the approved answers.",
      },
      {
        role: "user",
        content: `Customer email:\n"${customerEmail}"\n\nRelevant company knowledge:\n${context}`,
      },
    ],
  });

  return completion.choices[0].message.content;
}

// Example usage
const reply = await draftReply(
  "I want to stop paying for my account. How can I do that?"
);
console.log(reply);

That's the entire system. An Express route or a Next.js API route just wraps draftReply and returns the result, maybe with a "send" button in a dashboard rather than auto-sending, since you'll want a human reviewing replies at first.

A few things worth doing before this touches real customers

Set a similarity threshold. If the closest match only scores 0.35, that's not actually relevant, it's just the least-far option in the table. Below a threshold like 0.75 or so (tune this against your own data), fall back to a human instead of letting the LLM guess.

Log what got matched. Store which rows were retrieved for each email alongside the final reply. When something goes wrong, you'll want to see exactly what context the LLM was working from.

Keep the system prompt strict. Telling the model not to invent information outside the approved answers matters more than it looks like it should. Without that instruction, it'll happily blend in plausible sounding details that were never approved.

The Full Pipeline

Customer email
      ↓
Embedding model
      ↓
Query vector
      ↓
PostgreSQL + pgvector
      ↓
Vector similarity search
      ↓
Top matching Q&A rows
      ↓
LLM (given the retrieved answers as context)
      ↓
Drafted reply

The Mental Model Worth Keeping

Don't treat the embedding column as some kind of AI magic. It's just a column full of numbers that represent meaning. And the retrieval query is just this, in plain language:

"Take the new email's numbers, compare them against every row's numbers, and give me back the rows whose numbers are closest."

The LLM's only job after that is to take the retrieved rows and turn them into a well written reply. Everything before that step is straightforward math and a database query.

That's the foundation RAG systems are built on, whether it's a support ticket router, a documentation chatbot, or an email auto-reply system like this one. The retrieval mechanism barely changes. What changes is what you're retrieving and what you do with it afterward.

What the Vector Database Is Doing vs What the LLM Is Doing

It's easy to blur these two together when you're first learning this, so it's worth separating them cleanly.

	Vector database (PostgreSQL + pgvector)	LLM
Job	Find which stored rows are closest in meaning to the new input	Turn retrieved information into natural, well phrased language
How	Cosine distance between number lists, pure math	Language generation, trained on huge amounts of text
Knows about your product?	No, it just stores numbers and compares them	No, unless you hand it context
Creative?	Not at all, it's deterministic, same input always ranks the same	Yes, this is where actual reasoning and phrasing happen
Can it hallucinate?	No, it either finds a close match or it doesn't	Yes, if it's not given clear context or instructions

The database never "understands" anything. It's doing arithmetic on lists of numbers, nothing more. All of the actual language understanding happened earlier, when the embedding model converted text into those numbers in the first place. And all the actual writing happens later, when the LLM turns retrieved facts into a sentence a customer will read.

Once you see the split this clearly, a lot of the mystery around RAG disappears. The database's only job is ranking. The LLM's only job is writing. Neither one does the other's job.

When You Don't Need a Vector Database

Just because you're building something AI-powered doesn't mean pgvector belongs in the stack. A few honest signals that you can skip it:

Your knowledge base is small enough to just paste into the prompt. If you have twenty or thirty approved answers total, you can hand all of them to the LLM directly, every time, and let it pick the relevant one itself. No retrieval step needed. This stops making sense once your knowledge base grows past what comfortably fits in a prompt, both for cost and for the model's accuracy at picking the right one out of a long list.

Plain keyword search already works. If your questions use fairly consistent, predictable wording (support tickets from a technical audience often do), a simple ILIKE or full text search in PostgreSQL might get you 90% of the way there without needing embeddings at all.

Your data barely changes. If the set of question and answer pairs is basically static, you don't need a live similarity search system. You could precompute the best match for a fixed set of common inputs and skip the infrastructure entirely.

You're validating an idea, not shipping a product yet. Standing up pgvector, an embedding pipeline, and a retrieval query is real infrastructure. If you're still testing whether AI auto replies are even useful for your support volume, start by hardcoding a handful of examples straight into a prompt. Add the vector database once you've proven the concept and the knowledge base has grown past what fits comfortably in context.

The pattern is the same one that shows up everywhere in software: reach for the simplest thing that solves the actual problem, and only add the heavier piece once you've outgrown the simple one.

How to Build a Quote Request System with React (2026 Guide)

Allen Jones — Tue, 21 Jul 2026 15:43:05 +0000

Most "contact us" forms on freelancer and agency sites do the same thing. A visitor types a message, hits send, and the message lands somewhere in an inbox. There is no structure to it. You cannot tell what service someone wants, what their budget looks like, or how urgent the project is until you open the email and read it line by line.

A quote request system fixes that. Instead of one open text box, you ask the questions that actually help you price and prioritize work: what kind of project this is, what the scope looks like, what budget range they have in mind, and how soon they need it done. Every submission arrives already sorted.

In this tutorial, we will build a complete quote request system in React. Not just a form, a full pipeline: a form component that collects structured project details, client-side validation, a submit handler that posts to a backend, an instant email notification, and a lead management view where we can track every request from New to Contacted to Converted.

Here is the architecture we are building:

Form Component -> Validation -> Submit -> Backend API -> Email Notification -> Lead Management

The frontend is plain React. For the backend, email notification, and lead management pieces, you will use Formgrid, an open-source form backend, so you can focus this tutorial on the part that actually needs your attention: building a form that captures the right information and converts.

What We Are Building

A multi-field quote request form in React with:

Full name, email, company, and phone fields
A radio group for the type of work being quoted
A textarea for project scope
Radio groups for budget range and timeline
Client-side validation before anything gets submitted
A loading state while the request is in flight
A success state once the request lands

On the backend side, every submission becomes:

An instant email notification to your inbox
A row in your Formgrid submissions dashboard
A tracked lead with a status of New, which you can move to Contacted or Converted, add notes to, and set a follow-up reminder on

No server code. No database. No separate CRM.

The full code for this tutorial is available on GitHub if you want to clone it and follow along, or just skip ahead and run it directly: github.com/allenarduino/react-quote-request-system.

Prerequisites

Before starting, make sure you have:

Node.js 18 or higher installed
Basic familiarity with React and hooks
A free Formgrid account (you will create one during this tutorial)

Step 1: Set Up the React Project

Create a new React project using Vite:

npm create vite@latest quote-request-system -- --template react
cd quote-request-system
npm install
npm run dev

Open the local dev server URL in your browser and confirm the default page loads.

Step 2: Create Your Formgrid Form

Set up your Formgrid form before writing any component code, so you have the endpoint URL ready to drop in later.

Go to formgrid.dev and sign up using Google or email. No credit card required.

Once you are logged in, click New Form from your dashboard and name it something like "Quote Requests." Click Create Form.

You will land on the form's Overview tab. Copy your endpoint URL. It looks like this:

https://formgrid.dev/api/f/your-form-id

Save this URL. You will use it in your submit handler in Step 5.

If you would rather start from a template than build the fields from scratch, Formgrid also has a Quote Request template with this exact field set already built, including the multi-step layout. You can open it in the anonymous builder at
Quote Request Form Nocode Template and customize it without creating an account first. You can later embed it in your website.

This tutorial builds the form by hand in React so you understand every piece, but the template is there if you want a shortcut for the Formgrid side of things.

Step 3: Build the Project Structure

Inside src, create a components folder and a QuoteRequestForm.jsx file inside it:

src/
  components/
    QuoteRequestForm.jsx
    QuoteRequestForm.css
  App.jsx

Open App.jsx and replace its contents with:

import { useMemo, useState } from 'react';
import './QuoteRequestForm.css';

const FORMGRID_ENDPOINT = 'https://formgrid.dev/api/f/brcy3qd4';

const HERO_IMAGE =
    'https://images.unsplash.com/photo-1521737604893-d14cc237f11d?auto=format&fit=crop&w=1400&q=80';

const initialState = {
    company: '',
    fullName: '',
    email: '',
    phone: '',
    quoteFor: '',
    budget: '',
    timeline: '',
    projectScope: '',
};

const quoteForOptions = [
    'Web design and development',
    'Branding and creative',
    'Marketing and advertising',
    'Construction or renovation',
    'Consulting or professional services',
    'Other',
];

const budgetOptions = [
    'Under $5,000',
    '$5,000 – $15,000',
    '$15,000 – $50,000',
    '$50,000+',
    'Not sure yet',
];

const timelineOptions = [
    'ASAP — within 2 weeks',
    'Within 1 month',
    'Within 3 months',
    'Flexible: No fixed deadline',
];

const requiredFields = ['fullName', 'email', 'quoteFor', 'budget', 'projectScope'];

export default function QuoteRequestForm() {
    const [formData, setFormData] = useState(initialState);
    const [errors, setErrors] = useState({});
    const [status, setStatus] = useState('idle');

    const filledCount = useMemo(
        () => requiredFields.filter((key) => formData[key].trim() !== '').length,
        [formData],
    );
    const progress = Math.round((filledCount / requiredFields.length) * 100);

    function handleChange(e) {
        const { name, value } = e.target;
        setFormData((prev) => ({ ...prev, [name]: value }));
        if (errors[name]) {
            setErrors((prev) => ({ ...prev, [name]: undefined }));
        }
    }

    function validate() {
        const nextErrors = {};

        if (!formData.fullName.trim()) nextErrors.fullName = 'Please enter your name';

        if (!formData.email.trim()) {
            nextErrors.email = 'Email is required';
        } else if (!/^\S+@\S+\.\S+$/.test(formData.email)) {
            nextErrors.email = 'Enter a valid email address';
        }

        if (!formData.quoteFor) nextErrors.quoteFor = 'Select what you need';
        if (!formData.budget) nextErrors.budget = 'Select an estimated budget';
        if (!formData.projectScope.trim()) nextErrors.projectScope = 'Tell us about your project';

        setErrors(nextErrors);
        return Object.keys(nextErrors).length === 0;
    }

    async function handleSubmit(e) {
        e.preventDefault();
        if (!validate()) return;

        setStatus('sending');

        try {
            const res = await fetch(FORMGRID_ENDPOINT, {
                method: 'POST',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ formData }),
            });

            if (res.ok) {
                setStatus('success');
                setFormData(initialState);
            } else {
                setStatus('error');
            }
        } catch {
            setStatus('error');
        }
    }

    if (status === 'success') {
        return (
            <div className="qf-card qf-success">
                <div className="qf-success__badge" aria-hidden="true">
                    <svg viewBox="0 0 24 24" width="34" height="34" fill="none">
                        <path
                            d="m5 13 4 4L19 7"
                            stroke="currentColor"
                            strokeWidth="2.4"
                            strokeLinecap="round"
                            strokeLinejoin="round"
                        />
                    </svg>
                </div>
                <h2>Request received</h2>
                <p>
                    Thanks! We've got your details and will send a tailored quote within 2
                    business days.
                </p>
                <button
                    type="button"
                    className="qf-btn qf-btn--ghost"
                    onClick={() => setStatus('idle')}
                >
                    Submit another request
                </button>
            </div>
        );
    }

    return (
        <div className="qf-card">
            <header className="qf-topbar">
                <div>
                    <p className="qf-topbar__title">Quote Request Form</p>
                    <p className="qf-topbar__hint">
                        Fill in all required fields marked with <span className="qf-req">*</span>
                    </p>
                </div>
                <div className="qf-progress" aria-hidden="true">
                    <span className="qf-progress__label">
                        {filledCount} of {requiredFields.length} required fields filled
                    </span>
                    <span className="qf-progress__track">
                        <span className="qf-progress__bar" style={{ width: `${progress}%` }} />
                    </span>
                </div>
            </header>

            <div className="qf-hero">
                <h1>Request a quote</h1>
                <p>
                    Tell us about your project and we&apos;ll send a tailored quote within 2 business
                    days. No commitment required.
                </p>
                <div className="qf-hero__image">
                    <img src={HERO_IMAGE} alt="Two colleagues collaborating at a desk" />
                </div>
            </div>

            <form className="qf-form" onSubmit={handleSubmit} noValidate>
                <section className="qf-section">
                    <h2 className="qf-section__title">Contact details</h2>
                    <div className="qf-grid">
                        <div className="qf-field">
                            <label htmlFor="company">Company</label>
                            <input
                                id="company"
                                name="company"
                                type="text"
                                placeholder="Acme Inc."
                                value={formData.company}
                                onChange={handleChange}
                            />
                        </div>

                        <div className="qf-field">
                            <label htmlFor="fullName">
                                Your name <span className="qf-req">*</span>
                            </label>
                            <input
                                id="fullName"
                                name="fullName"
                                type="text"
                                placeholder="Jane Smith"
                                aria-invalid={Boolean(errors.fullName)}
                                value={formData.fullName}
                                onChange={handleChange}
                            />
                            {errors.fullName && <span className="qf-error">{errors.fullName}</span>}
                        </div>

                        <div className="qf-field">
                            <label htmlFor="email">
                                Email <span className="qf-req">*</span>
                            </label>
                            <input
                                id="email"
                                name="email"
                                type="email"
                                placeholder="you@company.com"
                                aria-invalid={Boolean(errors.email)}
                                value={formData.email}
                                onChange={handleChange}
                            />
                            {errors.email && <span className="qf-error">{errors.email}</span>}
                        </div>

                        <div className="qf-field">
                            <label htmlFor="phone">Phone</label>
                            <input
                                id="phone"
                                name="phone"
                                type="tel"
                                placeholder="+1 (555) 000-0000"
                                value={formData.phone}
                                onChange={handleChange}
                            />
                        </div>
                    </div>
                </section>

                <div className="qf-divider" />

                <section className="qf-section">
                    <h2 className="qf-section__title">Project details</h2>

                    <div className="qf-field">
                        <label htmlFor="quoteFor">
                            What do you need? <span className="qf-req">*</span>
                        </label>
                        <div className="qf-select">
                            <select
                                id="quoteFor"
                                name="quoteFor"
                                aria-invalid={Boolean(errors.quoteFor)}
                                value={formData.quoteFor}
                                onChange={handleChange}
                            >
                                <option value="" disabled>
                                    Select…
                                </option>
                                {quoteForOptions.map((option) => (
                                    <option key={option} value={option}>
                                        {option}
                                    </option>
                                ))}
                            </select>
                            <svg
                                className="qf-select__chevron"
                                viewBox="0 0 24 24"
                                width="18"
                                height="18"
                                aria-hidden="true"
                            >
                                <path
                                    d="m6 9 6 6 6-6"
                                    stroke="currentColor"
                                    strokeWidth="2"
                                    fill="none"
                                    strokeLinecap="round"
                                    strokeLinejoin="round"
                                />
                            </svg>
                        </div>
                        {errors.quoteFor && <span className="qf-error">{errors.quoteFor}</span>}
                    </div>

                    <fieldset className="qf-field qf-fieldset">
                        <legend>
                            Estimated budget <span className="qf-req">*</span>
                        </legend>
                        <div className="qf-radios">
                            {budgetOptions.map((option) => (
                                <label
                                    key={option}
                                    className={`qf-radio ${formData.budget === option ? 'is-selected' : ''
                                        }`}
                                >
                                    <input
                                        type="radio"
                                        name="budget"
                                        value={option}
                                        checked={formData.budget === option}
                                        onChange={handleChange}
                                    />
                                    <span>{option}</span>
                                </label>
                            ))}
                        </div>
                        {errors.budget && <span className="qf-error">{errors.budget}</span>}
                    </fieldset>

                    <div className="qf-field">
                        <label htmlFor="timeline">When do you need to start?</label>
                        <div className="qf-select">
                            <select
                                id="timeline"
                                name="timeline"
                                value={formData.timeline}
                                onChange={handleChange}
                            >
                                <option value="" disabled>
                                    Select…
                                </option>
                                {timelineOptions.map((option) => (
                                    <option key={option} value={option}>
                                        {option}
                                    </option>
                                ))}
                            </select>
                            <svg
                                className="qf-select__chevron"
                                viewBox="0 0 24 24"
                                width="18"
                                height="18"
                                aria-hidden="true"
                            >
                                <path
                                    d="m6 9 6 6 6-6"
                                    stroke="currentColor"
                                    strokeWidth="2"
                                    fill="none"
                                    strokeLinecap="round"
                                    strokeLinejoin="round"
                                />
                            </svg>
                        </div>
                    </div>

                    <div className="qf-field">
                        <label htmlFor="projectScope">
                            Describe your project <span className="qf-req">*</span>
                        </label>
                        <textarea
                            id="projectScope"
                            name="projectScope"
                            rows={5}
                            placeholder="Share goals, deliverables, timeline, references, or links to inspiration…"
                            aria-invalid={Boolean(errors.projectScope)}
                            value={formData.projectScope}
                            onChange={handleChange}
                        />
                        {errors.projectScope && (
                            <span className="qf-error">{errors.projectScope}</span>
                        )}
                    </div>
                </section>

                {status === 'error' && (
                    <p className="qf-alert" role="alert">
                        Something went wrong while sending your request. Please try again.
                    </p>
                )}

                <button type="submit" className="qf-btn" disabled={status === 'sending'}>
                    {status === 'sending' ? 'Sending…' : 'Submit quote request'}
                </button>
            </form>
        </div>
    );
}

Replace FORMGRID_ENDPOINT with the endpoint URL you copied in Step 2.

Step 5: Style the Form

Create src/components/QuoteRequestForm.css:

.qf-card {
  width: 100%;
  max-width: 860px;
  margin: 0 auto;
  background: var(--app-bg);
  border-radius: 18px;
  overflow: hidden;
}

/* Top bar */
.qf-topbar {
  display: flex;
  align-items: flex-start;
  justify-content: space-between;
  gap: 16px;
  padding: 18px 28px;
  border-bottom: 1px solid var(--border);
  background: transparent;
}

.qf-topbar__title {
  font-size: 14px;
  font-weight: 700;
  color: var(--text-h);
  letter-spacing: 0.1px;
}

.qf-topbar__hint {
  font-size: 12.5px;
  color: var(--text-muted);
  margin-top: 2px;
}

.qf-progress {
  text-align: right;
  min-width: 190px;
}

.qf-progress__label {
  display: block;
  font-size: 12px;
  color: var(--text-muted);
  margin-bottom: 6px;
}

.qf-progress__track {
  display: block;
  height: 6px;
  border-radius: 999px;
  background: #eef1f6;
  overflow: hidden;
}

.qf-progress__bar {
  display: block;
  height: 100%;
  border-radius: 999px;
  background: linear-gradient(90deg, var(--accent), #4f8bff);
  transition: width 0.35s ease;
}

/* Hero */
.qf-hero {
  padding: 34px 28px 8px;
}

.qf-hero h1 {
  font-family: var(--heading);
  font-size: 32px;
  line-height: 1.15;
  font-weight: 800;
  letter-spacing: -0.6px;
  color: var(--text-h);
  margin: 0 0 10px;
}

.qf-hero p {
  font-size: 15px;
  line-height: 1.55;
  color: var(--text);
  max-width: 54ch;
}

.qf-hero__image {
  margin-top: 22px;
  border-radius: 14px;
  overflow: hidden;
  aspect-ratio: 16 / 8;
  background: #eef1f6;
}

.qf-hero__image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

/* Form layout */
.qf-form {
  padding: 26px 28px 30px;
}

.qf-section + .qf-divider {
  margin: 26px 0;
}

.qf-divider {
  height: 1px;
  background: var(--border);
}

.qf-section__title {
  font-family: var(--heading);
  font-size: 18px;
  font-weight: 700;
  letter-spacing: -0.2px;
  color: var(--text-h);
  margin: 0 0 18px;
}

.qf-grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 18px;
}

.qf-field {
  display: flex;
  flex-direction: column;
  gap: 7px;
  margin-bottom: 18px;
  min-width: 0;
}

.qf-grid .qf-field {
  margin-bottom: 0;
}

.qf-field:last-child {
  margin-bottom: 0;
}

label,
.qf-fieldset legend {
  font-size: 13.5px;
  font-weight: 600;
  color: var(--text-h);
  padding: 0;
}

.qf-req {
  color: var(--danger);
  font-weight: 700;
}

/* Inputs */
.qf-field input[type='text'],
.qf-field input[type='email'],
.qf-field input[type='tel'],
.qf-field textarea,
.qf-select select {
  width: 100%;
  padding: 11px 13px;
  font-family: inherit;
  font-size: 14px;
  color: var(--text-h);
  background: var(--field-bg);
  border: 1px solid var(--border-strong);
  border-radius: 10px;
  transition: border-color 0.15s ease, box-shadow 0.15s ease;
  appearance: none;
}

.qf-field textarea {
  resize: vertical;
  min-height: 120px;
  line-height: 1.5;
}

.qf-field input::placeholder,
.qf-field textarea::placeholder {
  color: var(--text-muted);
}

.qf-field input:hover,
.qf-field textarea:hover,
.qf-select select:hover {
  border-color: #b6bfcd;
}

.qf-field input:focus,
.qf-field textarea:focus,
.qf-select select:focus {
  outline: none;
  border-color: var(--accent);
  box-shadow: 0 0 0 4px var(--ring);
}

.qf-field input[aria-invalid='true'],
.qf-field textarea[aria-invalid='true'],
.qf-select select[aria-invalid='true'] {
  border-color: var(--danger);
}

/* Select */
.qf-select {
  position: relative;
}

.qf-select select {
  padding-right: 40px;
  cursor: pointer;
}

.qf-select__chevron {
  position: absolute;
  right: 12px;
  top: 50%;
  transform: translateY(-50%);
  color: var(--text-muted);
  pointer-events: none;
}

/* Radios */
.qf-fieldset {
  border: none;
  margin: 0 0 18px;
  padding: 0;
}

.qf-fieldset legend {
  margin-bottom: 10px;
}

.qf-radios {
  display: grid;
  gap: 8px;
}

.qf-radio {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 11px 13px;
  border: 1px solid var(--border-strong);
  border-radius: 10px;
  font-size: 14px;
  font-weight: 500;
  color: var(--text-h);
  cursor: pointer;
  transition: border-color 0.15s ease, background 0.15s ease, box-shadow 0.15s ease;
}

.qf-radio:hover {
  border-color: #b6bfcd;
}

.qf-radio input {
  accent-color: var(--accent);
  width: 16px;
  height: 16px;
  margin: 0;
}

.qf-radio.is-selected {
  border-color: var(--accent);
  background: var(--accent-soft);
  box-shadow: 0 0 0 1px var(--accent) inset;
}

/* Note + alerts */
.qf-note {
  display: flex;
  align-items: center;
  gap: 8px;
  margin: 22px 0 20px;
  font-size: 13px;
  color: var(--text-muted);
}

.qf-note svg {
  color: var(--success);
  flex-shrink: 0;
}

.qf-alert {
  margin-bottom: 16px;
  padding: 12px 14px;
  border-radius: 10px;
  background: rgba(220, 38, 38, 0.08);
  border: 1px solid rgba(220, 38, 38, 0.25);
  color: var(--danger);
  font-size: 13.5px;
  font-weight: 500;
}

.qf-error {
  color: var(--danger);
  font-size: 12.5px;
  font-weight: 500;
}

/* Button */
.qf-btn {
  width: 100%;
  padding: 14px 20px;
  border: none;
  border-radius: 12px;
  background: var(--primary);
  color: #fff;
  font-family: inherit;
  font-size: 15px;
  font-weight: 600;
  letter-spacing: 0.1px;
  cursor: pointer;
  transition: background 0.15s ease, transform 0.05s ease, box-shadow 0.15s ease;
  box-shadow: 0 8px 20px -8px rgba(31, 42, 68, 0.55);
}

.qf-btn:hover:not(:disabled) {
  background: var(--primary-hover);
}

.qf-btn:active:not(:disabled) {
  transform: translateY(1px);
}

.qf-btn:focus-visible {
  outline: none;
  box-shadow: 0 0 0 4px var(--ring);
}

.qf-btn:disabled {
  opacity: 0.65;
  cursor: not-allowed;
}

.qf-btn--ghost {
  background: transparent;
  color: var(--text-h);
  border: 1px solid var(--border-strong);
  box-shadow: none;
  width: auto;
  padding: 11px 20px;
  margin-top: 20px;
}

.qf-btn--ghost:hover:not(:disabled) {
  background: #f4f6fa;
}

/* Success */
.qf-success {
  padding: 48px 32px 40px;
  text-align: center;
}

.qf-success__badge {
  width: 64px;
  height: 64px;
  margin: 0 auto 18px;
  border-radius: 50%;
  display: grid;
  place-items: center;
  background: rgba(22, 163, 74, 0.12);
  color: var(--success);
}

.qf-success h2 {
  font-family: var(--heading);
  font-size: 24px;
  font-weight: 700;
  color: var(--text-h);
  margin: 0 0 8px;
}

.qf-success p {
  font-size: 15px;
  color: var(--text);
  max-width: 46ch;
  margin: 0 auto;
  line-height: 1.55;
}

/* Responsive */
@media (max-width: 640px) {
  .qf-topbar {
    flex-direction: column;
    padding: 16px 18px;
  }

  .qf-progress {
    text-align: left;
    width: 100%;
    min-width: 0;
  }

  .qf-hero,
  .qf-form {
    padding-left: 18px;
    padding-right: 18px;
  }

  .qf-hero h1 {
    font-size: 26px;
  }

  .qf-grid {
    grid-template-columns: 1fr;
  }
}

At this point, run npm run dev and fill out the form. Submitting it sends a POST request straight to your Formgrid endpoint.

Step 6: Confirm the Submission Arrives

Fill in the form with real-looking test data and click Request Quote.

Within seconds, three things happen.

First, an email notification arrives at the address you signed up with, containing every field from the submission formatted cleanly.

Second, the same submission appears in your Leads tab with a status of New. This is the part a plain email notification cannot give you.

If both show up, your quote request system is working end to end.

Step 7: Work the Lead, Not Just the Submission

Open the lead you just created in your dashboard.

Change its status from New to Contacted once you have reached out. When the project actually closes, move it to Converted. Your conversion rate updates automatically as you work through leads, so over time you know what fraction of quote requests turn into paying work, not just how many people filled in the form.

Add a private note after every call. What they asked for, what you quoted, what the next step is.

Spoke on the phone Tuesday. Wants the full 6- to 8-page site plus blog. Quoted $9,500.
Waiting on her to confirm the October trade show date before we lock the timeline.

Set a follow-up reminder for a date in the future. Formgrid emails you on that date with the lead's details and your notes attached, so you never lose track of a quote you sent out.

This is the part that separates a form that just collects submissions from a system that actually helps you close work. A quote request that goes cold because nobody followed up is a lost project. A tracked lead with a reminder attached is not.

The follow-up reminder email is sent.

Step 8: Add Spam Protection

Before this goes live, turn on spam protection from your form settings.

Go to your form's Settings tab and scroll to Security Settings. You can enable a honeypot field, CAPTCHA, rate limiting, or restrict submissions to your own domain.

If you would rather add a honeypot manually in your React form, add a hidden input and check it before sending the request:

<input
  type="text"
  name="_honey"
  style={{ display: 'none' }}
  tabIndex={-1}
  autoComplete="off"
/>

Then in handleSubmit, bail out early if it has a value, since a real visitor will never fill in a field they cannot see.

Step 9: Sync to Google Sheets

If you want your whole team to see quote requests without logging into Formgrid, connect Google Sheets from your form's Integrations tab.

Every submission from this point on adds a new row automatically, with columns that match your form fields exactly. No Zapier, no manual export.

Why Not Just Use a Plain Contact Form

A single message box is faster to build, but it pushes all the sorting work onto you after the fact. You have to read every message to figure out what someone actually wants, guess at their budget, and manually track who you have followed up with, usually in your own head or a scattered set of email threads.

A structured quote request form does that sorting up front. By the time a request lands in your inbox, you already know the service, the scope, the budget range, and the timeline. Paired with a lead pipeline, you also know exactly where every request stands, instead of losing track of the ones that went quiet.

Deploying

Build the project for production:

npm run build

Deploy the dist folder to any static host; Vercel, Netlify, or Cloudflare Pages all work with zero configuration for a Vite project. Your form will keep working identically in production, since Formgrid handles the backend processing regardless of where the frontend is hosted.

Final Thoughts

A quote request form is a small amount of extra structure that pays off every time someone submits one. You spend less time reading and guessing, and more time responding with an actual number, because the information you need was collected upfront.

The React side of this tutorial is a form component, a validation function, and a fetch call. The part that turns it into a system, tracking who you have contacted, who converted, and who needs a follow-up, comes from Formgrid running underneath it.

If you want to build this for your own site, start free at formgrid.dev. The form backend, email notifications, and lead pipeline are all included from day one.

👉 Try Formgrid free at formgrid.dev

Contact Form vs Client Intake Form: Which One Should Your Business Use?

Allen Jones — Tue, 21 Jul 2026 00:21:41 +0000

Still Using a Contact Form? The Real Question Is What Happens After Someone Clicks Submit.

If you're comparing a contact form and a client intake form, it's easy to focus on the number of fields.

A contact form might have four questions.

A client intake form might have fifteen.

But that's not the real difference.

The real question is:

How much information does your business actually need before you can help a customer?

Most businesses start with a simple contact form.

Someone enters their name, email address, phone number, and a short message.

You receive an email notification.

The conversation begins.

For many businesses, that's exactly how it should work.

But if you provide professional services—whether you're a lawyer, accountant, consultant, photographer, roofing contractor or marketing agency—you've probably noticed something.

Almost every enquiry is followed by another email.

Thanks for reaching out.

Could you tell us a little more about your project?

Then another.

Do you have any photos?

Then another.

What's your budget?

Then another.

When do you need this completed?

By the time you've gathered enough information to schedule a consultation, you've exchanged several emails that could have been avoided.

That's where a client intake form makes all the difference.

Instead of collecting a message, it collects the information your business needs before the first conversation even begins.

In this guide, you'll learn:

The difference between a contact form and a client intake form
Which one your business should use
Examples from different industries
Common mistakes to avoid
How to build an effective client intake process

Build a Client Intake Form in Minutes

Skip the blank page.

Start with a free Client Intake Form template, customize it for your business, and publish it in minutes.

👉 Try the Client Intake Form Template

What Is a Contact Form?

A contact form exists for one simple purpose:

To let people contact you.

It usually contains only a handful of fields:

Name
Email address
Phone number
Message

That's enough for:

General enquiries
Support requests
Partnership opportunities
Customer feedback
Simple questions

Because it's short, visitors can complete it quickly.

That's why contact forms work so well on:

Restaurant websites
Personal portfolios
SaaS support pages
Small business websites
Community organisations

The goal isn't to qualify the visitor.

It's simply to start a conversation.

What Is a Client Intake Form?

A client intake form serves a different purpose.

Instead of asking visitors to "leave a message", it collects the information your business needs before deciding what happens next.

Think about the questions you normally ask during your first phone call.

Those are usually the questions your intake form should ask.

For example...

A law firm might ask:

What type of legal matter is this?
Have you spoken with another attorney?
Are there any important deadlines?
Can you upload supporting documents?

A roofing company might ask:

What type of roofing service do you need?
Is the property residential or commercial?
Can you upload photos of the roof?
When would you like the work completed?

A marketing agency might ask:

What's your website?
What's your monthly marketing budget?
Which services are you interested in?
What's your biggest challenge?

Instead of receiving a vague message like:

"I'd like a quote."

Your team receives enough information to prepare a meaningful response.

See What a Modern Intake Form Looks Like

Reading about client intake forms is one thing.

Seeing one in action is another.

Open our free Client Intake Form template to see how multi-step forms, file uploads, and confirmation emails work together.

👉 Preview the Client Intake Template

The Biggest Difference

Many people think the biggest difference is the number of fields.

It isn't.

It's the purpose.

A contact form starts a conversation.

A client intake form prepares for one.

That's a huge distinction.

Imagine someone submits this contact form.

Name: Sarah

Message:

"I need legal help."

Now someone has to reply asking:

What happened?
Which type of case?
Do you have documents?
Is there a deadline?
What's your preferred contact method?

Several emails later, you've finally gathered enough information to schedule a consultation.

Now imagine Sarah completed a client intake form instead.

Your team immediately receives:

Contact information
Practice area
Description of the legal issue
Important dates
Supporting documents

Nothing about your expertise changed.

Only your workflow.

Instead of collecting information, your team starts solving problems.

That's the real advantage of client intake.

Contact Form vs Client Intake Form

Contact Form	Client Intake Form
Starts conversations	Prepares for conversations
Collects basic contact details	Collects structured client information
Usually 3–5 fields	Questions tailored to your business
Good for general enquiries	Best for consultations and quotes
Often requires follow-up emails	Reduces back-and-forth communication
Rarely includes file uploads	Often supports file uploads
Simple and fast	More detailed and more useful

Neither one is better.

They're simply designed for different situations.

If visitors only need a way to reach you, a contact form is perfect.

If every enquiry leads to the same five follow-up questions, you've probably outgrown a traditional contact form.

Best Form Builders in 2026: What Happens After Someone Submits a Form

Allen Jones — Tue, 14 Jul 2026 00:53:16 +0000

Building a Form From Scratch, or Still Comparing Builders?

Get a form backend for developers and a no-code builder for everyone else, in one tool, with a lead pipeline built in. Starts at $12 a month.

Create your free form

If you are looking for a form builder in 2026, you have many options, and most roundups make the choice seem harder than it is. The real question is not which builder has the most templates. It is what happens after someone fills out your form.

Most form builders stop at collecting a response. You get a submission, maybe an email, and then it is on you to remember who you followed up with, who converted, and who went quiet. That gap is the actual thing worth comparing across these tools, not just price and template count.

In this article, I will walk through the best form builders in 2026, covering price, features, and which one is right for your use case.

Short Version

If you want a form builder and a form backend in one tool, plus a way to track what happens to a submission after it arrives, use Formgrid. It starts at $12 a month.

If you need something completely free for simple internal use and branding does not matter, Google Forms is genuinely the simplest option.

If you specifically need Typeform's conversational design polish or Jotform's payment and approval workflows, either is still a fine choice for that narrower use case.

Why the Builder You Pick Matters More Than It Seems

Here are the things worth checking before you commit to one:

Does it give you an HTML endpoint, or only a hosted form? If you already have a coded form, or one your AI coding assistant generated, most builders have nothing for you. You would have to rebuild it inside their editor.

What happens to a submission after it arrives? Most builders give you a flat list or an inbox. Almost none tell you who you have followed up with, who converted, or who needs a reminder.

Is the free plan actually usable, or just a funnel to get you to pay? Some free tiers are generous. Some cap you low enough that they only exist to get you to upgrade.

Can you self-host if you ever want to? If data ownership matters to you, most of these tools give you no path to run it yourself.

If any of that matters to you, keep reading.

The Best Form Builders in 2026

1. Formgrid: Form Builder, Form Backend, and Lead Pipeline in One Place

Formgrid is the only tool on this list that gives you a no-code drag and drop builder, an HTML form endpoint for developers, multi-step and conversational forms, and a full lead pipeline, all starting at $12 per month.

Best for: developers who want a form backend, non-technical users who need a shareable form link, and small businesses who want to manage leads without buying a full CRM.

What makes it different

Most form builders pick a lane. Either a no-code builder for people who do not want to touch code, or a bare backend for developers who already have their own form. Formgrid does not make you choose. When you create a form, you pick your path right away: build it with the drag and drop editor, or grab an endpoint URL for a form you already have.

On top of that, it adds something almost nothing on this list offers: every submission becomes a tracked lead, not just a response in a list.

How Annie uses it

Annie runs event registrations in San Diego. Before Formgrid, every signup landed in her inbox as a one-off email, and following up with attendees meant scrolling back through old messages trying to remember who she had already contacted. Now every registration becomes a lead in her pipeline automatically. She can see at a glance who she has followed up with, set reminders for people who have not responded, and export the full list when she needs it.

Option A: use your existing HTML form

<form
  action="https://formgrid.dev/api/f/your-form-id"
  method="POST"
>
  <input type="text" name="name" placeholder="Your Name" required />
  <input type="email" name="email" placeholder="Your Email" required />
  <textarea name="message" placeholder="Your Message"></textarea>
  <input type="text" name="_honey" style="display:none" />
  <button type="submit">Send Message</button>
</form>

Formgrid handles receiving submissions, sending email notifications, and storing the data. Your form stays exactly as it is.

Option B: start from a template, no account needed to try it

Head to the Formgrid templates page and open the Quote Request template. It is a multi-step form built for exactly the kind of lead capture most small businesses and freelancers need: contact details on the first step, project or service details on the second, and budget or timeline on the last.

You can try the anonymous builder right there in the browser. Change the headline, edit the steps, swap the color, and preview exactly what your visitor will see before you ever create an account. Only when you are happy with it do you click Save, at which point you are prompted to sign up. You can view and customize this template here.

You can also switch this same multi-step form into a conversational layout, one question at a time, with a progress bar and animated transitions between fields, the same style Typeform is known for. It is a toggle in the builder rather than a separate product, so you keep the same submissions, notifications, lead tracking, and Google Sheets sync either way.

Try the builder free. No account needed to start customizing.

Step 1: sign up and create a form

Head to formgrid.dev and sign up using Google or email. No credit card required.

Once logged in, you will land on your dashboard. Click New Form to get started, or open a template you already customized in the anonymous builder.

Step 2: choose your path

After creating your form, you will be taken to the form overview page, where you can either build with the drag and drop editor, opening it from a blank document or a template, or use the endpoint URL, which gives you the URL to point your existing HTML form at.

Step 3: build your form

Drag fields from the left panel onto the canvas: text fields, email fields, dropdowns, checkboxes, file uploads, and more. If you started from the Quote Request template, each step already has fields grouped logically, and you can add or remove a page break at any point.

Each field is fully customizable. Click any field to edit its label, placeholder, required status, and validation rules.

Step 4: customize your brand

Formgrid includes a color picker so you can match the form to your brand or your client's brand. Change the primary color, background, and button style directly in the builder.

If you are on the Premium plan, you can also connect a custom domain, so your shareable form link reads as forms.yourbusiness.com instead of formgrid.dev. Every form page also ships with proper OG and SEO meta tags out of the box, so links preview correctly when shared on LinkedIn, Slack, or WhatsApp.

Every form you share looks like it belongs to your brand, not like a generic third-party tool.

Step 5: preview and share

Once you are happy with the form, click Preview to see exactly how it looks to your users. When it is ready, click Share to get your shareable form link.

You can send that link via WhatsApp, email, SMS, or embed it on any website. No code, no hosting, just a link.

Step 6: configure settings

Go to the Settings tab on your form to:

Add notification email addresses. Notifications go to the address you signed up with by default, and you can add more if you want teammates or clients to be notified too
Enable captcha and bot protection, Cloudflare Turnstile for form builder forms and hCaptcha for HTML endpoint forms, on every plan including free
Set a custom redirect URL after submission

Step 7: get notified the moment someone submits, and see it as a lead

Every submission triggers an instant email notification to the addresses you added in Settings. You do not need to log in to your dashboard to know a form was filled out, but every submission also lands in your dashboard as a lead you can move through New, Contacted, and Converted.

The email includes every field the respondent submitted, formatted so you can scan it in a few seconds, along with the time it was submitted.

Step 8: work the lead, not just the submission

All submissions are stored in your Formgrid dashboard as leads, not just a static list. Go to the Submissions tab to view, search, filter, and export your data as a CSV, or open any individual lead to add a note, set a follow-up reminder, and update its status as you work it.

Try Formgrid free. No credit card required, and you will have this exact form live in under two minutes.

Every submission becomes a tracked lead, something most form builders have at no price

Most builders give you a list of responses. Formgrid gives you a pipeline. The moment a submission arrives, it shows up in your Leads tab as New.

All submissions live in your dashboard, searchable and exportable as CSV any time.

Move a lead to Contacted when you have followed up, Converted when it actually becomes a customer. Update several at once with bulk actions.

Add a private note after every call, so the next time you open that lead you know exactly where things left off.

Set a follow-up reminder for whenever it is actually needed.

On that date, Formgrid emails you with the lead's details and your notes attached, so you have everything you need before you follow up.

Your conversion rate updates automatically as you work through leads, so you actually know how your form is performing, not just how many submissions came in.

See what a tracked lead looks like, try Formgrid free. No credit card required.

Google Sheets sync, without Zapier

Every submission can automatically appear as a new row in your Google Sheet. No Zapier needed, no API setup. Connect your sheet once and every submission syncs instantly.

Turn your submissions into tracked leads. No credit card required.

Key features

No-code drag and drop form builder with shareable link
HTML form endpoint for developers with an existing form
Multi-step conversational forms on the free plan
Quote Request and other landing page templates, plus a blank form document mode for fully custom layouts
Built-in lead pipeline: New, Contacted, Converted
Notes and follow-up reminders on every lead
Conversion rate tracking
Free captcha and bot protection on all plans
Instant email notifications
File uploads
Google Sheets sync without Zapier
CSV export
Self-hostable with Docker
100% open source under MIT license
GDPR friendly, no tracking, no data selling

Pricing

Plan	Price	Submissions
Free	$0/month	50/month
Premium	$12/month	1,000/month
Business	$29/month	15,000/month

The bottom line: most form builders on this list give you either a no-code editor or a developer backend, and none of them track what happens after a submission arrives. Formgrid gives you both, plus a full lead pipeline, starting at $12 a month.

Try a template free. No account needed to start customizing.

2. Google Forms: Best Completely Free Option

Best for: anyone who needs a zero cost form for simple, low stakes use cases.

Completely free with no submission limits, and everyone already knows how to use it. If that is all you need, it is hard to argue against free.

Key features: completely free, unlimited responses, Google Sheets integration, basic conditional logic.

Pricing: free.

Tradeoff: no custom branding, no HTML form backend, no bot protection, no lead management. Looks like Google Forms, not your brand, so it is not well suited to professional client work.

3. Tally: Clean and Free, With a Catch for Developers

Best for: non-technical users who want a Typeform-like experience at a lower price.

Tally is a popular alternative with a clean, minimal interface, and the free plan is genuinely useful. But it is a hosted builder only, with no HTML endpoint for a form you have already coded, and multi-step forms are locked behind a $29 per month paid plan.

Key features: unlimited forms and responses on the free plan, conditional logic, file uploads on paid plan, Notion integration, embeddable forms.

Pricing: free plan available, paid plan at $29 per month.

Tradeoff: no HTML form backend, no self-hosting, no open source, no lead tracking after a response arrives, multi-step forms locked to the paid plan.

4. Typeform: Best for Conversational Surveys

Best for: marketers who want a beautiful conversational form experience for surveys and lead generation.

Typeform pioneered the one question at a time conversational format, and the design is genuinely polished. But the free plan is limited to 10 responses a month, and there is no HTML backend or lead management at any price.

Key features: conversational one question at a time format, beautiful design templates, logic jumps and conditional branching, payment integrations.

Pricing: free plan limited to 10 responses per month, paid plans start at $25 per month.

Tradeoff: very limited free plan, no HTML form backend, no self-hosting, no lead tracking, and the conversational format is no longer exclusive to Typeform.

5. Jotform: Best for Advanced Logic and Payments

Best for: businesses that need advanced form logic, payment integrations, and a full form management suite.

Jotform is the most feature-rich builder on this list: thousands of templates, payment integrations, conditional logic, approval workflows, PDF generation, and e-signatures.

Key features: thousands of templates, payment integrations including Stripe, PayPal, and Square, conditional logic, PDF generation, e-signatures, approval workflows.

Pricing: free plan available with 100 monthly responses, paid plans start at $34 per month.

Tradeoff: expensive at scale, no self-hosting, no open source, no HTML form backend, significant overkill for most small businesses.

6. Paperform: Best for Beautiful Landing Page Forms

Best for: creators and marketers who want a form that feels like a branded page rather than a generic form.

Paperform focuses on beautiful landing page style forms with strong media embedding and payment support.

Key features: polished form design, payment integrations, conditional logic, calculator fields, media embedding.

Pricing: starts at $24 per month, no free plan.

Tradeoff: no free plan, no HTML form backend, no self-hosting, no open source, no lead management.

Side by Side Comparison

Feature	Formgrid	Google Forms	Tally	Typeform	Jotform	Paperform
Form builder	Yes	Yes	Yes	Yes	Yes	Yes
HTML endpoint	Yes	No	No	No	No	No
Multi-step forms	Free	No	Paid	Yes	Paid	Yes
Conversational one question format	Free	No	Paid	Paid	No	No
Lead pipeline	Yes	No	No	No	No	No
Follow up reminders	Yes	No	No	No	No	No
Built in captcha	Free	No	No	No	Paid	No
Google Sheets sync	Yes	Yes	Paid	Paid	Paid	Paid
Self-hostable	Yes	No	No	No	No	No
Open source	Yes	No	No	No	No	No
Free responses	50/month	Unlimited	Unlimited	10/month	100/month	None
Starting paid price	$12/month	Free	$29/month	$25/month	$34/month	$24/month
GDPR friendly	Yes	Partial	Partial	Partial	Partial	Partial

Which One Should You Use?

Use Formgrid if you want a form builder and an HTML backend in one tool, you have an existing coded form and do not want to rebuild it, you need to know what happened to a submission after it arrived, who you contacted, who converted, who needs a follow-up, you want multi-step or conversational forms without paying for a second tool, or you care about open source and self-hosting.

Use Google Forms if you need something completely free with unlimited responses and branding does not matter.

Use Tally if you want a clean, minimal form builder for free and do not need an HTML backend or lead tracking.

Use Typeform if you need a conversational one question at a time experience for surveys where visual design and completion rate are the top priority.

Use Jotform if you need advanced logic, payments, approval workflows, and PDF generation, and budget is not a constraint.

Use Paperform if visual design is your top priority and you need strong payment integration.

Final Thoughts

Every tool on this list can build you a form. The difference is what happens after someone fills it in.

Formgrid is the only one here that gives you a form backend for developers, a no-code builder for everyone else, and a lead pipeline that tracks what happens after a submission arrives, all in one place, starting at $12 a month.

Try a template for free. No account needed to start building.

Full disclosure: I built Formgrid. I wrote this comparison as honestly as I could. If anything looks inaccurate, let me know in the comments.

Why I Use Formgrid for Every Client Website I Build

Allen Jones — Wed, 17 Jun 2026 13:02:41 +0000

A few months ago, I was building a website for my web design agency at leadsgrid.co.

I had the homepage done. The services page was looking good. The industry landing pages were ready. Everything was working.

Then I got to the contact form.

The Problem Every Web Developer Hits

I needed a lead capture form on the site. Not just a contact form that sends me an email. A proper form that would:

Notify me immediately when someone enquires. Store every submission somewhere I could track it. Let me see which enquiries I had followed up on and which ones I had not. Tell me which marketing channel sent each lead.

I had built this before. I knew what it involved.

A PHP backend to receive the POST request. An email sending library to format and deliver the notification. A database to store submissions. A dashboard to view them. Spam protection so bots do not flood the inbox. Something to track UTM parameters.

I looked at my shared hosting on Namecheap. cPanel. PHP 8. MySQL.

I thought: I could build this.

Then I thought: I already built this. It is called Formgrid.

Why I Almost Did Not Use My Own Tool

Here is the thing about building a product. You spend so much time inside it, thinking about edge cases and user flows and feature gaps, that you sometimes forget to step back and see what it actually does.

I almost went down the cPanel route out of habit. The same habit that makes developers spin up a Node.js backend and configure Nodemailer for a contact form when a better option already exists.

What stopped me was a simple question:

If I were not the founder of Formgrid and I needed a form backend for a static agency site right now, what would I use?

The answer was obvious.

What I Actually Did

I pointed the enquiry form on leadsgrid.co at a Formgrid endpoint.

<form action="https://formgrid.dev/api/f/your-form-id" method="POST">
  <input type="text" name="name" placeholder="Your Name" required />
  <input type="email" name="email" placeholder="Your Email" required />
  <select name="package">
    <option value="">Choose a package</option>
    <option value="Lead Starter">Lead Starter $500</option>
    <option value="Lead Engine">Lead Engine $950</option>
    <option value="Lead Machine">Lead Machine $1,500</option>
  </select>
  <textarea name="message" placeholder="Tell me about your business"></textarea>
  <input type="text" name="_honey" style="display:none" tabindex="-1" autocomplete="off" />
  <button type="submit">Send Enquiry</button>
</form>

One attribute change. The form was live in two minutes.

No PHP. No cPanel. No database setup. No email configuration. No spam protection to wire up separately.

Every enquiry now arrives as an instant email notification.

Every submission lands in a shared Google Sheet my team can see without logging into anything.

Every lead appears in a pipeline where I can see its status, add notes, and set a follow-up reminder so nobody goes cold.

The Moment I Understood Why This Matters

A few weeks after launching leadsgrid.co, one of my clients received 13 real job enquiries on the same day his website went live.

He is a tree service business owner in the US. He set up two Formgrid forms on his own without any help from me. He drove his existing traffic to the new forms.

13 enquiries. Day one.

Every single one of those landed as a tracked lead. He could see which ones he had called, which ones had not answered yet, and which ones had booked a job.

Before Formgrid, he had a WordPress site with Contact Form 7. Submissions arrived by email. Some got buried. Some he forgot to follow up on. He had no way of knowing what happened to each enquiry after it arrived.

After Formgrid, he had a pipeline.

That is not a feature. That is the difference between running a business and guessing at one.

What Most Developers Do Instead

I have seen a lot of client websites. The pattern is almost always the same.

The developer builds a beautiful site. Fast. Clean. Well structured. Then they get to the contact form and do one of three things:

Option 1: Contact Form 7 on WordPress

Most service businesses still run on WordPress because that is what their previous developer knew. Contact Form 7 sends submissions to an email address. The email arrives. It gets mixed in with supplier invoices and newsletters and spam. The business owner replies when they can. There is no record of which leads were followed up on. Good enquiries go cold.

Option 2: A basic form that sends an email

The developer writes a PHP script or a serverless function that receives the form data and sends an email. Better than nothing. But the same problem: everything lives in the inbox. No pipeline. No tracking. No follow-up reminders.

Option 3: Recommend a CRM

The developer suggests HubSpot or Pipedrive. The business owner tries it for two weeks and gives up because it is too complex for what they actually need. They go back to managing leads by email.

None of these serve the client well. And the developer has to rebuild the same infrastructure from scratch on every new project.

Why I Now Use Formgrid on Every Client Site I Build

The answer is straightforward.

It is the same work whether I build it myself or use Formgrid. I still need to create the form, style it, write the copy, and test it. The only thing that changes is where the data goes after submit. Pointing the action at a Formgrid endpoint costs me nothing extra.

The client gets more than they expected. They came to me for a website. They leave with a website and a complete lead management system. Pipeline, Google Sheets sync, email notifications, follow-up reminders, source tracking. That is a significantly better deliverable than a website that sends form submissions to an email inbox.

I do not maintain it. Once the form is live and connected to Formgrid, it runs without me. I am not on call when the PHP mail function breaks. I am not reconfiguring SMTP settings when the hosting provider changes. I am not debugging spam issues. Formgrid handles all of that.

My clients actually use it. The pipeline is simple enough that non-technical business owners understand it immediately. New, Contacted, Converted. That is it. They log in, they see their leads, they move them through the stages. No training required.

What This Looks Like in Practice

Here is the exact setup I now use for every service business website I build:

The form collects the information the business actually needs to respond usefully. For a roofing company, that is: type of job, property address, photo of the damage, best time to call. For a photographer, that is: type of session, preferred date, mood board upload. For a restaurant that is: date, party size, occasion, dietary requirements.

The notification arrives the moment someone submits. Full details. Instant. The business owner sees it on their phone and can call back before the potential customer tries the next result on Google.

The Google Sheet updates automatically. Every submission becomes a new row. The whole team can see new leads in real time without logging into anything new. No copying from email. No manual data entry.

The pipeline tracks every lead from arrival to outcome. New when it arrives. Contacted when they reach out. Converted when it becomes a paying job. The business owner can see their conversion rate, spot which leads need follow-up, and never let a warm enquiry go cold because it got buried in an inbox.

The source tracking shows which marketing channel sent each lead. Google search, Facebook, referral, direct. After 30 days, the business owner knows exactly which marketing is actually sending paying customers.

The Result

Since I started doing this on every client site I build:

Clients ask fewer questions about what happened to their leads. Because they can see every lead in the pipeline with its current status.

Clients renew and refer more often. Because their website is visibly generating business for them, not just sitting there looking professional.

I spend less time on maintenance. Because Formgrid handles the form backend, spam protection, email delivery, and Google Sheets sync. I build the form once and move on.

My deliverable is better. A website with a complete lead system is worth more than a website with a contact form. The client knows it. I know it. And the price reflects it.

For Web Developers and Agencies

If you build websites for clients and you are still setting up WordPress contact forms or writing custom PHP form handlers for every project, there is a better way.

Point your form at Formgrid. Every client gets a complete lead management system included in the build. You charge more because you are delivering more. And you never think about form backends again.

If you want to set this up for your own agency site or for a client site right now, Formgrid is free to start with no credit card required.

Try Formgrid free at formgrid.dev

If you want the entire system set up for you, including the landing page, form, Google Sheets sync, and lead pipeline, that is what I offer at leadsgrid.co/services. Setup from $500. Most go live in 3 to 5 days.

I built Formgrid. I use it on every site I build. This post is my honest experience with it.

Formgrid vs Splitforms: Which Form Backend Is Right for You in 2026

Allen Jones — Tue, 16 Jun 2026 20:03:54 +0000

Splitforms and Formgrid are both form backends for developers building static sites. Both give you an endpoint URL, both send email notifications, and both have a submissions dashboard.

But they made fundamentally different product bets.

Splitforms optimized for price and free-tier generosity. Formgrid optimized for what happens after the submission arrives.

This post is the honest comparison. I built Formgrid, so I have a clear conflict of interest. I will do my best to be fair about where Splitforms wins and where it falls short.

What Both Tools Do

Both Formgrid and Splitforms solve the same core problem:

You built a static site on GitHub Pages,
Vercel, Netlify, or plain HTML.
Your contact form has nowhere to go.
Static sites have no server.
No server means no backend.
No backend means no way to process
form submissions natively.

Both tools give you:

An endpoint URL you point your HTML form at. A submissions dashboard to view what came in. Email notifications when someone submits. Spam protection. CSV export.

That is where the similarities end.

The Core Difference

Splitforms:
Form submits
Email arrives
Submission sits in a list
You manage everything else yourself

Formgrid:
Form submits
Email arrives
Submission becomes a tracked lead
Status: New
You contact them
Status: Contacted
They become a customer
Status: Converted
Conversion rate updates automatically

Splitforms stops at the inbox. Formgrid does not.

That is not a criticism of Splitforms. Stopping at the inbox is a deliberate product choice. For developers who just want form submissions handled and nothing else, it is exactly the right scope.

But for anyone running a business where those submissions represent potential customers, stopping at the inbox costs you money.

Splitforms: Where It Wins

Free tier

Splitforms has the most generous free tier of any form backend available in 2026.

Free: 1,000 submissions per month
      Unlimited forms
      Dashboard
      Webhooks included free
      AI spam filtering
      No credit card required

Formspree gives you 50 per month. Basin gives you 100. Web3Forms gives you unlimited but with no dashboard. Splitforms gives you 1,000 with a full dashboard and webhooks included.

If you are building personal projects, portfolio sites, or low-volume client sites and you genuinely just need form submissions handled cheaply, Splitforms is the best free option available right now.

Price

Splitforms Free: 1,000 submissions per month
Splitforms Pro: $5 per month for 5,000 submissions
Splitforms 3 Year: $59 one time for 15,000 per month

Formgrid Free: 25 submissions per month
Formgrid Premium: $12 per month for 1,000 submissions
Formgrid Business: $29 per month for 15,000 submissions

On price and submission volume per dollar, Splitforms wins clearly. There is no way around this.

If your only consideration is how many form submissions you can receive for the lowest possible cost, Splitforms is the better choice.

Webhooks on free plan

Splitforms includes webhooks on the free plan. Formspree paywalls webhooks at $10 per month. Formgrid includes webhooks on the Business plan at $29 per month.

If you want to forward submissions to Slack, Discord, or your own server for free, Splitforms wins here too.

Formgrid: Where It Wins

The lead pipeline

This is the feature that separates Formgrid from every other form backend on the market, including Splitforms.

Every submission that arrives through Formgrid automatically becomes a tracked lead with a status, a notes field, a follow-up reminder system, and conversion tracking.

Here is what the full flow looks like from form submission to tracked lead:

On each lead, you can:

Change status from New to Contacted to Converted. Add a private note about the conversation. Set a follow-up date and receive an email reminder on that day with the lead details and your notes attached. See where the lead came from using UTM source tracking.

Your conversion rate updates automatically at the top of the leads tab. 3 of 23 leads converted is 13 percent. That number tells you things a flat submissions list never could.

Splitforms has none of this. Its dashboard shows you a list of submissions. You manage everything after that yourself.

Google Sheets sync without Zapier

Formgrid syncs every submission to a Google Sheet automatically without Zapier at $12 per month. Splitforms does not include Google Sheets integration at any price point.

Every new submission appears as a new row in your connected sheet the moment it is received.

If you have a team that needs to see new submissions in real time without logging into anything new, this matters a lot.

A form builder with landing page templates

Formgrid is not just a form backend. It also includes a full drag-and-drop form builder with professionally designed landing page templates.

You can build a complete branded landing page with a form embedded inside it, share the link anywhere, and every submission still lands as a tracked lead in your dashboard.

Splitforms is a form backend only. There is no form builder and no shareable form link. You have to build your own form UI in HTML.

Multi-step conversational forms

Formgrid includes a built-in multi-step conversational form format. One question per screen. Clean design. Works on any device. No Typeform subscription needed.

Splitforms has no multi-step form capability.

Auto-responder emails

Formgrid includes auto-responder emails on the Premium plan. When someone submits your form, they receive an automatic confirmation email instantly.

Splitforms does not include auto-responder emails on any plan.

Open source and self-hostable

The entire Formgrid codebase is on GitHub under the MIT license. You can self-host on Docker for free with unlimited submissions.

Splitforms is not open source and is not self-hostable.

Side-by-Side Comparison

Feature	Splitforms	Formgrid
HTML form endpoint	Yes	Yes
Free submissions	1,000 per month	25 per month
Paid price	$5 per month	$12 per month
Submissions dashboard	Yes	Yes
Email notifications	Yes	Yes
Spam protection	AI spam free	Free all plans
Webhooks	Free	Business plan
Lead pipeline	No	Yes
Status tracking	No	Yes
Notes on leads	No	Yes
Follow-up reminders	No	Yes
Conversion tracking	No	Yes
Google Sheets sync	No	Yes ($12/mo)
Form builder	No	Yes
Landing page templates	No	Yes
Multi-step forms	No	Yes
Shareable form link	No	Yes
Auto-responder emails	No	Yes (Premium)
File uploads	No (Q3 2026 roadmap)	Yes
Open source	No	Yes
Self-hostable	No	Yes

The Honest Verdict

Use Splitforms if:

You just need form submissions handled cheaply and reliably. You have high volume and price is the primary concern. You want webhooks on the free plan. You are a developer who manages everything after the submission yourself. Personal projects, portfolios, and low-volume sites where the submissions do not represent business-critical leads.

Use Formgrid if:

You want to track what happens to submissions after they arrive. You want to know which leads you contacted, which ones converted, and which ones went cold. You need Google Sheets sync without Zapier. You want a form builder and shareable form links in addition to an HTML endpoint. You want auto-responder emails to confirm receipt to the person who submitted. You need file uploads. You care about open source and self-hosting. You are running a business where those form submissions represent potential customers you cannot afford to lose track of.

The Real Question

Both tools handle form submissions. The question is not which one receives form data better.

The question is: what do you do with those submissions after they arrive?

If the answer is "I just need to receive emails," Splitforms is excellent value and the best free tier available.

If the answer is "I need to follow up on these leads, track which ones converted, and never forget to reach out," Splitforms cannot help you with that. Formgrid can.

A Real Example

I built Formgrid after experiencing this problem myself.

While building my own agency website at leadsgrid.co I hit the same wall every developer hits. I had a contact form. It sent me emails. Those emails piled up. I lost track of which leads I had responded to. I forgot to follow up on warm enquiries. Good potential clients went cold because they slipped through the cracks of my inbox.

I needed a pipeline, not just an inbox.

One of my Formgrid customers is a tree service business in the US. He set up two forms on his website on his own without any help. On the same day they went live he received 13 real job enquiries. Every one of those enquiries arrived as a tracked lead in his pipeline. He could see which ones he had called, which ones had not responded yet, and which ones had become paying jobs.

That is the problem Formgrid solves. Splitforms does not try to solve it. That is neither good nor bad. They are different tools for different needs.

How to Switch to Formgrid From Splitforms

If you are on Splitforms and want to try Formgrid, switching takes about 5 minutes.

Create a free account at formgrid.dev. No credit card required.

Create a new form and copy your endpoint URL.

Update your HTML form action from your Splitforms URL to your Formgrid endpoint:

<!-- Before -->
<form action="https://splitforms.com/api/submit" method="POST">
  <input type="hidden" name="access_key" value="your-splitforms-key" />
  <input type="text" name="name" placeholder="Your Name" />
  <input type="email" name="email" placeholder="Your Email" />
  <textarea name="message" placeholder="Your Message"></textarea>
  <button type="submit">Send</button>
</form>

<!-- After -->
<form action="https://formgrid.dev/api/f/your-form-id" method="POST">
  <input type="text" name="name" placeholder="Your Name" />
  <input type="email" name="email" placeholder="Your Email" />
  <textarea name="message" placeholder="Your Message"></textarea>
  <input type="text" name="_honey" style="display:none" tabindex="-1" autocomplete="off" />
  <button type="submit">Send</button>
</form>

Submit a test form to confirm it is working.

That is it. Your form is live, and every new submission now arrives as a tracked lead.

Formgrid Pricing

Plan	Price	Submissions
Free	$0 per month	25 per month
Premium	$12 per month	1,000 per month
Business	$29 per month	15,000 per month

The free plan is enough to evaluate whether the lead pipeline is useful for your use case. Upgrade when your volume or needs grow.

Try Formgrid free at formgrid.dev No credit card required.

Full disclosure: I built Formgrid. I wrote this comparison as honestly as I could. If anything looks inaccurate, let me know in the comments.

How to Handle Form Submissions in Vue.js Without a Backend

Allen Jones — Tue, 16 Jun 2026 18:19:39 +0000

If you are building a Vue.js application and need to handle contact form submissions, the standard approach involves setting up a backend server, configuring email sending, managing environment variables, and deploying server-side code.

That is a lot of infrastructure for what is essentially a contact form.

In this tutorial, I will show you how to handle Vue.js form submissions without any backend using Formgrid. Every submission gets stored in a dashboard, triggers an instant email notification, becomes a tracked lead in a pipeline, and optionally syncs to Google Sheets automatically.

No server. No Node.js backend. No email configuration. Just a Vue.js form and a Formgrid endpoint URL.

What You Are Building

A fully functional contact form in Vue.js that:

Sends form data to Formgrid on submission. Triggers an instant email notification with the submission details. Stores every submission as a tracked lead in your Formgrid dashboard. Shows a loading state while submitting. Shows a success message after submission. Blocks bots with a honeypot field.

Prerequisites

Basic knowledge of Vue.js and JavaScript. A free Formgrid account at formgrid.dev.

Step 1: Create Your Vue.js Project

If you do not have a Vue.js project yet create one now:

npm create vue@latest vue-formgrid-contact
cd vue-formgrid-contact
npm install
npm run dev

Open localhost:5173 and confirm the default Vue.js page loads.

Step 2: Create Your Formgrid Account and Form

Go to formgrid.dev and sign up using Google or email. No credit card required.

Once logged in click New Form from your dashboard and give your form a name. Something like "Vue Contact Form" or "Website Enquiries". Click Create Form.

You will be taken to your form's Overview tab. Here you will find your unique Endpoint URL. Copy it. It looks like this:

https://formgrid.dev/api/f/your-form-id

This is the URL you will send your form data to. Every time someone submits your form the data goes to this endpoint and Formgrid emails you the submission details instantly.

Step 3: Create the Contact Form Component

In your Vue.js project create a new file called ContactForm.vue inside the src/components folder:

<!-- src/components/ContactForm.vue -->
<template>
  <div class="form-wrapper">
    <div v-if="submitted" class="success-message">
      <svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" fill="none" stroke="#0d9488" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" viewBox="0 0 24 24">
        <path d="M22 11.08V12a10 10 0 1 1-5.93-9.14"/>
        <polyline points="22 4 12 14.01 9 11.01"/>
      </svg>
      <h2>Message sent successfully</h2>
      <p>We will get back to you within 24 hours.</p>
    </div>

    <form v-else @submit.prevent="handleSubmit">
      <h2>Contact Us</h2>
      <p>Any questions or remarks? Just write us a message.</p>

      <div class="field">
        <label for="name">Name</label>
        <input
          id="name"
          v-model="form.name"
          type="text"
          placeholder="Allen Jones"
          required
        />
      </div>

      <div class="field">
        <label for="email">Email</label>
        <input
          id="email"
          v-model="form.email"
          type="email"
          placeholder="allen@example.com"
          required
        />
      </div>

      <div class="field">
        <label for="phone">Phone <span class="optional">(optional)</span></label>
        <input
          id="phone"
          v-model="form.phone"
          type="tel"
          placeholder="+1 555 000 0000"
        />
      </div>

      <div class="field">
        <label for="message">Message</label>
        <textarea
          id="message"
          v-model="form.message"
          placeholder="Write your message here"
          rows="5"
          required
        />
      </div>

      <!-- Honeypot field: hidden from real users, catches bots -->
      <input
        v-model="form.honeypot"
        type="text"
        name="_honey"
        style="display: none"
        tabindex="-1"
        autocomplete="off"
        aria-hidden="true"
      />

      <p v-if="error" class="error-message">{{ error }}</p>

      <button type="submit" :disabled="loading">
        {{ loading ? 'Sending...' : 'Send Message' }}
      </button>
    </form>
  </div>
</template>

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

const FORMGRID_ENDPOINT = 'https://formgrid.dev/api/f/your-form-id'

const form = reactive({
  name: '',
  email: '',
  phone: '',
  message: '',
  honeypot: ''
})

const loading = ref(false)
const submitted = ref(false)
const error = ref('')

async function handleSubmit() {
  // If honeypot is filled in it is a bot
  if (form.honeypot) return

  loading.value = true
  error.value = ''

  try {
    const response = await fetch(FORMGRID_ENDPOINT, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json'
      },
      body: JSON.stringify({
        name: form.name,
        email: form.email,
        phone: form.phone,
        message: form.message
      })
    })

    if (response.ok) {
      submitted.value = true
    } else {
      error.value = 'Something went wrong. Please try again.'
    }
  } catch {
    error.value = 'Something went wrong. Please try again.'
  } finally {
    loading.value = false
  }
}
</script>

<style scoped>
.form-wrapper {
  max-width: 540px;
  margin: 60px auto;
  padding: 40px;
  background: #ffffff;
  border-radius: 12px;
  box-shadow: 0 4px 24px rgba(0, 0, 0, 0.08);
  font-family: system-ui, sans-serif;
}

h2 {
  font-size: 1.5rem;
  font-weight: 700;
  color: #0d1117;
  margin: 0 0 8px;
}

p {
  color: #6b7a8d;
  font-size: 0.9rem;
  margin: 0 0 24px;
}

.field {
  margin-bottom: 20px;
}

label {
  display: block;
  font-size: 0.75rem;
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.1em;
  color: #0d1117;
  margin-bottom: 6px;
}

.optional {
  font-weight: 400;
  text-transform: none;
  letter-spacing: normal;
  color: #6b7a8d;
}

input,
textarea {
  width: 100%;
  padding: 10px 14px;
  border: 1px solid #e2e8f0;
  border-radius: 8px;
  font-size: 0.95rem;
  color: #0d1117;
  background: #f8f9fb;
  box-sizing: border-box;
  transition: border-color 0.15s ease;
  outline: none;
}

input:focus,
textarea:focus {
  border-color: #0d9488;
  background: #ffffff;
}

textarea {
  resize: vertical;
  min-height: 120px;
}

button {
  width: 100%;
  padding: 12px;
  background: #0d9488;
  color: #ffffff;
  border: none;
  border-radius: 8px;
  font-size: 0.875rem;
  font-weight: 600;
  letter-spacing: 0.05em;
  cursor: pointer;
  transition: background 0.15s ease;
  margin-top: 8px;
}

button:hover:not(:disabled) {
  background: #0f766e;
}

button:disabled {
  opacity: 0.65;
  cursor: not-allowed;
}

.error-message {
  color: #dc2626;
  font-size: 0.875rem;
  margin-bottom: 12px;
}

.success-message {
  text-align: center;
  padding: 20px 0;
}

.success-message svg {
  margin-bottom: 16px;
}

.success-message h2 {
  font-size: 1.25rem;
  color: #0d1117;
  text-align: center;
}

.success-message p {
  text-align: center;
  margin: 8px 0 0;
}
</style>

Replace your-form-id in the FORMGRID_ENDPOINT constant with the actual form ID from your Formgrid form overview tab.

Step 4: Use the Component in Your App

Open src/App.vue and import the ContactForm component:

<!-- src/App.vue -->
<template>
  <div>
    <ContactForm />
  </div>
</template>

<script setup>
import ContactForm from './components/ContactForm.vue'
</script>

Run your development server:

npm run dev

You should see the contact form at localhost:5173.

Step 5: Test the Form Submission

Fill in the form with real looking test data and click Send Message.

Within seconds you should see three things happen.

The success message appears on screen replacing the form.

You receive an instant email notification at your Formgrid signup address with the full submission details formatted cleanly:

New Submission: Vue Contact Form

Name: Allen Jones
Email: allen@example.com
Phone: +1 555 000 0000
Message: This is a test message from my Vue.js form.

Submitted: 10:30 AM, June 16, 2026

The submission appears in your Formgrid dashboard under the Submissions tab.

Step 6: View the Lead in Your Pipeline

This is where Formgrid goes beyond a basic form backend.

Every submission automatically becomes a tracked lead in your Formgrid dashboard. Go to the Leads tab and you will see your test submission with a status of New.

Here is what the full flow looks like from form submission to tracked lead:

Click on the lead and you can:

Change its status from New to Contacted when you reply. Change it to Converted when they become a customer. Add a private note about the conversation. Set a follow-up reminder so Formgrid emails you on a date you choose with the lead details and your notes attached.

Your conversion rate updates automatically at the top of the leads tab. That number tells you things a flat email inbox never could.

Step 7: Configure Form Settings

Go to the Settings tab on your form in the Formgrid dashboard to configure additional options.

From here you can:

Add multiple notification email addresses. Set a custom redirect URL after submission. Enable auto-responder emails to confirm receipt to the person who submitted. Enable hCaptcha for additional bot protection on top of the honeypot field already in your form.

Step 8: Connect Google Sheets (Optional)

If you want every form submission to appear automatically as a new row in a Google Sheet go to the Integrations tab on your form.

Connect your Google account and select the sheet where you want submissions to land. From that point every new submission creates a new row instantly with no Zapier required.

This is particularly useful if you have a team. Everyone with access to the sheet sees new submissions in real time without needing to log into anything new.

Google Sheets sync is available on the Premium plan at $12 per month.

How to Handle File Uploads

If you need users to upload files alongside the form you need to send multipart form data instead of JSON. Here is the updated handleSubmit function:

async function handleSubmit() {
  if (form.honeypot) return

  loading.value = true
  error.value = ''

  try {
    const formData = new FormData()
    formData.append('name', form.name)
    formData.append('email', form.email)
    formData.append('phone', form.phone)
    formData.append('message', form.message)

    if (form.file) {
      formData.append('file', form.file)
    }

    const response = await fetch(FORMGRID_ENDPOINT, {
      method: 'POST',
      headers: {
        'Accept': 'application/json'
      },
      body: formData
    })

    if (response.ok) {
      submitted.value = true
    } else {
      error.value = 'Something went wrong. Please try again.'
    }
  } catch {
    error.value = 'Something went wrong. Please try again.'
  } finally {
    loading.value = false
  }
}

Add the file field to your reactive form object and a file input to your template:

<div class="field">
  <label for="file">Attachment <span class="optional">(optional)</span></label>
  <input
    id="file"
    type="file"
    @change="form.file = $event.target.files[0]"
  />
</div>

File uploads up to 1GB are included on the Premium plan at $12 per month.

Using with the Options API

If you prefer the Options API instead of the Composition API here is the equivalent component:

<template>
  <!-- Same template as above -->
</template>

<script>
export default {
  name: 'ContactForm',
  data() {
    return {
      form: {
        name: '',
        email: '',
        phone: '',
        message: '',
        honeypot: ''
      },
      loading: false,
      submitted: false,
      error: ''
    }
  },
  methods: {
    async handleSubmit() {
      if (this.form.honeypot) return

      this.loading = true
      this.error = ''

      try {
        const response = await fetch(
          'https://formgrid.dev/api/f/your-form-id',
          {
            method: 'POST',
            headers: {
              'Content-Type': 'application/json',
              'Accept': 'application/json'
            },
            body: JSON.stringify({
              name: this.form.name,
              email: this.form.email,
              phone: this.form.phone,
              message: this.form.message
            })
          }
        )

        if (response.ok) {
          this.submitted = true
        } else {
          this.error = 'Something went wrong. Please try again.'
        }
      } catch {
        this.error = 'Something went wrong. Please try again.'
      } finally {
        this.loading = false
      }
    }
  }
}
</script>

Using with Nuxt.js

If you are using Nuxt.js instead of plain Vue.js the same component works without any changes. Nuxt.js is built on Vue.js and supports the same Composition API and Options API patterns.

The only difference is where you place the component file. In a Nuxt project put it in the components folder and Nuxt will auto-import it:

components/
  ContactForm.vue   // auto-imported by Nuxt

Use it in any page without importing:

<!-- pages/contact.vue -->
<template>
  <div>
    <ContactForm />
  </div>
</template>

Why Not Just Use a Backend?

You could set up an Express server, configure Nodemailer, deploy it to a VPS, and manage it yourself. Here is what that actually involves:

Setting up a Node.js server. Configuring email sending with an SMTP provider. Managing environment variables for email credentials. Deploying and maintaining the server. Handling server downtime and errors. Paying for server hosting.

Formgrid handles all of that for $12 per month on the Premium plan, plus gives you a lead pipeline, Google Sheets sync, and follow-up reminders that a custom backend would not include.

For a contact form on a Vue.js site, a backend is the wrong tool for the job.

Formgrid Pricing

Plan	Price	Submissions
Free	$0 per month	25 per month
Premium	$12 per month	1,000 per month
Business	$29 per month	15,000 per month

The free plan is enough to get started. Upgrade when your volume grows.

Conclusion

In this tutorial you built a fully functional Vue.js contact form that handles submissions without any backend code.

Every submission is:

Sent to Formgrid via a simple fetch request. Stored in a dashboard you can access any time. Emailed to your inbox instantly. Tracked as a lead in a pipeline with status, notes, and follow-up reminders. Optionally synced to Google Sheets automatically.

The entire setup takes about 10 minutes. No server to build. No email configuration. No infrastructure to maintain.

Try Formgrid free at formgrid.dev No credit card required.

Full disclosure: I built Formgrid. I wrote this tutorial as honestly as I could. If anything looks inaccurate or could be improved let me know in the comments.

Paperform Alternatives in 2026: Cheaper, Simpler, and With Actual Lead Management

Allen Jones — Mon, 15 Jun 2026 22:47:22 +0000

If you have been using Paperform and recently looked at your bill, you are not alone.

Paperform starts at $24 per month for the Essentials plan with only 100 submissions per month. The Pro plan is $59 per month. The Business plan is $129 per month. There is no free plan. Just a 7-day trial with no credit card required.

For a lot of developers, indie hackers, and small businesses, those numbers are hard to justify when the core need is a form that collects submissions, sends notifications, and helps you track what happens after.

In this article, I will walk through the best Paperform alternatives in 2026, covering price, features, self-hosting options, and which one is right for your use case.

Why People Look for Paperform Alternatives

Here are the most common reasons people switch:

No free plan. Paperform gives you a 7-day trial and then charges $24 per month. If you are evaluating tools or running a small project, there is no way to use Paperform without committing to a paid plan immediately.

Price jumps quickly. The Essentials plan at $24 per month only gives you 100 submissions per month. The moment your volume grows, you are paying $59 per month for Pro or $129 per month for Business. Those are significant jumps for what is essentially a form builder.

No HTML form backend. Paperform is a hosted form builder only. You cannot point your existing HTML form at a Paperform endpoint. If you have a static site or a custom-coded form, Paperform does not help you.

No lead management. Paperform collects submissions and shows you a results dashboard. It does not track which submissions you followed up on, which ones converted to customers, or which ones went cold. The submission arrives, and you are on your own.

No self-hosting. If you care about data ownership or GDPR compliance, Paperform gives you no option to run it yourself.

No open source option. You are locked in with no transparency and no ability to modify or audit the code.

Google Sheets requires the Pro plan. Paperform only includes Google Sheets integration from the Pro plan at $59 per month. If you are on Essentials, you need Zapier to connect your sheet.

If any of those hit home, keep reading.

The Best Paperform Alternatives in 2026

1. Formgrid: The Best Paperform Alternative for Developers and Small Businesses

Formgrid is the best Paperform alternative in 2026 because it is the only form tool that combines a drag-and-drop form builder with landing page templates, an HTML form backend for developers, multi-step conversational forms, a full lead pipeline with follow-up reminders and conversion tracking, free captcha bot protection, and Google Sheets sync at $12 per month with a genuine free plan. Paperform charges $24 per month for Essentials with 100 submissions and no free plan at all.

Best for: Developers who need an HTML form backend, small businesses who want to track leads without a CRM, event organisers who want a shareable professional form link, and anyone who wants a Paperform alternative that is both cheaper and more capable.

What makes it different:

Most form tools pick a lane. Either a form backend for developers or a no-code form builder for everyone else. Formgrid does both. And it adds something Paperform does not have at any price point: a lightweight lead management system built into every form, plus free captcha bot protection that requires no backend code to verify.

When a submission comes in, it does not just sit in a results dashboard. It becomes a tracked lead. You mark it as New, Contacted, or Converted. Add a note. Set a follow-up reminder, and Formgrid emails you on the day you choose with the lead details and your notes. See your conversion rate at a glance.

That is the difference between a form builder and a tool that actually helps you turn submissions into customers.

Two ways to use Formgrid:

Option A: Build a form with a landing page template or multi-step form

This is the most powerful thing Formgrid does that Paperform handles differently.

Instead of building in isolation, you choose a professionally designed landing page template, and your form is embedded inside a complete branded page. Or you choose the multi-step format for a one-question-at-a-time conversational experience.

Step 1: Sign up and create a form

Head to formgrid.dev and sign up with Google or your email address. No credit card required.

Once logged in, you land on your dashboard. Click New Form to get started.

Step 2: Open the form builder

After creating your form, you will be taken to the form details page. Click Open Builder to enter the form builder.

Step 3: Choose a template or multi-step form

At the top of the builder, click Choose Template. A gallery opens showing professionally designed landing page templates for different industries and use cases. One of those templates is the multi-step conversational form.

Templates available include Multi-Step Conversational Form, Horse Ride Registration, Event Registration, Wedding RSVP, Photography Booking, Cleaning Service Booking, Personal Trainer Enquiry, Real Estate Enquiry, Plumbing Quote Request, Job Application, and Blank Form.

Select the template that matches your use case, and Formgrid immediately loads a complete branded page with your form embedded inside it.

Multi-step conversational forms built in

Formgrid includes the same one-question-at-a-time conversational format on all plans, including free at no extra cost. One question per screen. Clean minimal design. Works on any device.

No Paperform or Typeform subscription needed. This is included in Formgrid at no extra cost.

Step 4: Edit the template inline

Every piece of text on the page is editable. Click directly on any text element, and it becomes editable in place.

Change the primary color using the color picker on the right panel, and the buttons, accents, and highlights across the entire page update instantly to match your brand.

Step 5: Customize your form fields

Switch to the Form Fields tab to add, remove, and reorder the fields in your form. Drag fields from the left sidebar onto the canvas. Every field is fully customizable with labels, placeholder text, required status, and validation rules.

Step 6: Share your form link

When you are happy with the page, click Save Changes. Go back to the form details page and copy your unique shareable link.

Share it anywhere: WhatsApp groups, email newsletters, Instagram bio, Facebook events, or embed it on your website.

Step 7: Receive instant email notifications

The moment someone submits the form, you receive an instant email notification with all their details formatted cleanly.

New Registration: Blue Ridge Endurance Classic 2026
Rider Name: Sarah Johnson
Email: sarah@email.com
Phone: (555) 123-4567
Horse Name: Midnight Storm
Division: 50 Mile
Experience: Advanced

No checking a spreadsheet. Every submission arrives in your inbox the moment it happens.

Step 8: View and manage submissions

All submissions are stored in your Formgrid dashboard. Go to the Submissions tab to view, search, filter, and export your complete list as a CSV file.

Step 9: Configure settings

Go to the Settings tab on your form to add notification email addresses, enable captcha and bot protection, set a custom redirect URL after submission, and configure auto-responder emails.

Step 10: Free captcha and bot protection

Formgrid includes Cloudflare Turnstile for form builder forms and hCaptcha for HTML endpoint forms at no extra cost on all plans, including free.

For form builder forms, Cloudflare Turnstile runs invisibly in the background. Real visitors see nothing. Bots are blocked silently before they ever reach your inbox.

Paperform uses reCAPTCHA, but coverage varies by plan. Formgrid includes bot protection free on every plan.

Step 11: Sync to Google Sheets automatically

Every submission can automatically appear as a new row in your Google Sheet. No Zapier needed. No API setup. Connect your sheet in one click.

Paperform only includes Google Sheets on the Pro plan at $59 per month. Formgrid includes it at $12 per month.

Step 12: Track every submission as a lead

This is where Formgrid goes beyond Paperform and every other tool on this list.

Paperform shows you a results dashboard. You see submissions. You can filter and export them. But there is no record of whether you followed up, whether the person became a customer, or what happened after they hit submit.

Formgrid turns every submission into a tracked lead automatically.

The moment a submission arrives, it appears in your Leads tab with a status of New. Move it through a simple pipeline: New to Contacted to Converted.

Here is what the full flow looks like from form submission to tracked lead:

On each lead, you can add a private note about the conversation, set a follow-up date, and receive an email reminder on that day with the lead details and your notes; see where the lead came from using UTM source tracking, and export all leads as CSV at any time.

Changing lead status

When you reply to a lead, change its status from New to Contacted. When they become a customer, change it to Converted.

Adding notes to every lead

After every conversation, add a private note directly on the lead.

Setting follow-up reminders

When someone asks you to follow up in two weeks, set a reminder directly on the lead. Pick a date. Click Set Reminder.

On that date, Formgrid emails you with the lead details and your notes so you have everything you need before you follow up.

Seeing your conversion rate

Your conversion rate updates automatically as you work through leads. 3 of 23 leads converted is 13 percent. That number tells you things a flat submissions list never could.

Paperform does not have any of this at any price point.

A real example

One of Formgrid's customers runs endurance horse riding events in San Diego. She was getting 15 to 20 registrations per month through a basic form. Submissions were landing in her inbox and getting buried.

She switched to Formgrid, connected her registration form to a horse ride landing page template, and every registration now appears as a tracked lead in her pipeline. After two months, she discovered that leads who received a reply within 4 hours converted at almost twice the rate of leads who waited a day or more. She would never have known that from a Paperform results dashboard.

"The level of personal support was impressive."
A. Libby, Event Manager, San Diego Endurance Riders

Option B: Use your existing HTML form

If you already have an HTML form on your website, just point it at your Formgrid endpoint URL:

<form action="https://formgrid.dev/api/f/your-form-id" method="POST">
  <input type="text" name="name" placeholder="Your Name" required />
  <input type="email" name="email" placeholder="Your Email" required />
  <textarea name="message" placeholder="Your Message"></textarea>
  <input type="text" name="_honey" style="display:none" />
  <button type="submit">Send Message</button>
</form>

Paperform has no equivalent of this. You cannot use Paperform with an existing HTML form. Formgrid works with any static site, any framework, and any custom-coded form.

Key features:

Drag and drop form builder with shareable link. Multi-step conversational forms built in. Landing page templates for different industries. Inline text editing on templates. HTML form endpoint for any static site. Built-in lead pipeline: New, Contacted, Converted. Notes and follow-up reminders on every lead. Conversion rate tracking. Free CAPTCHA and bot protection on all plans, including free. Instant email notifications. File uploads up to 1GB. Google Sheets sync without Zapier at $12 per month. CSV export. Auto-responder emails on Premium and Business plans. Webhooks on Business plan. Self-hostable with Docker. 100 percent open source under MIT license. GDPR friendly with no tracking and no data selling.

Pricing:

Plan	Price	Submissions
Free	$0 per month	50 per month
Premium	$12 per month	1,000 per month
Business	$29 per month	15,000 per month

The bottom line: Paperform charges $24 per month for 100 submissions with no free plan, no HTML form backend, no lead management, and Google Sheets only on the $59 plan. Formgrid gives you a form builder, an HTML backend, multi-step conversational forms, a full lead pipeline with follow-up reminders, free captcha protection, and Google Sheets sync for $12 per month with a real free plan.

Try Formgrid for free. No credit card required.

If you would rather have everything set up for you, including forms, Google Sheets sync, lead pipeline, and source tracking:

View done-for-you setup

2. Tally: Best Free Paperform Alternative for Non-Technical Users

Tally is a good free Paperform alternative for non-technical users who want a clean, minimal form experience with unlimited responses and no subscription required. But it has no HTML form backend, no lead management, and no self-hosting.

Best for: Non-technical users who want a generous free plan and a clean form experience without paying anything.

Key features:

Unlimited forms and responses on the free plan. Conditional logic. File uploads on the paid plan. Notion integration. Embeddable forms. Stripe payments on the paid plan.

Pricing: Free plan available. Paid plan at $29 per month.

Drawback: No HTML form backend. No self-hosting. No open source. No lead management. No bot protection. Multi-step forms only on paid plan. Less visually polished than Paperform.

3. Jotform: Best Paperform Alternative for Advanced Forms

Jotform is a good Paperform alternative for businesses that need advanced conditional logic, payment integrations, PDF generation, and approval workflows. It has a free plan with 100 monthly responses but starts at $34 per month for paid plans and has no HTML form backend.

Best for: Businesses that need advanced form logic, multiple payment integrations, and a comprehensive form management suite where budget is not the primary concern.

Key features:

10,000 plus templates. Payment integrations including Stripe, PayPal, and Square. Conditional logic and branching. PDF generation from submissions. E-signatures. Approval workflows. 150 plus integrations.

Pricing: Free plan with 100 monthly responses. Paid plans start at $34 per month.

Drawback: Expensive at scale. No self-hosting. No open source. No HTML form backend. No lead management. Significantly more expensive than Formgrid for similar submission volumes.

4. Typeform: Best Paperform Alternative for Conversational Design

Typeform is a good Paperform alternative for teams that prioritise one-question-at-a-time conversational forms with a polished visual presentation. But the free plan is almost unusable at 10 responses per month, and paid plans start at $25 per month.

Best for: Teams where conversational form design is the top priority and budget is not a constraint.

Key features:

One question at a time conversational forms. Strong visual design. Logic jumps and branching. Video questions. Strong integration ecosystem.

Pricing: Free plan with 10 responses per month. Paid plans start at $25 per month.

Drawback: Extremely limited free plan. No HTML form backend. No self-hosting. No open source. No lead management. No bot protection on lower plans. Worth noting that Formgrid now includes multi-step conversational forms at $12 per month with all the features Typeform lacks.

5. Google Forms: Best Free Paperform Alternative for Basic Use Cases

Google Forms is a good free Paperform alternative for basic surveys and internal data collection with unlimited responses at no cost. But it has no custom branding, no lead management, no bot protection, and no HTML form backend.

Best for: Anyone who needs something completely free for basic internal data collection where branding and lead tracking do not matter.

Key features:

Completely free. Unlimited responses. Google Sheets integration included. Conditional logic. Simple response analytics.

Pricing: Free.

Drawback: No custom branding. Forms look like Google Forms. No HTML form backend. No self-hosting. No bot protection. No lead management. Not suitable for professional client-facing forms or event registration pages.

Side-by-Side Comparison

Feature	Paperform	Formgrid	Tally	Jotform	Typeform
Form builder	Yes	Yes	Yes	Yes	Yes
Multi-step forms	Yes	Yes	Paid	Yes	Yes
Landing page templates	Yes	Yes	No	No	No
HTML form endpoint	No	Yes	No	No	No
Lead pipeline	No	Yes	No	No	No
Follow-up reminders	No	Yes	No	No	No
Conversion tracking	No	Yes	No	No	No
Free captcha	Paid	Free	No	Paid	No
Google Sheets sync	Paid ($59 plan)	Yes ($12/mo)	Paid	Paid	Paid
Self-hostable	No	Yes	No	No	No
Open source	No	Yes	No	No	No
File uploads	Paid	Yes	Paid	Paid	Paid
Free plan	No	Yes	Yes	Yes	Yes (10/mo)
Starting price	$24 per month	$12 per month	$29 per month	$34 per month	$25 per month
GDPR friendly	Yes	Yes	Partial	Partial	Partial

Which One Should You Use?

Use Formgrid if:

You want a Paperform alternative with a real free plan. You need an HTML form backend for a static site or custom-coded form. You want to track what happens to submissions after they arrive. You want Google Sheets sync without paying $59 per month or using Zapier. You want multi-step conversational forms without a separate subscription. You need free captcha protection without writing any backend code. You care about open source and self-hosting. GDPR compliance matters to you.

Use Tally if:

You want unlimited responses for free. You are a non-technical user who does not need an HTML backend. You use Notion and want native integration.

Use Jotform if:

You need advanced payment integrations, PDF generation, and approval workflows. Budget is not a constraint.

Use Typeform if:

Visual design and conversational flow are your absolute top priority. You are not concerned about the limited free plan.

Use Google Forms if:

You need something completely free with unlimited responses. Branding and lead management do not matter.

Final Thoughts

The best Paperform alternative in 2026 is Formgrid because it is the only tool that gives you a form builder, an HTML form backend, multi-step conversational forms, a full lead pipeline with follow-up reminders and conversion tracking, free captcha protection, and Google Sheets sync at $12 per month with a real free plan. Paperform charges $24 per month for 100 submissions with no free plan and none of those additional capabilities.

Paperform is a genuinely good product. The form design quality is high, and the payment integrations are strong. But it is hard to justify the price in 2026 when better alternatives exist at lower cost with more features.

Most form tools stop at the inbox. Your submission arrives, you get an email, and then you are on your own figuring out who to follow up with and whether they ever became a customer. Formgrid is the only tool on this list that closes that gap.

Try Formgrid for free. No credit card required.

Full disclosure: I built Formgrid. I wrote this comparison as honestly as I could. If anything looks inaccurate, let me know in the comments.

DEV Community: Allen Jones

What Actually Makes a Software Engineer Great (It's Not the Framework You Know)

1. Understand the "Why," Not Just the "How"

A Concrete Example: Node.js vs Python

Why This Matters More With AI Tools

2. Product Engineering: Go Beyond Writing Code

3. System Design: Know What's Underneath the Platform

Putting It Together

The N+1 Query Problem: Why Your API Might Be Making 101 Database Queries Instead of 2

The Setup

Why It's Called N+1

The Fix: A Single SQL JOIN

How Different Frameworks Solve This

How to Catch This in Your Own Code

It Gets Worse With Nested Relationships

A Rough Sense of the Cost

Don't Forget the Index

Takeaway

What an idempotency key actually does

Why "just check the balance first" doesn't work

The fix is a key, not a check

Same key, different payload, is a bug, not a replay

Three states, not two

The race no one thinks about until it bites

Idempotency is not a transaction

Keys don't live forever

What I check now

Embeddings are just arrays. Retrieval is the work.

What I hold in my head

Two arrays from two different models are not comparable

Chunking is the product decision

Looking at what actually gets retrieved

Brute force works until it doesn't

The embedding call is a network call

What I am not doing yet

How to Build an AI Email Auto-Reply System with RAG and PostgreSQL

The Problem

Step 1: A Table of Known Questions and Answers

Step 2: Turning the Incoming Email into a Vector

Step 3: The Retrieval Query, Broken All the Way Down

What $1 actually is

What <=> actually does

What ORDER BY does here

What LIMIT 3 does

Where the similarity score comes from

Putting the whole query back together

Step 4: Handing the Retrieved Answers to the LLM

Building It: A Minimal Working Implementation

1. Set up the database

2. Seed it with known questions and answers

3. Handle an incoming email

A few things worth doing before this touches real customers

The Full Pipeline

The Mental Model Worth Keeping

What the Vector Database Is Doing vs What the LLM Is Doing

When You Don't Need a Vector Database

How to Build a Quote Request System with React (2026 Guide)

What We Are Building

Prerequisites

Step 1: Set Up the React Project

Step 2: Create Your Formgrid Form

Step 3: Build the Project Structure

Step 5: Style the Form

Step 6: Confirm the Submission Arrives

Step 7: Work the Lead, Not Just the Submission

Step 8: Add Spam Protection

Step 9: Sync to Google Sheets

Why Not Just Use a Plain Contact Form

Deploying

Final Thoughts

Contact Form vs Client Intake Form: Which One Should Your Business Use?

Still Using a Contact Form? The Real Question Is What Happens After Someone Clicks Submit.

Build a Client Intake Form in Minutes

What Is a Contact Form?

What Is a Client Intake Form?

See What a Modern Intake Form Looks Like

The Biggest Difference

Contact Form vs Client Intake Form

Best Form Builders in 2026: What Happens After Someone Submits a Form

Building a Form From Scratch, or Still Comparing Builders?

What `$1` actually is

What `<=>` actually does

What `ORDER BY` does here

What `LIMIT 3` does

Where the `similarity` score comes from