Build story · 5 min read
How We Built SealedApply: From Napkin to Launch
Published October 4, 2026 by The Huckleberry Co.
SealedApply started with a familiar mess: a small committee hiring for one important role, with resumes scattered across inboxes and no shared place to decide. Here's how it went from that problem to a working app. It's also a fair picture of what building with us looks like.
The problem, in one sentence
People who hire once in a while need a fair, private way to review applications together, and big hiring software isn't built for them.
Applicant tracking systems are made for recruiters who hire every week. Founders making a first hire, nonprofit boards and search committees make do with email and a spreadsheet instead. Resumes get forwarded around, reviewers look at different versions, and the decision can come down to whoever spoke last.
Who it's for
- Founders making a first hire
- Nonprofits and small teams
- Boards and search committees
- Small businesses without anyone in HR
We wrote the promises first
Before any code, we wrote the website. Every promise on it became a line in a scoping document, next to the feature that keeps it. "Resumes never travel as email attachments." "A blind first pass that hides names." "Every applicant hears back." When a decision changed a promise, the website changed with it, so the site never says something the app doesn't do.
What we built first
- A branded apply page, with one link per role
- Private uploads that only the hiring team can open
- Ratings and comments kept per reviewer, with a flag when the team disagrees
- A blind first pass that hides names and contact details
- An AI hiring advisor that summarizes each application, explains strengths and gaps against the job description, and suggests interview questions. Personal details are removed before the AI sees anything, and every decision is made by a person.
- A confirmation email to every applicant
What we left out on purpose
- Open sign-up. The first version is invite-only, so we can watch every new team get set up and fix what confuses them before it confuses a hundred teams.
- Recruiter features. Sourcing tools, job-board syndication and sales-style pipelines. Search committees don't need them, and every extra button makes the app harder to learn.
- AI where the law asks for more. Some places, like New York City, require bias audits for automated hiring tools. The AI advisor is switched off for roles there.
How long it took
The website and the scoping document came first, in a single day. A working version of the app followed within days, in time for a real search committee to test it, and its first real search opens this week.
We move quickly because we use AI coding tools heavily. Every change also gets a second, independent review before it ships (the idea behind our Adversarial Review guide), and a person checks the result in a real browser.
What we learned in week one
Our first full walkthrough found a real gap: a new job went live the moment you saved it, with no chance to preview it. That's fine for us and nerve-wracking for a search chair. So drafts, a preview button and a clear Publish step are next, along with a copy-link button and a required choice of remote, hybrid or in-office.
That's the point of launching small. The first real users show you what to fix, while the fixes are still small.
The build, at a glance
- The problem in one sentence
- A clear picture of who it's for
- Promises written down before any code
- The smallest version that keeps every promise
- Real users in the first week
- Fix what they trip on, then keep going