DEV Community

Cover image for I Built a Hiring Tool After Watching Founders Lose Great Candidates to Google Forms
Sunil Kumar
Sunil Kumar

Posted on

I Built a Hiring Tool After Watching Founders Lose Great Candidates to Google Forms

Last year I watched a founder friend spend six weeks trying to hire a backend engineer.

She wasn't bad at hiring. She had a strong job post, she was getting applications, and she had good instincts about candidates. The problem was her process. Applications were landing in a Google Form. Status tracking lived in a color-coded spreadsheet that she and her co-founder were both editing, independently, with no shared source of truth. Resumes were Dropbox links embedded in spreadsheet cells. Communication with candidates happened through whatever Gmail tab she had open.

Three weeks in, she got an email from a candidate she'd really liked. He'd accepted another offer. She dug through her inbox to find their last exchange — she'd never sent the follow-up she'd meant to send.

That candidate would have been perfect. The process lost him, not her judgment.

I'd seen this exact pattern enough times that I decided to do something about it. The result is HireFormly — a simple applicant tracking system built specifically for small teams who have outgrown Google Forms but don't need (or want to pay for) enterprise hiring software.

I want to talk about what I learned building it, because the problem is more interesting than it looks.


Why Google Forms is the default — and why it breaks

Google Forms became the default hiring tool for small companies for completely rational reasons:

  • It's already paid for if you're on Workspace
  • Anyone can build a form in 10 minutes
  • Responses auto-populate into Sheets, which feels organized

The problem isn't that Google Forms is bad software. It's that it's the wrong software. It's a survey tool. Hiring isn't a survey.

Here's what actually happens when you use Google Forms for hiring at any real volume:

No state. A Google Sheet is a list of rows. There's no concept of a candidate being "in phone screen" or "rejected" or "offer pending." You bolt this on with color coding or a status column, but it degrades the moment more than one person touches the spreadsheet. I've seen companies with six different color conventions across the same sheet because three people each added their own system.

No continuity. Resumes come in as Drive links, Dropbox links, or PDF attachments to the form. Those links break. Those attachments get buried. Three months after a hiring round closes, finding a specific candidate's resume requires archaeological work.

No communication pipeline. When someone submits a Google Form, nothing happens automatically. No acknowledgment email. No "here's what to expect" message. No rejection notice when they don't move forward. Candidates just wait in a void. The best candidates — the ones with options — move on. The ones who wait are often the ones who have nowhere else to go.

The numbers are brutal. Research consistently shows that 60–65% of candidates never receive any status update after applying. 58% have declined job offers specifically because of poor hiring experience. And the candidates most likely to abandon a broken process are the ones with the most options — exactly the people you're trying to hire.


What I decided to build

I didn't want to build another enterprise ATS. Greenhouse, Lever, and Workday exist. They're good products for the teams they're built for. A 500-person company with a dedicated recruiting team and 200 open roles needs those products.

What I wanted was the smallest possible thing that would fix the real problems:

  1. One dashboard for all candidates across all roles — so nothing gets lost and anyone on the team has the same view
  2. Custom application forms per role — so you're not asking an engineer and a designer the same generic questions
  3. A branded careers page — generated automatically from your open jobs, no developer required
  4. Status tracking — mark candidates as new, shortlisted, interviewing, offered, hired, or rejected, and have it be visible to the whole team
  5. Everything in one place — resumes, application responses, status, all tied to the same candidate record

That's HireFormly. It's not trying to be Greenhouse. It's trying to be the minimum viable hiring process for a team of 5–30 people that currently has no process at all.


Some things I learned building this

The spreadsheet is the real competitor. Not other ATS products. The thing I'm competing against is the behavior of defaulting to a Google Sheet because it's already open. The product needs to be faster to set up than building a Sheet, and more obviously useful within the first 10 minutes. Two-minute setup was a design constraint, not a marketing line.

Candidate experience is an employer problem, not a candidate problem. The market talks about "candidate experience" like it's a nice-to-have. It's not. A bad candidate experience directly reshapes your applicant pool — the highest-quality candidates, the ones with the most options, are also the ones with the least tolerance for disorganized processes. They don't persist through friction out of desperation. They move on. By the time you've driven off the top 30% of your applicant pool through process friction, you're selecting from the remainder. That's a selection effect most companies never calculate.

