DEV Community: Brightcode

Your contact form says "Thank you". Did the lead arrive? How we test website forms end to end

Brightcode — Thu, 29 Oct 2026 09:20:56 +0000

By the Brightcode team, a small web agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

The most expensive bug we look for on a client site doesn't throw an error. The form submits, the visitor sees a green "Thanks, we'll be in touch", and the lead goes nowhere. It lands in a spam folder, or in the inbox of someone who left last year, or it never leaves the server at all.

Nobody reports it, because the person it fails for has already gone off to call a competitor. The owner only notices months later, when enquiries look "a bit slow".

So for every site we build or take over, we treat the lead path as a system that needs tests, the same as a checkout. Here's what that looks like.

Step 1: List every lead path, not just the contact page

A business site rarely has one form. We write them all down before touching code:

Contact and "get a quote" forms
Popup or footer forms (often from a different plugin than the main one)
Phone links (tel:)
WhatsApp buttons
Email links (mailto:)
Booking widgets, newsletter sign-ups, careers forms

For each one, note where the submission is supposed to end up (which inbox, CRM or sheet) and who is supposed to answer it. That second column is where the surprises are. More than once, the honest answer has been "nobody knows".

Check the links while you're at it. On our own site, the WhatsApp button used to be a JavaScript click handler with no real link behind it. It worked for most visitors, but it isn't a link to a crawler, to some in-app browsers, or to anyone with a script blocked. Now it's a plain <a href="https://wa.me/...">. Boring, and it always works.

Step 2: Stop relying on `mail()` and the host's default sender

The classic setup is a form plugin that calls PHP's mail() on shared hosting and sends as wordpress@yourdomain.com. That message usually has no proper authentication for your domain, and receiving servers are much stricter than they used to be. Google's sender guidelines say that since February 2024 all senders to Gmail accounts must set up SPF or DKIM, and bulk senders need SPF, DKIM and DMARC.

A small business form sends a few emails a day, nowhere near bulk. It still makes sense to do all three:

Send through an authenticated SMTP or transactional email service, from an address on your own domain
Publish SPF and DKIM records for that service
Add a DMARC record, even if it starts at p=none while you watch the reports

You can check what's published in a minute:

dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com
# DKIM needs the selector your email provider gave you:
dig +short TXT selector1._domainkey.example.com

Then send a test submission to a Gmail address and use "Show original". You want to see PASS next to SPF, DKIM and DMARC.

Step 3: Save the lead before you send the email

Treat the email as a notification. It shouldn't be the only place a lead lives. If SMTP is down for an hour, or a credential expires, the lead should still exist somewhere.

Our rule: write the submission to storage first, then notify. Here's the shape of it in a Next.js route handler, with a honeypot field for basic bot filtering:

// app/api/lead/route.js
import nodemailer from "nodemailer";
import { saveLead } from "@/lib/leads"; // your DB, sheet or CRM call

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: 587,
  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
});

export async function POST(req) {
  const data = await req.json();

  // Honeypot: a hidden "company_website" field real users never fill in
  if (data.company_website) return Response.json({ ok: true });

  if (!data.name || !data.phone) {
    return Response.json({ ok: false, error: "Name and phone are required" }, { status: 400 });
  }

  const lead = await saveLead({ ...data, receivedAt: new Date().toISOString() });

  try {
    await transporter.sendMail({
      from: '"Website enquiry" <leads@example.com>',
      to: process.env.LEADS_INBOX,
      replyTo: data.email || undefined,
      subject: `New enquiry from ${data.name}`,
      text: `${data.name}\n${data.phone}\n${data.email || "-"}\n\n${data.message || ""}`,
    });
  } catch (err) {
    console.error("Lead saved but email failed", lead.id, err); // alert on this
  }

  return Response.json({ ok: true, id: lead.id });
}

The honeypot returns a fake success so bots don't learn anything. Validation runs on the server, because anyone can skip client-side checks. And an email failure is logged loudly instead of being swallowed, since the lead is already safe.

Step 4: Fire the analytics event only on a real success

A lot of sites send their "lead" event when the button is clicked. That counts double-clicks, validation errors and bot hits as leads, and the numbers in analytics drift away from the numbers in the inbox.

GA4 has a recommended event for this, generate_lead. We send it only after the server says the lead was saved:

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

