A Michigan tree service

A hiring pipeline that runs itself

A careers site with four open roles and an applicant pipeline — resume storage, bot filtering, and automatic confirmation emails — built for a Michigan tree service whose real problem was filling crews, not web design.

The problem

Trades operators lose applicants to friction. Paper applications, unanswered voicemails, and a hiring inbox nobody watches mean the crew stays short even when interest exists. The brief was not a website — it was a pipeline: get a working applicant from a Facebook or Indeed post to the hiring manager without a human in the middle.

What we built

A one-page, mobile-first careers site — no build step, loads fast on a phone in a truck — with four open roles (tree climber, bucket operator, equipment operator, laborer), each backed by a job-posting PDF used directly in Facebook and Indeed posts. One form, one action: apply.

The pipeline behind the form

On submit, the resume lands in private storage (time-limited signed links, never public), the applicant record is written to a standalone database table, the hiring contact gets an email with the resume attached, and the applicant gets their own confirmation so they know it landed. The two emails are tracked independently — a bounced applicant confirmation and a failed internal notification are different problems, and the system can tell them apart.

Keeping bots out without losing humans

Bot defense is layered: a honeypot field catches naive form-fillers, and a managed challenge blocks scripted submissions. The failure mode is deliberate — if the bot check itself cannot run, a real person is never silently rejected; only a failed challenge is refused. The applicant always sees an instant success screen; the machinery runs after.

Built to hand over

The applicant table and resume bucket are deliberately standalone — no entanglement with our internal systems — so the whole pipeline, data included, can be handed to the client outright. Their applicants are their asset, not ours.