Job board requirements: a sample PRD and acceptance checklist
A job board needs more than a searchable list of vacancies. Its central rule is that each employer can see the applicants for its own jobs and cannot see anyone else's. That rule has to reach exports, attachments and API endpoints as well as the employer dashboard.
Download the job board requirements and sample PRD (.md)
The free document is an editable example for a niche board with on-site applications. It includes decisions to fill in, a role matrix, record lifecycles and acceptance scenarios. External apply links and paid listings are separate choices, not requirements silently added to every build.
Decide which kind of board you are building
Write down the audience, listing source and application destination first. A curated board maintained by one editor differs from a marketplace where employers create accounts and publish vacancies. A redirect to an employer's application system also has a different data responsibility from storing resumes yourself.
| Decision | Example choice in the downloadable PRD | What changes if you choose differently? |
|---|---|---|
| Listing ownership | Each job belongs to one employer organisation | An editor-only board may not need employer accounts |
| Application destination | Candidates apply on the board | External apply links remove the local application review workflow |
| Publication | Admin review before a job goes live | Automatic publication needs a different abuse and moderation policy |
| Monetisation | Free listings in the core example | Paid listings add payment events, entitlements, refund rules and reconciliation |
| Candidate visibility | Applications visible only to the candidate and owning employer, subject to the stated admin policy | A searchable resume database requires separate, explicit candidate visibility choices |
Do not describe unresolved options as accepted scope. Mark them for a decision and keep their dependent work out of the first build.
Define the role matrix
| Action | Visitor | Candidate | Employer | Administrator |
|---|---|---|---|---|
| Read published jobs | Yes | Yes | Yes | Yes |
| Edit a draft listing | No | No | Own organisation only | Under an explicit moderation policy |
| Submit or withdraw an application | No | Own application only | No | No impersonation by default |
| Read an application and attachments | No | Own application only | Own job only | Only if explicitly permitted and logged |
| Publish, reject or close any listing | No | No | May close own listing | Yes |
| Export applicant information | No | Own data if offered | Own job only | Same scoped policy as the screen |
“Admin” is not an excuse to leave the policy undefined. Specify who gets the role, how it is assigned and which actions are logged. Public registration and an external sign-in provider must never let a user choose an administrator role.
Specify state changes and their consequences
A listing can move from Draft to Pending review, then to Published or Rejected. Published listings can close or expire. Define what happens to an application already in progress when a listing closes: the sample requires a fresh server-side eligibility check at submission.
An application starts as Submitted and can become Withdrawn by its candidate. Employer review status is a separate field so “Reviewed” does not erase a later withdrawal. Decide how withdrawal affects employer access to the resume and contact details, and apply the same rule to downloads.
If paid listings are in scope, record verified payment events independently of listing status. A repeated webhook must not grant a second entitlement. A browser success redirect cannot be the authority that marks a payment settled. Define the relationship between payment, moderation, publication and refunds before implementing the checkout.
Require proof on both sides of each boundary
Use two employers, two candidates and one administrator in the test dataset. Create a job and an application for each employer. Prove an employer can read its own applicants before proving the other employer is denied. Repeat the test against guessed record IDs, exports and attachment URLs.
The PlanSmith job-board benchmark explains why this matters. Its four-build comparison focuses on security and isolation. Its caveats also state where everyday workflows were not tested end to end. Treat those results as evidence about the tested boundary, not a blanket endorsement of every workflow or a production certification.
Define a release receipt
For each requirement, record the route or API, actor, expected result, observed result and evidence location. Keep separate results for local tests, preview deployment and the live release. Add an owner for backups, email delivery, abuse handling and failed background jobs. A clean test run cannot replace a restore exercise or a check against the deployed URL.
Use the AI build walkthrough to turn this PRD into a sequence. For a compact agent instruction file, use the CLAUDE.md template. The job-board planner provides guided discovery when the sample's assumptions do not match your business.