DEV Community: Akshay Sharma

I built a hiring platform where candidates never apply - here's how the matching works

Akshay Sharma — Sat, 05 Sep 2026 15:45:59 +0000

The problem I was trying to solve

Candidates send hundreds of applications.
Companies receive thousands of resumes.
Most candidates never hear back.

Both sides exhausted. Most of the effort wasted.

The insight that changed my thinking: senior engineers don't apply to jobs. They get headhunted. A recruiter finds them, reaches out, and they evaluate the opportunity on their terms.

Why is that only available to senior people?

It shouldn't be.

What I built

Wrkmark Jobs — a hiring platform where candidates never apply.

Here's how it works:

Candidates create one profile
Algorithm scores them against active roles
Companies see their top 15 ranked matches
Companies reach out. Candidates choose to respond.

No applications. No cover letters. No ghosting.

How the matching algorithm works

This is the part I want to talk about technically.

The algorithm scores each candidate against each job across four dimensions:

Skills — 40% of score

Simple exact match (case-insensitive) with a synonym map for common variations:

const SKILL_SYNONYMS: Record<string, string[]> = {
  'ruby on rails': ['rails', 'ror', 'ruby-on-rails'],
  'kubernetes': ['k8s', 'kube'],
  'postgresql': ['postgres', 'pg', 'psql'],
  'javascript': ['js', 'es6', 'ecmascript'],
  // 60+ mappings
}

A candidate with "RoR" on their profile matches a job requiring "Ruby on Rails". Simple but surprisingly effective at this scale.

Salary — 25% of score

All salaries converted to USD for comparison using live exchange rates (Frankfurter API).

The logic:
job_max_usd >= candidate_min_usd → score 100
job_max_usd < candidate_min_usd → score 0

If a company offers $80-120K and a candidate expects $30-50K — that's a great match. The company can easily meet the candidate's
expectation. Score: 100.

The common mistake is calculating range overlap. Overlap fails in the overqualified-offer case.

Experience — 20% of score

Years of experience vs role requirement.
Meeting or exceeding → full score.
Under by 50% → partial score.

Timezone — 15% of score

This one I'm most proud of. Most platforms do binary bucket matching:

"US East" or not

We calculate actual UTC hour overlap:

const UTC_WINDOWS = {
  us_east: [14, 22],   // 9am-5pm EST
  europe: [8, 16],     // 9am-5pm CET
  apac: [1, 9],        // 9am-5pm IST/SGT
}

function getOverlapHours(window1, window2) {
  const start = Math.max(window1[0], window2[0])
  const end = Math.min(window1[1], window2[1])
  return Math.max(0, end - start)
}

6+ hours overlap → 100 score
4-5 hours → 80
2-3 hours → 50
1 hour → 25
0 → fail

A US East job and a European candidate have 2 hours overlap (14:00-16:00 UTC). That scores 50 — workable with async communication. Better than the binary "not US East = zero" approach.

Hard filters (before scoring)

Before scoring, candidates must pass:

Employment type match
Work arrangement match (remote/hybrid/onsite)
Visa/sponsorship check (checks work_authorized_countries)

The visa check was interesting. An Indian citizen applying to an Indian company doesn't need sponsorship even if they've marked "needs_sponsorship: yes" globally.
We check work_authorized_countries first.

Why not ML?

At current scale — a few thousand candidates and hundreds of jobs — pure algorithmic matching is more accurate than ML.

ML needs large datasets to find patterns.
With small data, it overfits.

The algorithmic approach is also:

Explainable (candidates see exactly why they matched)
Debuggable (I can trace every score)
Fast (no model inference, just math)

I'll add ML when I have 100K+ matches worth of outcome data.

The paid candidate model

Candidates pay $9/year globally (₹99 in India).

Controversial? Yes. But here's the logic:

Free platforms have millions of profiles.
Most are fake, inactive, or outdated.
Companies stop responding because signal is lost.
Candidates get ghosted.

$9/year is a filter. Every profile on Wrkmark
is someone who meant it enough to pay.
Companies know this. They actually respond.

On free platforms, candidates are the product.
On Wrkmark, they're the client.

Tech stack

Frontend/Backend: Next.js 14 App Router
Database: Supabase (PostgreSQL + Auth + Storage)
Hosting: Vercel
Payments: Dodo Payments (MoR — handles global tax compliance without company registration)
Email: Resend
Resume parsing: Gemini 3.6 Flash (native PDF, no pdf-parse library)
Analytics: Umami (privacy-first)

What's live

Wrkmark Jobs — open beta.

Looking for candidates: engineering, product, data, design, DevOps. India, US, UK, EU, Southeast Asia. Remote-first.

Candidate membership: ₹99/year India, $9/year global.
Company job post: ₹5,000 India, $149 global.

Happy to answer questions about the algorithm, the stack, or the two-sided marketplace problem.

How I built a file-sharing tool where even I can't read your files (zero-knowledge architecture in Next.js)

Akshay Sharma — Tue, 14 Apr 2026 05:53:34 +0000

There's a moment most developers have experienced.

