Skip to content
Ayoub
Back to work
SaaS platform

Hiring platform

One profile for a job and for freelance work

A marketplace where hiring and freelance work run on the same four steps.

  • Hiring and freelance work
  • 2025
  • Live
  • My own project

At a glance

What it is
Hiring sites and freelance sites are built as two different businesses. They are not, so I built the hard part once, for both.
Who it is for
Hiring and freelance work
Year
2025
Status
Live
What I owned
Everything technical

The situation

This is my own project, not client work. I chose it because it is a genuinely hard problem to model, and because I wanted to build a complete SaaS platform end to end rather than a demo of one.

The idea comes from one observation: hiring platforms and freelance platforms are built as if they were different businesses, yet both run on the same four steps: discover, express interest, evaluate, commit. Only the last thing differs: a job offer there, a contract in milestones here. And whoever works both ways, which is many people now, lives in two products with two profiles and two reputations.

What was actually wrong

The difficulty is in the modelling. One identity has to serve a person looking for a job, a freelancer offering services, and a member of a company that hires, and one person can be all of those at once. And trust between strangers has to be built into the system itself: money deposited before work starts, a pipeline record that is not rewritten after the fact, reviews written only after a real, completed contract. Any shortcut in these foundations surfaces later as a defect in every screen above them.

What we were building inside

  • One identity that works as a candidate, a freelancer and a company member, without splitting into two accounts.
  • A candidate's trail is a record that is added to, not edited: every move stays, with its date and its author.
  • The freelancer's money is deposited before work starts, and it moves only through named steps: fund, deliver, approve, release.
  • Company permissions follow the real working roles: billing does not see candidates, and interviewers do not move them.
  • One skill list for both sides: the same skills describe the job, the project and the person.

How I approached it

I built the expensive part once. One identity that can be talent looking and can belong to a hiring company, one skill list that describes jobs, projects and people, one four-step pipeline that both sides run on, and one layer for messaging, reviews and billing. At the end, two thin ends on top of it all: a job closes with an offer, a project closes with a contract whose first milestone is funded before work starts.

The harder half was trust between strangers. A contract's milestones are funded before the work, delivery is in the freelancer's hands, approval and release are two separate steps in the company's, and every step requires the state before it. And a candidate's trail is an append-only record: each move is written with its author, its time and its note, and a correction is a new entry, not an edit of what happened.

Inside the company, permissions are capabilities, not ranks: an interviewer submits a scorecard but does not move a candidate, billing funds and releases but does not open applicants' files. And a colleague's scorecard stays hidden from you until you submit your own, so nobody writes their opinion on top of somebody else's.

What it does

A marketplace where hiring and freelance work run on the same four steps.

  • One profile for both kinds of work

    The same profile carries a job-search status and a freelance availability. Interviewing for a staff role while running a freelance contract is an ordinary state here, not an edge case.

  • Four steps, both sides

    Discover, express interest, evaluate, commit. One search and one pipeline for jobs and projects alike, and only the close differs: an offer, or a funded contract.

  • Money is funded before the work

    Each milestone's amount is funded before work on it starts. The freelancer delivers, the company approves and then releases, and every step requires the one before it, so nobody jumps to the end.

  • A trail that is never erased

    Every move of an applicant is written as a new entry: from where, to where, who moved them, when, and with what note. The trail is not edited after the fact, and applicants see which stage they stand at.

  • Permissions cut to the role

    Roles inside a company are precise capabilities, not broad ranks: interviewers rate but do not move, billing funds but does not see candidates, admins shape the pipeline. Every capability is checked on the server on every request.

  • A pipeline the company shapes

    Every job carries the stages the company draws for it: screening questions, interviews, scorecards. A knockout screening question filters out automatically whoever fails it, so nobody spends time on applications outside the requirements.

The decisions