if (res.ok && body.ok) {
  window.gtag?.("event", "generate_lead", { form_id: "contact_main" });
  showThankYou();
} else {
  showError(body.error || "Something went wrong. Please call or WhatsApp us.");
}

Two more things that bite people. If you use Google Tag Manager, check the data layer variable names match exactly, because a typo there sends events with empty parameters and no error. We had this on a site we run, and the fix was a one-line rename in GTM. And remember to mark the event as a key event in GA4, or it never shows up as a lead in reports.

Step 5: Test it like code, then keep testing it

Testing once at launch won't cover you. Forms break later, when a plugin updates, a caching layer starts serving a stale nonce, a CAPTCHA key is tied to the old domain after a move, or someone changes the inbox.

We use a Playwright test that submits the real form and checks the response, not just the thank-you text:

// tests/lead-form.spec.js
import { test, expect } from "@playwright/test";

test("contact form saves a lead", async ({ page }) => {
  await page.goto("/contact");
  await page.fill('input[name="name"]', "Form Test (automated)");
  await page.fill('input[name="phone"]', "0000000000");
  await page.fill('textarea[name="message"]', `monitor ${Date.now()}`);

  const [response] = await Promise.all([
    page.waitForResponse((r) => r.url().includes("/api/lead")),
    page.click('button[type="submit"]'),
  ]);

  expect(response.status()).toBe(200);
  expect((await response.json()).ok).toBe(true);
  await expect(page.getByText(/thank/i)).toBeVisible();
});

Run it in CI on every deploy, and on a schedule against production (daily is plenty for most sites). Tag the test leads clearly so the sales team can ignore them and filter them out of analytics. If you can, add one more check that the test lead actually reached the inbox or CRM, because that's the part the browser test can't see.

Once a month, a human should still do one test on a real phone: fill in the form, tap the phone link, tap WhatsApp. Automated tests catch regressions. A person catches "this form asks for eleven fields on mobile and nobody finishes it".

The short version

List every lead path and who owns it
Send from your own domain with SPF, DKIM and DMARC
Save first, notify second, and alert when the notification fails
Fire generate_lead only on a confirmed save
Test the form in CI and on a schedule, and do a real-phone check monthly

For the non-code side of this (offer, proof, tracking and the thank-you step), our checklist on what a conversion-ready landing page needs before you turn on ads covers what marketing and sales should sign off. If the forms live on WordPress, plugin updates are the usual reason they break, which is why regular security and maintenance matters for leads, not just for safety.

How do you monitor forms on sites you've handed over? We'd like to hear what's worked for you in the comments.

Written by the team at Brightcode, a Delhi NCR agency that builds business websites and keeps them working with website maintenance.

Redirect maps that survive a rebuild: how we keep SEO when a site changes platform or domain

Brightcode — Mon, 26 Oct 2026 09:15:36 +0000

By the Brightcode team, a small web agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

Most rebuilds we see go wrong in the same boring place. The new site looks great, the Lighthouse scores are green, and three weeks later someone asks why enquiries from Google have dried up. Usually the old URLs are returning 404s, or they redirect to the homepage, or they bounce through three hops before landing anywhere.

The fix is a redirect map. Everyone knows that. What's less obvious is how to build one that's actually complete, and how to prove it works before DNS flips.

This is the process we follow when we redesign a site, move it to a new platform, or move it to a new domain. We went through it for our own old domain recently, so a few of these lessons are fresh.

Step 1: Collect old URLs from more than one source

The live sitemap is the first place people look, and it's usually incomplete. Old blog posts drop out of it, plugin pages never made it in, and campaign landing pages were never meant to be in it.

We pull URLs from at least these sources and merge them:

The current XML sitemap (and any sitemap index children)
A full crawl of the live site, with a desktop crawler or a small script
The Pages report in Google Search Console, exported for the longest date range available
Landing pages from analytics, so you catch URLs that get traffic but aren't linked anywhere
Pages with external backlinks, from whatever backlink tool you have access to
Ad and email campaign URLs, which marketing teams keep in spreadsheets you'll have to ask for

Then normalise everything before you deduplicate. Lowercase the host, pick one trailing slash convention, strip tracking parameters like utm_source, and decide what to do with www and http. Without this step you end up with five rows for one page.

Step 2: Decide a fate for every URL

Every old URL gets one of three outcomes:

Redirect to the closest equivalent page on the new site
Keep the same path, because the page still exists with the same purpose
Retire with a 410 or a plain 404, because there's genuinely nothing equivalent

The tempting shortcut is to send everything you can't match to the homepage. Don't. Google tends to treat mass redirects to an unrelated page as soft 404s, and users who clicked a link about one specific thing land somewhere useless. An honest 404 page with good navigation is better than a misleading redirect.

"Closest equivalent" also means intent, not just title. Say an old page explained pricing and the new site has no pricing page. The services page that answers the same question is a better match than a blog post with a similar keyword in the slug.

Step 3: Keep the map in a boring format

Our redirect map is a CSV with four columns:

old_url,new_url,status,notes
/services/web-design/,/services/website-development,301,renamed service
/blog/old-post-slug/,/insights/new-post-slug,301,merged into new post
/summer-offer/,,410,campaign ended

A spreadsheet is fine for review with the client. But the source of truth should be a file in the repo, because then it can be tested in CI and the server config can be generated from it. Hand-typing hundreds of rules into a hosting panel is how typos ship.

A few rules we apply while filling it in:

No chains. If page A already redirects to B, and B now moves to C, update A to point straight at C. Old redirects from previous redesigns are the usual culprit here.
Point to final URLs. The target should return 200 directly, with the trailing slash and protocol your new site actually uses.
Permanent means 301 or 308. Use 302 or 307 only for something genuinely temporary, like a maintenance page.

Step 4: Put redirects in the right layer

Where the rules live matters for speed and for who can maintain them later.

For a handful of pattern rules on a Next.js site, redirects() in next.config.js works well. Setting permanent: true returns a 308, which search engines treat the same as a 301.

For a long list of one-to-one rules, we prefer the edge or the web server. An Nginx map block generated from the CSV keeps lookups fast, and so do CDN-level bulk redirect lists. Both run before your app does any work, which keeps redirect latency low and means a broken app deploy won't take your redirects down with it.

On WordPress, a redirect plugin is fine for small sites, but for a big replatform we still prefer server rules generated from the same CSV. On Shopify, URL redirects can be imported in bulk from the admin with a CSV, which suits the map format above.

Whatever layer you choose, keep one place. Redirects split between a plugin, .htaccess, the CDN and the app are very hard to debug.

Step 5: Test the map like code

This is the step that gets skipped, and it's the cheapest one. We run a small script against staging, and again against production right after launch:

