Dan Trapp

PLG / activation wedge / Recruiting

Dover Hiring Planner

A self-serve hiring planner built from Dover's marketplace data.

A PLG-style planner that helps a founder understand likely hiring cost, comparable searches, who should help first, and whether a marketplace route makes sense.

Status

Prototype

Timeline

Built from Dover's public 901-row benchmark dataset

Domain

Recruiting

Why

PLG / activation wedge

Dover Hiring Planner self-serve hiring interface
Self-serve hiring plannerPrototype

Stack

Languages, services, data sources, and operating pieces behind the build.

ReactViteDjangoPostgresNeon

Code Proof

What The Build Actually Contains

LOC

3.5k+

Source files

43

Backend

Django

Data

901 rows

Product proof

Dover Hiring Planner self-serve hiring interface
Self-serve hiring planner

Implementation

Code Behind The Surface

Planning before the sales handoff

ts

The core move behind the product surface.

const plan = planHiring({
  roleTitle,
  companyStage,
  companyLocation,
  hiringPriority,
});

routeQualifiedDemand(plan.fit, plan.urgency);

Product Model

ts

The useful answer has to be modeled before the UI can make it obvious.

type ProductSurface = {
  input: "Recruiting";
  signal: "What could a founder learn before opening a search if the marketplace data were pack";
  proof: string[];
};

const surface: ProductSurface = {
  input: "Recruiting",
  signal: "Cost, comparable searches, and who should help first.",
  proof: [
  "Self-serve hiring plan",
  "Cost range estimation",
  "Comparable search matching",
  "Recruiter route recommendation"
],
};

Hard Part

ts

Every build has a constraint: data quality, workflow shape, trust, speed, or operational risk.

const constraint = {
  project: "Dover Hiring Planner",
  status: "Prototype",
  category: "PLG / activation wedge",
  hardPart: "This is a classic PLG wedge: make the first useful answer available without a call, then use that interaction ...",
};

shipSurface(constraint);

Project Logic

Why This Exists

The point is not to show another screen. It is to show the gap, the build constraint, and the proof of work.

Mission

What could a founder learn before opening a search if the marketplace data were packaged as a product?

Hiring-marketplace demand starts before the transaction. Founders want to know cost range, comparable searches, route fit, and who should help before they commit to a search motion.

Build

What Had To Work

I built a planner backed by normalized benchmark data that gives an immediate recommendation and fallback frontend logic if the API is unavailable.

Why It Matters

901 benchmark hires

Compresses the first hiring-fit question into a self-serve plan instead of a sales conversation.

Hard Parts

Make The Signal Useful

Answer the founder's first hiring question before asking for a sales call.

Turn The Work Into A System

I built a planner backed by normalized benchmark data that gives an immediate recommendation and fallback frontend logic if the API is unavailable.

Prove The Wedge

This is a classic PLG wedge: make the first useful answer available without a call, then use that interaction to reveal fit, urgency, and buying context.

Decisions

Self-serve hiring plan
Cost range estimation
Comparable search matching
Recruiter route recommendation

Next Move

I would add email capture at the moment of high intent, segment recommendations by role complexity, and route qualified searches into a marketplace or sales workflow.

Tell Me About Your Project

Bring Me The Bottleneck.
I’ll Build The Answer.

Tell me what people are trying to do, where the current path breaks, and what kind of useful answer should exist.

Market Gap

Demand exists, but the answer is missing.

Workflow Drag

The work is still too manual, slow, or scattered.

Product Wedge

A small surface could prove the larger opportunity.

Quick Note