Every one of these had a real alternative and a real cost. Both are written down.

  1. 01The call

    Two specialised platforms, or one core with two ends?

    What I chose

    One core. Identity, skills, pipeline and messaging are built once, with two thin ends on top.

    Why

    The expensive thing in this kind of platform is the middle, not the ends: search, the profile, the pipeline, the trust. Building it twice means maintaining it twice and watching the copies drift apart. And whoever works both ways gets one profile and one reputation here.

    What I gave up

    Far heavier design up front than shipping two separate flows, and every decision in the core has to be right for both sides at once, which is a permanent constraint.

  2. 02The call

    The pipeline record: editable, or append-only?

    What I chose

    Append-only. A move is written and never touched; a correction is another move.

    Why

    An editable record is not a record, it is a draft. A candidate's trail can decide a piece of their working life, and it must not be quietly rearranged after the fact. When every move keeps its author and its time, the system's account is the only account.

    What I gave up

    Real mistakes stay visible in the record instead of being erased, and correcting one is a public addition. That is sometimes uncomfortable, and it is the price of a record that tells the truth.

  3. 03The call

    Money: direct payment between the two, or milestones held in deposit?

    What I chose

    Milestones in deposit. Each one is funded before it starts, and released after approval.

    Why

    Between two strangers the first real question is: who risks first? Funding up front answers it: the company risks the money before the work, and the freelancer sees the money held before writing a line. Approval and release are deliberately two separate steps, each with its own owner.

    What I gave up

    More friction on every contract: steps to understand and to follow. The easier road, an invoice paid afterwards, was faster and protected nobody.

  4. 04The call

    Separate skills per side, or one shared list?

    What I chose

    One list. The same skill describes the job, the project and the person, and synonyms get merged.

    Why

    If jobs were described in one vocabulary and projects in another, the same person would live with two dictionaries, and matching across the sides would be impossible. The single list is what lets search and matching work in both directions.

    What I gave up

    A shared list needs constant care: synonyms merged, duplicates cleaned, or it degrades for both sides at once instead of one.

  5. 05The call

    Colleagues' scorecards: always visible, or hidden until you submit yours?

    What I chose

    Hidden. You do not see your colleagues' cards on a candidate until you hand in your own.

    Why

    The first stated opinion drags the rest behind it, and interviews lose their value when they become echoes of whoever spoke first. Hiding until submission makes every card an independent judgement, which is the whole point of having several interviewers.

    What I gave up

    A mandatory step that slows the team down, and whoever wants a quick look at a colleague's view will not get it before writing their own.

How it moved through the stages

You tell me the idea

I started from the life of someone who works both ways: two profiles, two reputations, a history split across two platforms. Then I took the two processes apart step by step, and they turned out to be the same four-step path, differing only at the close.

You see the real screens

Most of the design time went into the model before the screens: where the job and the project meet and where they part, what gets deposited and when it is released, what is recorded and never edited. Mistakes here would have cost a rebuild, not a repaint.

You watch it being built

I built the core first: identity, skills, the pipeline with its record, then the money with its milestones, then messaging, reviews and subscriptions. Each part was finished for both sides together before moving to the next.

You launch, and I stay

The platform is published and runs in full, and it is presented here as what it is, a personal project: the widest published evidence of how I build a complete product.

See all six stages in full

What exists now

The platform is built in full and running: both sides, the pipeline, contracts with their milestones, messaging, reviews, subscriptions. I built it to learn from building the real thing in all its detail, and it is now the largest published example of how I work.

Revenue and growth belong to the client. I do not publish numbers I did not measure myself.

Screens

  • Hiring platform - screen 1
  • Hiring platform - screen 2

Built with

  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Prisma
  • Neon
  • Auth.js
  • Stripe
  • Zod
  • Tailwind CSS
  • shadcn/ui
  • Radix UI
  • UploadThing
  • Resend
  • Arcjet
  • Tiptap
  • Vitest
  • Playwright
  • Vercel

What you can check yourself

Other work

LiveMy own project

Smart booking platform

Booking for beauty centres: WhatsApp at the front, a full system behind it.

Next.js · TypeScript · Prisma · Neon · Better Auth · WhatsApp Business API

Read the full story
In development

Smart travel guide

A travel guide that stays with the traveller and deals with providers directly.

Next.js · TypeScript · Prisma · Neon · Better Auth · Vercel AI SDK

Coming soon
See all work
01 · You tell me the idea

At the same point this started from?

An idea, no technical co-founder, no obvious next step. That is the normal starting position.

Tell me about your idea