How to build a job board with AI: from scope to a tested demo
Start an AI-assisted job board with a written workflow and a small test dataset. The useful first milestone is a candidate applying to a real listing and the correct employer reading that saved application. A homepage full of sample jobs is an earlier milestone, not completion.
Download the sample job board PRD (.md) and the worked CLAUDE.md example (.md). The steps below use on-site applications and free listings. Paid posting is an optional branch with its own checks.
1. Set the scope before the agent edits code
Choose one audience and a listing source. Decide whether applications stay on the board or redirect elsewhere, whether employers can self-register, and who approves publication. Write the answers into the PRD. Put exclusions beside them: for example, no resume marketplace, chat, AI matching or subscription billing in the first release.
Give your coding agent the repository's existing conventions and the completed contract. Ask it to identify conflicts and missing decisions, then propose an implementation sequence. Keep the stack already in use unless there is a specific reason to change it.
2. Build identity and ownership with a control dataset
Create two employer organisations, one employer user in each, two candidate users and an administrator. Use fictional data. Make every job carry its owning organisation ID and every application carry both the job ID and candidate ID.
The server must derive the signed-in identity from its session and scope access to the owning records. A hidden button is not an authorization rule. Test a direct API request for the other employer's job before moving on to the dashboard.
Done when: each employer can create and read its own draft, and the other employer cannot read or change it through either the UI or API.
3. Complete the listing lifecycle
Build draft creation, review submission, administrator approval, publication and closure as one workflow. A rejected draft must be editable and resubmittable under a stated rule. Closed and expired jobs must stop accepting new applications even if a candidate has an old page open.
Add search and filters over published records only. Test an empty result, a long job title, an invalid location and a mobile viewport. Establish the canonical public job URL and remove drafts from public listings and sitemaps.
Done when: an approved job appears in search, a draft does not, and closing the job changes both the public page and submission eligibility.
4. Add applications and prove privacy
Store the application before showing success. Decide whether duplicate submissions are rejected or update an existing application. Keep resumes behind an authorization check rather than a publicly accessible upload path.
Test Employer A reading Applicant One for Job A. Then request the exact same record and attachment as Employer B, Candidate Two and a signed-out visitor. They must be denied. Withdraw the application as its candidate and check the chosen withdrawal policy on every surface, including downloads and exports.
Done when: the owning employer sees the application, unrelated users do not, and a withdrawal changes access exactly as the contract says.
5. Add paid listings only if the scope includes them
Start with the payment provider's test mode. Separate the provider event, payment record, listing entitlement and moderation status. Verify event signatures and handle repeated events without duplicate entitlements. Define what happens when payment succeeds but publication is still pending, or when an approved refund arrives after publication.
Do not make payment completion depend on a browser returning to a success page. Close the tab before the redirect during a test and confirm that the verified server event still records the correct result.
Done when: success, failure, duplicate notification and refund scenarios reconcile to saved records. If this branch is excluded, keep checkout out of the UI.
6. Deploy a demo and record what was tested
Deploy the same revision you checked locally. Exercise the candidate and employer journeys using the deployed URL, including email links and attachment access. Check phone layouts, keyboard focus, useful error messages and persistence after a reload. Test a backup restore in a separate environment before relying on the data.
Keep a demo with fictional users out of search indexing while leaving its public case study searchable. A demo's test credentials and seeded records are not a model for production account creation.
Our job-board benchmark compares four builds and documents meaningful differences in employer isolation. The highest-scoring build's review still did not cover every daily workflow end to end. Read the caveats, then run your own release checks; a score is not a substitute for them. The demo gallery lets you inspect the interfaces alongside that evidence.
What to ask the agent after each step
Use a specific handoff: “Show the changed routes, the saved records behind the result, the allowed and denied access tests, and anything still untested.” Correct gaps before stacking another feature on top.
The requirements guide provides the role and lifecycle detail behind this sequence. If you need help deciding those rules for your own board, start with the job-board planner. Scope and test evidence determine the work; there is no reliable fixed-hour promise for every board.