Build the software home-service teams run their day on.
Zaras is the operating layer for home-service businesses: scheduling, estimates, invoices, customer records, and field work in one place. Close to operators, shipping every week.
01 · The problem
Service businesses are still run through handoffs.
The office has one version of the job. The technician has another. The customer hears a third.
A call becomes a note, the note becomes a scheduled visit, the visit changes on site, and the invoice has to explain what actually happened. We’re building one operating record that stays accurate from first call to paid invoice.
02 · How we work
A tight loop between field, product, and shipping.
We don’t build from a roadmap in isolation. The work starts with real service operators, turns into a narrow product bet, ships quickly, then gets tightened against actual use.
Watch the work.
A roadmap written in a room optimizes for what looks like work. The day breaks where you can only see by watching — a quote nobody recorded, a job booked for a day off, the third call about the same broken thing.
Cut the scope.
Most product mistakes are not building the wrong thing — they are building too much of the right thing. Narrow changes ship, get used, and get corrected. Broad changes ship late, land on assumptions, and rarely get undone.
Ship the change.
Software a real team depends on can’t coast on happy paths. The polish is the part that decides whether a dispatcher trusts you on day 30 — and that bar holds at release, not in a follow-up sprint.
Close the loop.
Shipping is not signal. Usage, support, and field reports are. Tightening or deleting parts of what just shipped is the loop working, not the loop failing.
03 · Open roles
Open seats on the core team.
Engineering
Design
Product & Field
04 · Working here
What good looks like here.
Take the boring problem.
The work that runs a service business — scheduling, dispatch, invoicing, follow-up — is the work most products skim. The depth is in the parts everyone else considers solved.
Prefer simple systems.
Clear states, fewer clicks, fewer exceptions. Elegant usually means easier to operate.
Own the full path.
A feature is not done at the happy path. Empty states, permissions, errors, mobile behavior, and edge cases count.
Make decisions legible.
Decisions, trade-offs, and product behavior should survive handoff.
05 · Hiring process
Direct, practical, and centered on real work.
-
Intro call30 min
30 minutes with a founder or team lead. We align on the role, stage, location, and what each side needs to know.
-
Craft conversation60 min
Walk us through something you have actually shipped — the trade-offs, what you would redo, who it served, and what changed after launch.
-
Working sessionHalf day
A small piece of practical work based on the role. No trick puzzles, no unpaid product strategy deck, no leetcode theater.
-
Team day & offerFinal step
A deeper team conversation, a field or product walkthrough when relevant, and a clear yes/no decision quickly after.