I Built a Harvest Crew a Backend. Then I Took It Out.

In January, Aubri Farris filled out the contact form on my site. Farris Harvesting, a custom harvesting crew in Kansas, had no website, and hiring season was about a month away. They needed a place for job seekers to apply and for growers to learn who they were.

We launched on February 20. That part went the way a web project should. The part worth writing about happened in October.

What I built at launch

The public site was four pages: Home, About, Contact and Employment, styled in the Case IH red the crew runs in the field, with their own harvest footage as the hero video. Behind it, I built more:

• A database and admin portal to track job applications
• Transactional email for the contact form, with auto-replies
• Google Workspace addresses on the new domain

All of it worked. Almost none of it got used.

What the client actually used

The client already had a Google Form for applications, and it collected exactly what they needed, including uploads and sensitive details. Keeping that data inside Google was the safer choice, so the website linked to it. Contact messages went to the Gmail address their customers already knew.

Eight months in, the admin portal had never been switched on and the Workspace inbox was idle. Their real workflow was Gmail plus a Google Form. I was paying for, and patching, systems that did nothing for them.

Taking it out

In October I converted the site to a static export and removed everything the business wasn't using:

• The admin portal, login pages and API routes
• The database and email service, and their packages
• The Google Workspace subscription, about $17 a month

The forms now hand off to the crew's existing Gmail. The site is a set of plain files with no server, no database and no login page on the internet.

What changed for the client

• Nothing to maintain. No database to back up, no admin accounts to secure.
• A smaller attack surface. You can't break into a login page that doesn't exist.
• Fewer bills. One recurring subscription gone, and the domain moving into their own name.
• The same website. Visitors see the same pages, photos and application link.

The lesson

I built for the hiring workflow I imagined, not the one they had. That's a common mistake, and it's the same one I look for in cloud accounts: services that were reasonable when they were set up, still running and still billing, with nobody using them.

The fix is the same at any size. Look at what's actually used, keep what earns its place, and remove the rest. A website that does less can be the better website.

"Charles did a fantastic job creating our website. He was quick to follow up on next steps and made the process quick and easy." — Aubri Farris, Farris Harvesting