So I built a free, no-signup estimate and invoice generator that runs entirely in the browser: Free Contractor Estimate & Invoice Generator.

What it does

• Estimates and invoices with line items, quantities, unit prices, tax, and a deposit line. Print or save as PDF straight from the browser.
• Nothing leaves your device. There's no account and no server storing your customer data.
• A job pricing calculator (open it here) that takes labor hours, crew rate, materials, overhead, and target margin and gives you a price that actually covers the business, not just the job.
• Trade-specific starting templates with typical line items already filled in:
  • Roofing estimate template
  • Plumbing estimate template
  • HVAC estimate template
  • Electrical estimate template
  • Painting estimate template
  • Landscaping estimate template
  • Concrete estimate template
  • Remodeling estimate template
  • Cleaning estimate template
  • Handyman estimate template

Why margin matters more than markup

The most common pricing mistake I see is adding 20% markup to materials and labor and calling it profit. A 20% markup is only a 16.7% margin, and once overhead (truck, insurance, phone, software, unpaid estimate time) comes out, it can be close to zero. The calculator works backward from the margin you want, so the number you quote already includes overhead.

How it's built

Plain HTML, CSS, and a small vanilla JavaScript file, deployed as a static site on Vercel. Estimates are rendered to a print stylesheet, so "Save as PDF" in any browser produces a clean one-page document. No framework and no backend means it loads instantly on a phone at a job site.

If you want more than one-off estimates

The free tool handles a single estimate or invoice. If you want to track every lead, quote, job, and payment in one place, I also made a couple of low-cost trackers:

• Contractor Job Tracker spreadsheet for Google Sheets or Excel
• Contractor Job Tracker for Notion
• AI Prompts for Contractors, copy-paste prompts for estimates, follow-ups, reviews, and job descriptions

But the estimate generator is free and will stay free. If you run a trade business and something is missing, tell me in the comments and I'll add it.

I built a Notion workspace that keeps that whole pipeline in one place. Here's how it's structured, so you can copy the idea even if you never buy anything.

The four linked databases

1. Leads: every inquiry, with status (New, Contacted, Site visit, Quoted, Won, Lost), source (Google, referral, Facebook, yard sign), service, estimated value, and a next follow-up date. A board view by status lets you drag leads through the pipeline.
2. Quotes: one row per estimate, linked to its lead, with quote date, valid-until date, subtotal, tax rate, total, deposit percentage, and a balance formula (total minus deposit). Status goes Draft, Sent, Accepted, or Declined.
3. Jobs: once a quote is accepted it becomes a job, with crew, start and end dates, job address, total, deposit, and balance. There's a status board and a calendar view by start date.
4. Invoices: deposit and final invoices linked to the job, with due date, amount paid, paid date, and a "Days overdue" formula on anything not yet paid.

Because everything is a relation, you can open one job and trace it back to the quote and the original lead source.

Tips if you build your own

• Keep statuses short and few. Six is plenty; nobody updates a 12-step pipeline from a truck.
• Put a "Next follow-up" date on every lead and filter a view to today or earlier. That one view does more than any CRM feature.
• Split invoices into a deposit and a final balance. It makes "who still owes me money" a single filtered list.

Want the ready-made version?

If you'd rather skip the setup, the finished template (all four databases, formulas, and views, with a quick-start guide) is $9: Contractor Job Tracker for Notion.

Prefer spreadsheets? There's also an Excel/Google Sheets version with the same pipeline for $12: Contractor Job Tracker spreadsheet.

Two things were going on:

1. Reporting lag. Custom events take about 15–25 minutes to show up. Wait before you start debugging.
2. Intake filtering. The pixel returns 200 even when Whop's intake drops the visit, which happens with headless or data-center browsers, ad blockers, or a pixel script that never loaded. Those events never arrive.

The second one matters most for demos, QA runs and privacy-minded visitors. The fix is to send every event twice, once from the browser and once from the server, with the same event_id so Whop counts it only once.

The client: queue for the pixel, then mirror to your server

// src/track.ts
export function track(event: RoofingEvent, props: Record<string, unknown> = {}) {
  const eventId = `${event}_${crypto.randomUUID()}`;
  const payload = { event_id: eventId, ...props };
  pixelQueue.push([event, payload]);
  if (!flushPixel()) {
    let tries = 0;
    const id = setInterval(() => { if (flushPixel() || ++tries > 20) clearInterval(id); }, 250);
  }
  mirror(event, eventId, props);
}

