The challenge
Hiring rarely falls apart in one dramatic moment. It frays slowly. The role brief lives in one document, candidates arrive through several different channels, interview feedback is scattered across messages, and by the time a decision is made, it's hard to say exactly why it was made. Recruiters and hiring managers end up chasing updates instead of acting on them.
Applicants have a different problem. Finding a suitable role only helps if they feel ready, and able, to take the next step.
Tinker Digital built Talon to bring those pieces together. I led the engineering work from January to September 2026, connecting the employer, recruiter and applicant journeys while keeping each workspace focused on the decisions its users needed to make.
The first assumption that didn't hold
The employer side got going quickly. We had jobs, and employers and recruiters were signing up. Applicants were a different story.
Before launch, I reached out to 113 people who had previously asked me for help finding work. About seven signed up. Roughly three actually used the platform. Free access and real jobs, it turned out, weren't enough.
So we talked to people, including those who registered and never came back. Some didn't have a CV. Some didn't feel ready for interviews. Others were simply worn down by rejection. A later focus group gave us the most direct feedback of all: Talon was doing too much. There were so many choices that using it felt like work before anyone had even applied for a job.
That changed our question from "What else can we add?" to "What does this person need to do next?" We simplified the design, removed features, and cut down the number of decisions on the applicant path. We also made matching easier to understand. Instead of a vague match label, applicants can now see which parts of their profile relate to a role.
| Before | After |
|---|---|
| Many choices before applying | A clearer next action on the applicant path |
| A match label without context | Profile details that explain the match |
The published account does not yet establish a comparable post-redesign activation rate. The change is a documented product decision; its effect on applicant activation still needs a like-for-like measure.
One shared process, separate workspaces
The hiring side still had to support a genuinely complex journey. The engineering approach was to keep roles, candidates, interviews, feedback, offers and outcomes connected underneath, while showing each person only the work that's relevant to them.
In practice:
- Hiring managers agree the role and the interview plan.
- Applications, referrals and agency submissions all land on the same role record, along with their source and notes.
- Interviewers can leave feedback on candidates they're assigned to, without needing a paid hiring seat.
- Recruiters keep client briefs, submissions, follow-ups and placement progress together.
- Applicants get their own focused space for their profile, applications, offers and contact preferences.
The result is a decision trail that stays intact. A team can see what's waiting, who owns the next step, and the evidence behind each decision, without piecing the story back together from email threads and spreadsheets.
Engineering for trust and change
Talon runs on a Next.js web app, a Go backend and a Flutter mobile app.
The backend is the source of truth for hiring records, and it enforces workspace membership and permissions. Hiding a button in the interface is never treated as access control. Hiring data also has a life well beyond the application form, so candidate consent, retention, export and deletion are built as proper product workflows rather than afterthoughts.
A hiring decision often needs to trigger a message or an external integration. Sending that message inside the request would tie the decision to a provider response. If the database commit succeeded but the process stopped before delivery, the decision would stand with no message. Sending first has the opposite problem: a message could describe a decision that later rolled back.
Talon commits the decision and its communication intent in the same PostgreSQL transaction. A worker then claims the intent and delivers the email, SMS or push notification. Failed deliveries can be retried with backoff; repeated failures are held for review. A separate platform outbox carries events to external integrations. The hiring record stays authoritative through either failure path.
| Step | What happens |
|---|---|
| 1. Save | Commit the hiring decision and communication intent together. |
| 2. Claim | A worker leases pending work without blocking other workers. |
| 3. Deliver | Send through the appropriate channel or integration. |
| 4. Recover | Retry failures, or hold exhausted attempts for review. |
Results and what's next
Talon is now used by more than 17 businesses. Across four businesses, the reported average time to hire fell from roughly one to two months to 11 days. That's a strong signal for keeping briefs, candidate movement, feedback and decisions in one flow, though it isn't a promise that every customer will see the same result.
The applicant research gave us a different kind of result: a clearer direction. We stopped treating more features as progress and started judging each screen by a simple question: does it help someone take their next step with confidence?
Talon is still evolving, but that principle now shapes both sides of the platform. Keep the context. Make the next step obvious. Cut anything that doesn't help the decision.