You need to send a sensitive file - a private screenshot, a contract draft, a credential - and your options are: email it (it lives on both servers forever), WhatsApp it (metadata collected, file cached), or throw it on Google Drive (permanently indexed, permission revoke does nothing to cached versions).

None of these give you control. The file outlives the intention.

So I built BurnShot (burnshot.app) - a zero-knowledge, ephemeral sharing tool where files cryptographically erase themselves after a set view count or timer. Here's the architecture, the decisions, and the parts I got wrong.

The core problem with 'disappearing' file tools

Most tools that claim to offer disappearing or expiring files do one of two things: they either mark a file as 'deleted' in their database (but keep the bytes in storage), or they rely on the client to stop rendering the file without actually deleting it server-side.

Neither is deletion. Both are theater.

Real ephemeral sharing requires three things happening simultaneously:

The file must be encrypted before it touches any server
The server must never possess the decryption key
Deletion must be synchronous — not a background job

The encryption model: keys in the URL fragment

When you upload a file on BurnShot, AES-GCM encryption runs entirely in the browser using the Web Crypto API before the file is transmitted. The encrypted blob is what gets stored in Supabase Storage.

The decryption key is embedded in the shareable URL after the # (hash fragment). This is the critical part: URL fragments are never sent to the server in HTTP requests. They exist only in the browser. My server has never seen your key.

`// Simplified client-side encryption flow
const key = await crypto.subtle.generateKey(
{ name: 'AES-GCM', length: 256 }, true, ['encrypt', 'decrypt']
);
const encrypted = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv }, key, fileBuffer
);
const exportedKey = await crypto.subtle.exportKey('raw', key);
const keyBase64 = btoa(String.fromCharCode(...new Uint8Array(exportedKey)));

// Key goes into the URL fragment — never sent to server
const shareLink = https://burnshot.app/view/${fileId}#${keyBase64};`

This means if you subpoena my server, you get encrypted blobs. The keys don't exist there.

Auto-detonation: synchronous, not scheduled

Every file payload has a view_limit and a TTL stored in Postgres. Here's what happens on every access:
`-- Supabase RPC called on every view
UPDATE payloads
SET view_count = view_count + 1
WHERE id = $1
RETURNING view_count, view_limit, expires_at;

-- If threshold hit: immediate purge
SELECT storage.delete('payloads', file_ref);
DELETE FROM payloads WHERE id = $1;`

The deletion is atomic within the RPC. The file is gone before the HTTP response returns. There is no window where a race condition leaves the file accessible after its limit is hit — this was v1's critical bug, and I'll explain that shortly.

OTP email verification without storing emails (you can share files without email verification also)

If a sender wants to restrict access to a specific recipient, they add the recipient's email. Here's the privacy-preserving part: that email is SHA-256 hashed on the sender's device before it ever hits the API.

My database stores hash(email), never the plaintext. When the recipient enters their email to access the file, it gets hashed client-side and compared. I cannot tell you who the intended recipient was.

Ofcourse third party service for email - Resend has to know the plaintext email to deliver the message, and their logs will show the email body (the OTP). On Resend also I have set very short retention period which means this data gets deleted within few days.

But if a hacker breaches Supabase, they get encrypted blobs and hashed emails. They cannot read the files, and they don't know who the users are.
If a hacker breaches Resend, they get a list of email addresses and 6-digit numbers. But Resend has absolutely no access to the files, the decryption keys, or the database links.

Neither system holds the complete puzzle. Thus, at any given point of time through strict separation of concerns, your data remains impenetrable.

Anti-download canvas rendering

Files render inside a canvas element rather than native img or embed tags. This disables right-click save, browser download shortcuts, and most automated scrapers. It doesn't prevent screenshots — nothing on the web can. But it removes one-click exfiltration, which is the threat model for most use cases.

What I got wrong in v1

Version 1 ran file deletion in a background cron job every 5 minutes. The first comment on my Hacker News post was: 'Web based! receiver can take a screenshot very easily.'

They were right about the deletion window - there was a 5-minute gap after the final view where the file was still technically accessible. I rewrote the deletion logic to be synchronous within the RPC that same night. The screenshot comment was also valid — I added canvas rendering after that.

The second thing I got wrong: I launched with images only. Within weeks, the most requested feature was PDF support. Contracts, NDAs, payslips - the real sensitive sharing is documents, not photos. I added PDF support in v1.2 and it's now the majority of uploads.

The stack

Next.js 14 + TypeScript - App Router, server actions for API layer
Supabase — Postgres for metadata, Storage for encrypted blobs, Edge Functions for RPC
Vercel — Edge deployment, sub-100ms global response
Web Crypto API — all encryption/decryption in the browser

What's next

Watermarking: burning recipient identity into canvas renders for traceability
Audit trail for Enterprise without breaking zero-knowledge model
CLI tool for developers integrating ephemeral sharing into pipelines The tool is free at burnshot.app. Enterprise dedicated instances (isolated DB, custom domain) are available at $100/month for firms with compliance requirements.

Happy to go deep on any part of the architecture in the comments - the Web Crypto API has some gotchas around key serialization that took me a while to work through.