Eave
Software for Home Inspectors
Eave is a solo SaaS startup I built end-to-end for home inspectors — the people who walk a house room by room before it changes hands and write up everything they find. It replaces a stack of disconnected tools (a report template in Word, a scheduling link, a separate e-signature service, a spreadsheet of clients) with one product that covers the whole job: building the report on-site, flagging issues automatically, collecting a signature, and getting paid.
It's a full-stack project in the truest sense — a Nuxt/Vue web app, a native Swift iOS app, a SQLite database behind Drizzle ORM, Stripe billing, and deployment on Cloudflare, all designed and shipped by me alone. The sections below walk through the major feature areas and the engineering decisions behind each one.

Custom Templates & On-Site Data Entry
Every inspection starts from a template — either one of the curated samples (Standard Home Inspection, Radon Testing, Mold Assessment, Sewer Scope, and more) or a fully custom one built from scratch. Templates are made of sections, subsections, and fields, and each field can be one of eight types: text, number, yes/no, dropdown, multi-select, rating, date, or photo/video. Inspectors can drag-reorder everything, set default values, and even define conditional visibility so a field only shows up when a prior answer warrants it.

The hard part wasn't the builder UI, it was the schema. Eight field types each need different configuration (a number field needs a unit and min/max, a multi-select needs min/max selections, a photo field needs a max count) without turning the template model into a pile of nullable columns or forcing a new database migration every time I want to add a field type. I settled on a typed, discriminated config object per field, validated with Zod, stored as JSON — so the schema evolves in code, not in the database, and TypeScript catches mismatched field configs at compile time.
On-site, inspectors fill out fields directly on their phone or laptop with autosave firing about 1.5 seconds after the last keystroke (with Cmd+S available to force it), and they can even tweak a field on the fly mid-inspection — attach a description, require it, rename it — without leaving the report to go edit the template separately.

Automated Warnings & Home-Care Rules Engine
As an inspector answers fields, Eave evaluates a set of rules attached to the template and automatically generates warnings (grouped by severity: Safety, Health, Structural, Electrical, Fire, Maintenance, Info) and home-care tips (grouped by cadence: Monthly, Quarterly, Bi-Annual, Annual, Seasonal, As-Needed) without the inspector having to write any of that language themselves. They can still edit severity, title, message, estimated cost, or timeline on any triggered item, hide ones that don't apply, or add fully custom ones.

The interesting problem here is what happens when a rule changes after an inspector has already hand-edited a warning it triggered — say I fix a typo in a rule's default message, or the inspector changes their answer to the underlying field. Naively re-running the rule would silently overwrite their edit; naively skipping re-evaluation would leave stale data. I built what I call stale overrides: once an inspector manually edits a triggered item, that edit is tracked separately from the rule's output and takes precedence, but the system still flags when the underlying rule or answer has since diverged, so nothing gets lost silently. The whole thing locks at publish time so a report can't keep mutating after it's been sent to a client.

Publishing, E-Signatures & Version History
Once an inspection is complete, the inspector previews the report as a client would see it, downloads a PDF, and publishes it — which generates a stable, shareable link. Clients can be routed through a pre-inspection agreement that requires a digital signature before they can view the full report, and the report itself locks until that signature is captured. Inspectors can unpublish and republish later (clients get notified of updates), and every publish is kept in a version history.

Signature capture supports both drawing (mouse, trackpad, or touch) and uploading an image, which gets resized and compressed client-side before it's stored — no point uploading a multi-megabyte photo of a signature. Publishing itself is gated behind a profile-completeness check (license number, business info, and a signature all need to be on file), and several of these capabilities — publishing to clients, agreements, and republishing — are gated behind the paid tier, which meant threading subscription status through the publish flow cleanly rather than bolting a paywall on top of it.

Built-in Client Scheduling
Rather than sending clients to a third-party Calendly-style tool, Eave has its own public booking page — no login required. Clients pick a day from a calendar that highlights open slots, pick a time grouped into Morning/Afternoon, and enter their contact details. Inspectors configure their own working hours per weekday, inspection duration, buffer time between jobs, and slot granularity, and org admins can set org-wide defaults that individual members inherit until they customize their own.

I deliberately modeled this as a request → confirm flow rather than instant-booking: a client submitting a time doesn't touch the inspector's calendar until the inspector explicitly confirms it. That avoids a whole class of double-booking bugs you'd otherwise have to solve with locking, since nothing is actually committed until a human approves it — but it still needs real-time conflict protection so two clients can't both be shown, and both request, the same slot before either is confirmed.

Repair Requests
This is a feature unique to Eave that came directly from talking to inspectors and buyer's agents: after a report is published, a buyer's agent (or anyone with the report link) can build a free "repair request" — the ask list sent to a seller — directly from the inspector's findings, instead of re-typing everything into a separate Word doc. They check off findings, choose a request type per item (Repair, Replace, Credit, Further evaluation, Other), add credit amounts or notes, and include custom items not in the report at all.

The builder reads live off the published report, which creates a reconciliation problem: what happens when a finding the buyer already referenced gets edited or removed from the report after the fact? Deleting the buyer's text outright would be destructive and confusing. Instead, a removed finding is flagged as "no longer in the report" in the repair request UI while the buyer's existing wording is preserved — the two documents can drift without either one silently corrupting the other.

Mobile Web & Native iOS App (Swift)
Inspectors spend most of their working hours walking through houses, not sitting at a desk, so the mobile experience isn't an afterthought. The mobile web app works fully in the browser — camera capture with automatic photo resizing and HEIC-to-JPEG conversion, a section navigator built for one-thumb use, and the same aggressive autosave as desktop. On top of that, I built a native iOS app in Swift for field use, with things a web app can't do as well, like one-tap turn-by-turn directions to the property via Maps.

Both clients talk to the same backend and data model, which meant designing the API and photo pipeline around the actual conditions inspectors work in — spotty cell service in basements and crawl spaces — rather than assuming a fast, reliable connection. Compressing and converting media client-side before upload, and making autosave resilient to dropped connections, mattered more here than almost anywhere else in the product. Template building stays web-only by design; the iOS app is purpose-built for fast data capture in the field, not administration.

Multi-User Organizations
Many inspectors work as part of a small business rather than solo, so Eave supports organizations: create one, invite teammates by email — even people who don't have an Eave account yet, via an invite link that activates on signup — and everyone in the org automatically shares templates, inspections, and clients. There's no manual sharing toggle per object; if you're in the org, you see the org's work.

That "automatic sharing" model was a deliberate simplification. A per-object ACL system would be more flexible, but for a small inspection business — usually a handful of inspectors covering for each other — it's also more complexity than the problem calls for. Org-level defaults (a default template, a default fee) let an admin standardize how the whole team works without policing every new inspection individually.

Stripe-Powered Billing
The free tier lets an inspector run up to 5 inspections with no card required and no time limit, which is enough to genuinely try the product on real jobs before paying. Eave Inspect Pro removes the inspection cap and unlocks photo/video attachments, publishing reports to clients, e-signatures, custom templates, and republishing. Billing is per-seat through Stripe — one subscription per user rather than per organization — with Stripe's customer portal handling self-serve plan management.

Per-seat rather than per-org billing keeps the pricing model simple to reason about for both sides — an org isn't blocked from adding a teammate by a shared seat pool, and I don't have to reconcile who "owns" the subscription when org membership changes. Feature gating (publishing, e-signatures, custom templates) checks subscription status at the point of use, which is what keeps the paywall from leaking into every corner of the codebase as a bunch of scattered conditionals.
Full guide: Subscriptions & billing →