I run a drainage company. I got sick of paying for CRM software, so I built my own. Meet Relayhand.

Reza Jodeiri — Thu, 15 Oct 2026 16:51:23 +0000

If you've ever hired someone to fix a drain, replace an AC unit or regrade a yard, you've seen the back office of a small trade business. The quote was a photo of a notepad, or a PDF made from a Word template. The contract was the same PDF with "sign here" typed at the bottom.

I don't just know this world; I live in it. I own and operate a residential drainage company in Memphis, Tennessee. The thing that bothered me most about this industry wasn't how messy the back office looked. It was how much money leaked out of it. A lead that goes quiet for four days usually stays quiet. A contract signed on paper can't be found when there's a dispute. And a deposit nobody asked for at signing is a deposit that never comes in.

So I built Relayhand. It's a CRM for small trade contractors: one owner working alone, or a few crews with someone in the office. Today I'm opening it up.

What it does

Relayhand covers the stretch of work between "someone called about a job" and "the job is paid for." It's built around one loop:

1. A lead comes in. It can come from a call, a text or the contractor's own website. Whatever the source, it lands in one place with the address and history attached, and it goes into a pipeline. The contractor defines the pipeline stages, since an HVAC company and a landscaper don't sell the same way.

2. You send a quote. Quotes are built from the contractor's own price catalog: measures (linear feet, square feet, units), options the customer chooses between, and line items priced from those. A customer can pick "good," "better" or "best," or combine add-ons. The quote goes out as a branded PDF with the contractor's logo and prices.

3. The customer signs on their phone. They tap a link and sign from the driveway. This was the part I cared about most, and I'll get to why in the architecture section. Once a contract is sent, the document is frozen. What the customer signs is exactly what they saw, and nothing can change under them afterwards.

4. You get paid. The customer can put down a card deposit when they sign. When the job is finished, the balance is charged against the card already on file. The invoice always goes out before the charge. Both payments are recorded in a way that matches what the customer agreed to.

Several other pieces sit around that loop:

Follow-up that actually happens. When a lead goes quiet, Relayhand drafts a text for you. The draft waits in a queue for you to approve. Nothing is ever sent to a customer automatically. I made that a hard rule, because a contractor's reputation is local and one wrong message costs more than ten missed ones.
A schedule that works like a dispatch board. Crews are rows and days are columns. You drag a visit to move it. There's a separate field app for the person driving to the house, and it keeps working without signal and syncs when the truck gets back into coverage.
Recurring service plans. Maintenance contracts (quarterly HVAC checks, lawn care, pest control) are signed once, and every completed visit then gets invoiced and billed on the terms in that agreement.
Job costing and time tracking, so the owner can see what each job actually earned.
An MCP server, so an assistant like Claude can work with the CRM. It can look up a customer, draft a reply or pull a report. Anything that moves money takes two steps: the assistant previews the action, a person approves it, and only then does it run. Every money action is written to an append-only log.

How it's built

This is dev.to, so here's the part you probably came for.

Stack: React 18, TypeScript and Vite on the front end. Vercel serverless functions for the API. Supabase (Postgres) for the database and auth. Stripe Connect for payments. Vitest for tests. I build it alone.

Multi-tenancy is enforced in Postgres, not in route code. Every table has row-level security, in three tiers. Everyday records like customers, quotes and jobs can be written by any member of the business. Money tables like payments and stored-card mandates can only be written by an owner or admin. Logs like the email log and the AI action log can't be written by any user at all; only the server writes them. The reason is that Supabase's REST endpoint is reachable directly with the public key and a valid login token. A role check in an API route that isn't backed by a policy in the database isn't really a check.

Contracts are immutable in four layers. This is where most of the design effort went:

A published contract template is frozen by a database trigger. Editing it creates a new version.
A quote pins the exact template version when it's sent.
The rendered HTML is stored at send time, and the signing page serves that snapshot. It never re-renders.
A second snapshot is stored at the moment of signature, and the signed PDF is archived with a hash that a nightly job re-checks.

Changes to a signed contract don't edit it. They go through a separate amendment document that names the contract it changes. I also keep byte-exact snapshot tests of the rendered contracts, because a diff in a legal document should never slip through as a "small refactor."

Payments are direct charges on the contractor's own Stripe account. Relayhand doesn't hold anyone's money. Every Stripe call that touches a contractor's money passes their connected account ID, and every one-shot charge carries an idempotency key, so a retry can't double-charge a customer.

Two bugs that taught me something

The .js extension that took production down. Some of my TypeScript modules (the contract renderer, for example) are shared between the browser and the Node serverless functions. Vite resolves import { x } from './contractTokens' without complaint. Node's ESM resolver doesn't: it wants './contractTokens.js', even though the file on disk is .ts. I shipped one import without the extension. Typecheck passed, lint passed, the build passed, the tests passed. The contract view and signing endpoints then failed at module load with FUNCTION_INVOCATION_FAILED before any handler ran.

The fix took one line. The lesson was that my checks all ran in the wrong environment. Now there's a test that walks the import graph reachable from api/ and fails on any relative import without .js, plus a test that actually loads every API module in Node. After every deploy I curl the endpoints too. A 401 means the function loaded; a 500 means it didn't.

Six of my seven cron jobs never ran. Vercel Cron calls your endpoint with GET plus a bearer secret. Most of my cron handlers began with if (req.method !== 'POST') return 405, a reasonable-looking guard I'd copied from my write routes. Locally I triggered them with POST, so they worked. In production every scheduled run was refused politely, and nothing alerted me, because a 405 isn't an error from Vercel's side. Now all crons go through one shared method check, and a test reads vercel.json and checks every scheduled path.

Both bugs had the same root cause: a guard that passes in the environment you test in tells you nothing about the one you deploy to. I now treat "what would this check not see?" as part of writing the check.

Pricing

Flat monthly prices per business, not per seat:

Solo: $49/month, 1 person
Crew: $149/month, up to 5 people, adds scheduling, job costing, time tracking and service plans
Shop: $299/month, up to 15 people

There's no annual plan and no "contact sales" tier. Every plan has a 14-day free trial.

What's next

I'm going to be honest about where things stand. Relayhand is early. The core loop (lead, quote, signed contract, deposit, schedule, invoice) is what I've put the most work into. Some integrations are built but haven't been tested end to end against their live providers yet, and I won't advertise them until I've seen them work. If that sounds overly cautious for a launch post, it's on purpose: a contractor who pays for something because a marketing page said it works deserves for that to be true.

If you run a trade business, or you're related to someone who does (everyone seems to be), I'd love for you to try it and tell me where it falls short: relayhand.com.

If you're a developer, I'm happy to go deeper on any of this in the comments. That includes the RLS setup, the contract snapshot design, two-step confirmation for AI tools that move money, or how I test serverless code that my unit tests can't reach.