#!/usr/bin/env bash
# usage: ./check-redirects.sh redirects.csv https://staging.example.com
base="$2"
tail -n +2 "$1" | while IFS=, read -r old new status notes; do
  first=$(curl -s -o /dev/null -w "%{http_code}" "$base$old")
  read -r code url hops <<< "$(curl -s -o /dev/null -L --max-redirs 5 \
    -w "%{http_code} %{url_effective} %{num_redirects}" "$base$old")"
  target="$new"; [[ "$new" == /* ]] && target="$base$new"   # full URLs for domain moves
  if [ "$first" != "$status" ]; then
    echo "FAIL $old: got $first, expected $status"
  elif [ -n "$new" ] && { [ "$url" != "$target" ] || [ "$hops" -ne 1 ] || [ "$code" != 200 ]; }; then
    echo "FAIL $old: ended at $url ($code) after $hops hops"
  fi
done

For each row we check three things: the first response has the expected status, the final URL matches new_url, and it gets there in one hop with a 200 at the end. Anything else gets fixed before launch, not after.

It's also worth crawling the new site itself for internal links that still point to old paths. A redirect will catch them, but every internal link should go straight to the final URL. Menus, footers and links inside old blog content are where these hide.

Step 6: Update everything that points at URLs

Redirects handle people and bots arriving from outside. Inside the new site, a few more things need to agree with the map:

Canonical tags point to the new URLs, never to redirected ones
The XML sitemap lists only final, indexable URLs that return 200
hreflang, structured data and Open Graph URLs use the new paths
robots.txt on staging blocks crawling, and the production one doesn't (check this on launch day, every time)

For a domain move, there's one more step. Verify both domains in Google Search Console, make sure the old homepage 301s to the new one, and then use the Change of Address tool. Google's own guidance is to keep redirects in place for at least a year, so don't let the old domain lapse.

Step 7: Watch it for a few weeks

After launch we check the Search Console Pages report and crawl stats regularly, and look for new 404s in server logs. Old URLs you missed will show up there, often from backlinks nobody knew about. Add them to the CSV, regenerate the rules, re-run the test.

Rankings often wobble for a bit after a migration, even when everything is done right. What you want to avoid is the drop that never recovers because a whole section of URLs is quietly broken.

If you're still deciding whether a site needs a full rebuild at all, we wrote about when to rebuild versus redesign. And for the non-developer side of launch planning, like owners, access and tracking, our website migration checklist covers the rest.

What's the worst redirect mess you've inherited from a previous redesign? Tell us in the comments.

Written by the team at Brightcode, a Delhi NCR agency that builds websites and handles SEO-safe platform migrations.

Website, web app or SaaS? The architecture questions we ask before writing a line of code

Brightcode — Thu, 22 Oct 2026 09:21:16 +0000

By the Brightcode team, a small web agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

A lot of project briefs we get start with "we need an app". Sometimes that's true. Often what the person needs is a fast website with a good form, plus one paid tool they haven't heard of yet. And now and then a "simple website" turns out to be a multi-tenant product with billing.

Calling it wrong is expensive in both directions. Build a SaaS when the client needed a brochure site and you've burned months. Build a brochure site when they needed a portal and you'll rebuild it within a year.

So before we pick a stack or write an estimate, we sort the project into one of three buckets. Here's how, and what changes in the architecture once we know.

The one-line test

Ask: will people come here to read, or to do work?

Mostly reading (services, products, contact details, then call, WhatsApp or buy) → website
Logging in to get something done (book, order, approve, check a report) → web app
The same web app, sold to many customers who each get their own walled-off space → SaaS

A store sits in between. It's a website with an app-like checkout. A service site with a client login area is a website with a small web app attached. That's fine. Name the parts separately and scope them separately.

Question 1: Does anyone need to log in?

This is the biggest fork. The moment there's a login, you're on the hook for:

Auth (sessions or tokens, password reset, maybe OTP or Google sign-in)
Roles and permissions, even if it's only "admin" and "user" on day one
Data that differs per person, which changes how you cache everything
Security reviews you didn't need for a marketing site

If nobody logs in, keep it a website. Static or mostly static pages, a CMS for the people who edit content, aggressive caching at the CDN. If only the client's team logs in to edit content, that's a CMS, not a web app. Don't build custom auth for it.

Question 2: Is the content the same for everyone?

Websites serve the same page to every visitor. That's what makes them cheap to host and fast to load. You can pre-render, cache at the edge for minutes or hours, and serve most traffic without touching your server.

Web apps serve different data to each user, so pages are rendered per request or built on the client from an API. Caching moves down to the data layer. This is why "can we just add a dashboard to the website?" is rarely a small change. It brings a second rendering model into the same codebase.

A pattern that works well for us: keep the marketing site and the app as two deployables. example.com is the website, built for SEO and speed. app.example.com is the web app, built for logged-in users. They share a design system, not a runtime.

Question 3: Is there more than one customer organisation?

This is the question that separates a web app from SaaS. A portal for one distributor and its dealers is a web app, even if hundreds of dealers log in. A tool you sell to fifty distributors, each with their own dealers, is SaaS.

SaaS adds a few things you can't bolt on cheaply later:

Tenancy. Usually a tenant_id on every row with strict scoping in queries (or row-level security in Postgres). Separate schemas or databases per tenant are possible, but they make migrations and reporting harder.
Billing. Plans, trials, upgrades, failed payments, invoices with GST if you sell in India. Subscription billing through a gateway like Razorpay or Stripe is a project in its own right.
Onboarding and admin. Sign-up, inviting teammates, a super-admin view for your own support team.

If the client isn't planning to sell the software to other companies, don't build tenancy "just in case". It's the most common over-engineering we see in early briefs.

Question 4: Does a ready-made tool already do 80% of it?

Before custom anything, we check whether existing SaaS covers the job. CRMs, booking tools, invoicing, helpdesks. If it does, the right build is usually a good website in front of the tool, plus a thin integration layer: the website form posts to the CRM's API, a webhook sends a WhatsApp alert, a small script updates a sheet.

Custom earns its place when:

The team spends hours a day copying data between tools
A missing feature in the current tool causes real mistakes
Per-seat pricing keeps climbing as the team grows
The process itself is the business's edge (a particular quoting or dealer pricing system, say)
The software is the product

Most of our software and API work lives in that thin layer, not in replacing tools that already work.

Question 5: Who looks after it in year two?

This one decides more than the stack.

A website mostly needs content edits, dependency or plugin updates and someone watching uptime. A web app needs all that plus bug fixes, database care, auth patches and small feature requests that never stop. A SaaS adds on-call for paying customers.

So we ask who will own it after launch, and scope that up front. If the honest answer is "nobody technical", that pushes us towards simpler choices: a hosted CMS, fewer custom parts, managed infrastructure. If you're weighing a headless setup for a content-heavy site, we wrote up when a headless CMS makes sense and when it's overkill.

What changes in the estimate

Once the bucket is clear, the estimate changes shape:

	Website	Web app	SaaS
Main unit we price	Unique templates and content	Screens, roles and workflows	Everything in web app, plus tenancy, billing and onboarding
Rendering	Pre-rendered or cached	Per request or client-side	Per request or client-side
Auth	None (CMS login only)	Yes, with roles	Yes, with roles per tenant
Testing focus	Layout, speed, forms, SEO	Permissions, edge cases, data	All of that, plus tenant isolation
Year-two work	Updates, edits, uptime	Fixes, features, data care	Same, plus support and billing issues

We also split mixed briefs into two lines: "marketing website" and "client portal", each with its own estimate. Clients can see where the money goes, and they can launch the website first while the app is still being built.

The short version

Read or do? That's website vs web app.
One customer organisation or many? That's web app vs SaaS.
Can a ready-made tool do most of it? Then build the website and the glue, not the tool.
Who maintains it? Let that answer simplify your choices.

We wrote a longer, non-technical version of this for business owners: website vs web app vs SaaS: what does your business actually need?. It's handy to send to a client before the first call.

How do you sort briefs like this? Do you split the marketing site and the app from day one, or keep them in one codebase? Tell us in the comments.

Written by the team at Brightcode, a Delhi NCR agency that builds websites, e-commerce stores and custom web apps.

How we turn "how much for a website?" into a quote you can defend: a developer's scoping checklist

Brightcode — Mon, 19 Oct 2026 04:12:15 +0000

By the Brightcode team, a small web agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

If you build websites for small businesses, you know this message. "How much for a website?" And the person wants a number in the next reply.

We're a small web team in Delhi and that question reaches us every week. Answering with a number straight away feels helpful. It rarely is. Either the client compares it with a quote that covers half the work, or three weeks in you learn that "simple website" meant online booking plus a CRM sync.

So we stopped quoting off the first message. Below is the checklist we now use to get from a vague ask to a scope we can price and stand behind. It's written for developers and freelancers. If you're the one buying a site, it shows what a good quote should rest on.

1. Count templates, not pages

"10 pages" tells you very little. Ten blog posts share one template. A home page, a service page, a product page and a checkout are four separate builds. Each has its own layout, states and edge cases.

So we list every unique template and price those. Pages that reuse a template are content entry, and the quote says so. That single change explains most of the gap between a ₹15,000 quote and a ₹1.5 lakh one, when both sides are calling it "a 10-page site".

2. Write down the project type before anything else

Clients use the same words for very different jobs:

Brochure site: mostly read-only content and a contact form
Lead-gen site: landing pages, forms, conversion tracking, ad-ready structure
Store: catalogue, cart, checkout, payments, shipping, returns
Web app: logins, roles, dashboards, reports
SaaS: one codebase serving many customers, billing, multi-tenancy

The further down that list, the more testing and long-term maintenance you're signing up for. When a brief straddles two types, like a service site with a client portal, we split the quote in two. That way the expensive part is out in the open.

3. Treat every integration as its own mini-project

Here in India the integrations list tends to look the same: a payment gateway (Razorpay, PayU, Cashfree), WhatsApp alerts, a CRM, Google Sheets. Sometimes accounting software like Tally, or an ERP.

Every one of those means setup, auth, error handling and a test plan. Plus the webhook that fails at 2 a.m. A gateway isn't finished when the happy path works. It's finished when refunds, failed payments and duplicate webhooks are handled too. Older systems with thin API docs take longer, and we flag that as a risk in the estimate instead of hiding the hours.

When a client asks "can you just connect it to X?", our answer is "yes, and here's what that involves". A lot of software and API integration work hides inside projects that get called "a website".

4. Decide the platform by who edits the site after launch

WordPress, Shopify, Next.js, custom. We try not to start from what we enjoy writing. We start from who will update the site, how often, and what it'll cost to run over the next two or three years.

WordPress suits content-heavy sites where non-developers publish often. Someone still has to own updates and security.
Shopify gets a store live fast. The monthly plan and paid apps are ongoing costs.
Next.js or custom gives you speed and control, for more development effort up front.

There's a longer write-up of the trade-offs in WordPress vs a custom website. Short version: picking a platform also picks the running costs, so bring it into the quote conversation early.

5. Ask who supplies content and photos

Cheap quotes almost always assume finished copy and photos show up on day one. They rarely do. In our experience content is the most common reason a project runs late. So we ask straight out: who writes the copy, who shoots the product photos, does anything need translating? If the answer is "you", it becomes a separate line item with its own timeline.

6. Put migration and SEO in writing

If the client already has a site that ranks, a redesign without a redirect map can quietly wipe out years of traffic. We list migration as its own line: URL inventory, redirect map, and a Search Console check after launch. Basic on-page SEO (titles, meta, headings, sitemap) comes with every build we ship. Anything deeper gets scoped separately. Our website migration checklist is the list we actually work from.

7. Show the first-year cost, not just the build cost

If the quote only shows the build price, month four brings a nasty surprise. So we add a short running-costs section: domain and SSL, hosting, yearly theme or plugin licences, platform plans like Shopify, gateway fees, SMS/email/WhatsApp API charges, and maintenance.

People rarely complain about running costs they were told about upfront. It's the ones nobody mentioned that cause the argument.

8. Agree on what "done" means

Our scope documents end with the dull bits. They're also the bits that prevent fights later:

How many revision rounds
Who owns the domain, hosting account and code (always the client)
What's covered after launch, and for how long
What counts as a change request

The red flags we see in other quotes

Clients sometimes show us a competing quote. These are the things that make us wince, and they're worth checking in your own quotes too:

One line: "Website – ₹X", no scope
Nothing about revisions, hosting or maintenance
Domain, hosting or code registered in the agency's name
Mobile layout, speed or basic SEO sold as extras
No redirect plan when replacing a live site

Wrapping up

None of this is hard. It just means having one proper conversation before the number instead of after it. The quote takes a little longer to write. In exchange, it survives being compared line by line with someone else's.

On the buying side and want to see how all this turns into real price ranges in our market? We published a longer guide: what decides website development cost in Delhi NCR. It has the ranges other agencies publish for each type of site, the running costs, and a prep list for getting quotes you can compare.

What's on your scoping checklist that isn't on ours? Tell us in the comments.

Written by the team at Brightcode, a Delhi NCR agency that does website development, e-commerce and web apps.

DEV Community: Brightcode

Your contact form says "Thank you". Did the lead arrive? How we test website forms end to end

Step 1: List every lead path, not just the contact page

Step 2: Stop relying on mail() and the host's default sender

Step 3: Save the lead before you send the email

Step 4: Fire the analytics event only on a real success

Step 5: Test it like code, then keep testing it

The short version

Redirect maps that survive a rebuild: how we keep SEO when a site changes platform or domain

Step 1: Collect old URLs from more than one source

Step 2: Decide a fate for every URL

Step 3: Keep the map in a boring format

Step 4: Put redirects in the right layer

Step 5: Test the map like code

Step 6: Update everything that points at URLs

Step 7: Watch it for a few weeks

Website, web app or SaaS? The architecture questions we ask before writing a line of code

The one-line test

Question 1: Does anyone need to log in?

Question 2: Is the content the same for everyone?

Question 3: Is there more than one customer organisation?

Question 4: Does a ready-made tool already do 80% of it?

Question 5: Who looks after it in year two?

What changes in the estimate

The short version

How we turn "how much for a website?" into a quote you can defend: a developer's scoping checklist

1. Count templates, not pages

2. Write down the project type before anything else

3. Treat every integration as its own mini-project

4. Decide the platform by who edits the site after launch

5. Ask who supplies content and photos

6. Put migration and SEO in writing

7. Show the first-year cost, not just the build cost

8. Agree on what "done" means

The red flags we see in other quotes

Wrapping up

Step 2: Stop relying on `mail()` and the host's default sender