Mobile is not optional. 70% of job applications are started on a mobile device. Google Forms works on mobile in the same way that a desktop website technically loads on a phone — it functions but it's not designed for it. File uploads frequently fail. Long forms are miserable to complete. If your application isn't mobile-first, you're losing a majority of applicants before they finish. Every form in HireFormly is mobile-first by default.

"Free to start" is the hardest feature to ship honestly. The free plan has to be genuinely useful, not artificially crippled to push upgrades. If someone can run their entire early-stage hiring process on the free plan, that's the right call — because the alternative is they don't use the product at all, and the problem I'm trying to solve doesn't get solved. Unlimited jobs and unlimited form submissions on the free plan wasn't a growth hack. It was the minimum needed to actually be useful.


The AI piece

One thing I shipped recently that I'm proud of: AI candidate scanning.

The problem it solves is specific. When you post a role and get 40 applications, reading all 40 resumes is genuinely the highest-value thing you can do. But it's also the thing that's easiest to procrastinate on, do poorly when rushed, or approach with unconscious pattern-matching rather than actual evaluation.

The AI scanning in HireFormly reads every application and surfaces the strongest candidates based on the role requirements — not keyword matching, actual contextual analysis of the application content. You still make every hiring decision. But instead of reading 40 resumes to build a shortlist, you're reviewing the AI's top 8 and making judgment calls from there.

It's in beta now. The goal isn't to automate hiring. It's to make the first pass faster and more consistent so the human judgment that matters is applied where it matters.


The tech stack

HireFormly is a Next.js app. The form builder uses a schema-driven approach — each form is defined as a JSON schema, rendered dynamically on the client. This is what lets the "takes 2 minutes to set up" claim actually be true — you're configuring a schema, not writing markup.

File uploads (resumes) go to cloud storage directly from the client using presigned URLs. No file touches the server. This matters both for performance and for keeping the surface area simple.

The careers page is statically generated from job data — it rebuilds on job create/update/delete. So it's fast without any client-side data fetching, and indexed properly by search engines.

The AI scanning runs server-side on job submission — not as a user-initiated action but as a background process. By the time the hiring manager opens the application dashboard, the ranking is already there.


What I'd do differently

Build the careers page first. I built the application form and dashboard first, then added the careers page. The careers page turned out to be one of the highest-value features for getting teams to commit to using the product — having a proper URL to share everywhere is the thing that replaces the Google Form link. I should have led with it.

Talk to users before building the AI feature. I built the AI scanning because I thought it was obviously useful. It is — but I built it before I'd talked to enough people about how they actually ran the first-pass review. The feature is right, but some of the specific signals it surfaces needed iteration that earlier conversations would have caught sooner.

Pricing is harder than building. The technical decisions were easier than the pricing decisions. "Free forever for the basics" sounds simple. What counts as basic? Where does the paid tier start that's genuinely worth the upgrade without feeling like the free tier was artificially limited? I'm still iterating on this.


If you're building a startup and still using Google Forms for hiring

I built this specifically for you, and it's free to start.

You get:

  • Unlimited jobs
  • Unlimited form submissions
  • Custom application forms per role
  • A candidate dashboard with status tracking
  • An auto-generated careers page
  • Excel export
  • Resume AI Scan

No credit card. No time limit. Takes 2 minutes to set up.

👉 hireformly.com

If you're at the stage where you're about to post a role and you were going to build a Google Form — try this instead. If it's not better than your spreadsheet in the first 10 minutes, close the tab and go back. No hard feelings.


The broader point

The pattern I saw with my founder friend isn't unusual. Most early-stage companies lose candidates not because they lose on culture or compensation or role quality — they lose because the mechanics of their hiring process are broken. The application goes into a void. The follow-up doesn't happen. The candidate who waited a week for feedback accepted something else while waiting.

These are fixable problems. The tools exist. The barrier is usually inertia — "we'll sort out our hiring process when we have more hiring to do." But the time to build a hiring process that works is before the critical role, not during it.

The first hire you make with a working process will be better than the first five you made without one.


HireFormly is at hireformly.com. I'm building this solo and I read every piece of feedback — if you try it and have thoughts, my contact is on the site.

Top comments (0)