flushPixel() drains the queue once window.whop.track exists. That covers the race where a user clicks before the injected pixel has loaded. mirror() POSTs the same event to /api/track with keepalive: true, so it survives navigation to checkout:

fetch("/api/track", {
  method: "POST", headers: { "content-type": "application/json" },
  body, keepalive: true, credentials: "same-origin",
}).catch(() => {});

The anonymous ID comes from Whop's _wuid cookie, so the server copy is tied to the same visitor as the pixel copy.

The server: allowlist, validate, forward to the Events API

// worker/index.ts
const TRACKED = new Set(["service_viewed", "deposit_started", "estimate_requested"]);

async function mirrorEvent(req: Request, env: Env) {
  const b: any = await req.json().catch(() => ({}));
  const name = clean(b.event, 35);
  if (!TRACKED.has(name)) return json({ error: "Unknown event" }, 400);
  const eventId = clean(b.event_id, 100);
  if (!/^[\w-]{8,100}$/.test(eventId)) return json({ error: "event_id required" }, 400);
  const cookieWuid = (req.headers.get("cookie") || "").match(/(?:^|;\s*)_wuid=([^;]*)/)?.[1];
  const body = {
    account_id: accountId(env),
    event_name: name,
    event_id: eventId,                 // same id as the pixel → deduplicated
    event_time: new Date().toISOString(),
    action_source: "website",
    url: clean(b.page_url, 1000) || req.headers.get("referer") || undefined,
    user: (b.anonymous_id || cookieWuid) ? { anonymous_id: b.anonymous_id || cookieWuid } : undefined,
    context: { ip_address: req.headers.get("cf-connecting-ip") || undefined,
               user_agent: req.headers.get("user-agent") || undefined },
  };
  let r = await whopApi(env, "/events", { method: "POST", body: JSON.stringify(body) });
  if (!r.ok && /context\./.test(String(r.body?.error?.message))) {
    delete (body as any).context;      // hosting proxy IP/UA rejected → retry without it
    r = await whopApi(env, "/events", { method: "POST", body: JSON.stringify(body) });
  }
  return json({ ok: r.ok, event_id: eventId }, r.ok ? 200 : 502);
}

A few choices worth explaining:

• An allowlist, not a passthrough. Without it, anyone could use /api/track to inject arbitrary events into your analytics.
• Validate event_id. Deduplication depends on it, so reject anything missing or malformed.
• Retry without context. Behind the hosting proxy, the IP or user agent is sometimes rejected. Dropping device context is better than dropping the event.
• The server key never reaches the browser. Whop hosting injects it into the worker environment.

Verifying it

Check the Websites → Pixel events panel instead of the general Events page, and give it 20 minutes. Run a headless browser against the site. Before the mirror, its events were missing. After it, they all showed up, each counted once.

This tracking setup comes with my Whop contractor templates, along with Leads-powered estimate forms, deposits, and card-on-file invoicing. Demos: roofing · HVAC. The source is $49, or $199 done-for-you.

When I built a roofing contractor site on Whop, I used a two-step flow:

1. At approval: the homeowner saves a card in a setup-mode checkout and is charged $0.
2. After the job: the contractor calls one endpoint, which creates an invoice for the final balance and charges the saved card.

Here's the code that does it.

Step 1: Save a card with a setup-mode checkout

In the Whop dashboard (or through the API) you create a checkout configuration in setup mode. It collects a payment method without charging it. On the site, that configuration ID goes into the same <Checkout> component you'd use for a normal plan:

// src/CheckoutModal.tsx
const checkoutProps =
  target.kind === "plan"
    ? { plan: target.plan, ...(promoCode ? { promoCode } : {}) }
    : { checkoutConfiguration: target.checkoutConfiguration };

const onComplete = (p: any) => {
  if (p?.result === "setup")
    setDone({ label: "Card saved on file — nothing was charged.", id: p.setupIntentId });
  else
    setDone({ label: "Payment received — thank you!", id: p?.receiptId ?? p?.paymentId });
};

onComplete returns a setupIntentId. That's the only thing to keep, and you can look up the reusable payment method from it later.

Step 2: Resolve the saved payment method

On the worker, an admin-only route reads the setup intent, which carries the payt_… payment method ID:

// worker/index.ts
async function getSetupIntent(id: string, env: Env) {
  const r = await whopApi(env, `/setup_intents/${encodeURIComponent(id)}`);
  return json(r.body, r.status);
}

Every /api/admin/* route checks an x-admin-token header against a secret, so customers can't reach it.

Step 3: Create and issue the final invoice

This is the core of it. The invoice is a one-off hidden plan with the final amount. If you pass payment_method_id, issuing the invoice charges that card. Without one, the customer gets a payable invoice link instead:

const create = await whopApi(env, "/invoices", {
  method: "POST",
  body: JSON.stringify({
    account_id: accountId(env),
    ...(b.member_id
      ? { member_id: b.member_id }
      : { email_address: clean(b.email, 200), customer_name: clean(b.customer_name, 120) || undefined }),
    ...(b.payment_method_id ? { payment_method_id: b.payment_method_id } : {}),
    ...(b.billing_address ? { billing_address: b.billing_address } : {}),
    due_at: due,
    items: [{
      quantity: 1,
      variant: {
        currency: "usd", billing_type: "one_time", initial_price: amount, visibility: "hidden",
        title: clean(b.description, 30) || "Final balance",
        product_id: LEAD_PRODUCT_ID, force_create_new_plan: true,
      },
    }],
    metadata: { kind: "final_balance", project: clean(b.project, 60) || "roofing" },
  }),
});
const issued = await whopApi(env, `/invoices/${create.body.id}/issue`, { method: "POST", body: "{}" });

Gotchas I hit

• Variant titles are capped at 30 characters. Put the long text in description and keep title short.
• Tax needs an address. Whop has to resolve tax before it can issue the invoice, so pass billing_address or issuing will fail.
• Use force_create_new_plan: true. Each job's final balance is different, so each invoice gets its own hidden plan instead of reusing one.
• Create first, then issue. The invoice starts as a draft. The charge only happens on /issue, which lets you review the amount before it bills.

Calling it from the contractor's side is a single request:

curl -X POST https://your-site.whop.site/api/admin/final-invoice \
  -H "x-admin-token: $ADMIN_TOKEN" -H "content-type: application/json" \
  -d '{"email":"homeowner@example.com","amount":8420,"description":"Roof replacement – final","payment_method_id":"payt_..."}'

That's the whole flow: a deposit or $0 card save when the quote is approved, and one call when the crew leaves.

I packaged this flow, along with Whop Leads estimate forms, embedded checkout and server-side events, into two ready-to-deploy contractor templates. Demos: roofing · HVAC. Each is $49 for the source or $199 done-for-you.

What it does

• Estimate requests become real leads. The estimate form signs the homeowner in with Whop (OAuth + PKCE) and creates a record through the Whop Leads API, so nothing lives in a forgotten inbox.
• Deposits and service fees are paid on the spot. An embedded Whop checkout (with Apple Pay and Google Pay) handles a fixed-price visit and a $500 project deposit without leaving the page.
• Card on file, then the final bill. A setup-mode checkout saves the customer's card. When the job is done, one call to the Invoices API charges the final balance to that saved card.
• Conversion tracking that survives ad blockers. Three events (service viewed, deposit started, estimate requested) fire through the Whop pixel from the browser and are mirrored through a small server endpoint.
• One config file to rebrand. Business name, services, prices, service area and colors all live in one file.

Stack

React + Vite, deployed to Whop Websites. No Stripe account, no WordPress plugins, no separate CRM.

Live demos

• Roofing: https://beta-roofing-demo.whop.site
• HVAC: https://beta-hvac-demo.whop.site

Lessons from the Whop APIs

1. Pixel events show up in the dashboard 15 to 25 minutes late. If your events page looks empty, wait before debugging, or check the Websites pixel events panel.
2. Mirror conversion events server-side. Browser-only tracking quietly loses a chunk of events.
3. Setup-mode checkout plus the Invoices API is a clean pattern for any service business that bills after the work is done.

Get the source

If you build sites for roofers or HVAC companies, the full source is available:

• Roofing template: https://whop.com/beta-demo-roofing-template/whop-roofing-site-template/
• HVAC template: https://whop.com/beta-demo-roofing-template/whop-hvac-site-template/

Each is $49 for the code, or $199 and I'll set it up and rebrand it for you within 3 business days. Happy to answer questions about the Whop APIs in the comments.