How to Vibe Code a Job Board: A Step-by-Step Tutorial with Prompts

You can use AI to build a job board. The useful question is what you want that board to do when a real employer posts a job and a real candidate tries to apply.

This guide walks through a niche board called Climate Roles. We'll choose a design system and technology stack, build the core journeys in stages, and work through deployment, security, and running costs. Each stage includes a prompt and a check you can perform before moving on. We'll also cover the additional work behind resume parsing, AI job matching, and email alerts, and where Cavuno fits if you want those systems supplied together.

Think of the result as a small job board product: employers have accounts and private drafts, an operator decides what goes live, and candidates can find and apply to current vacancies. Building those connections teaches you what to look for in a job board platform as well as how to make one yourself.

How to use this guide: Build and test the core through the employer-review stage first. Deployment is a separate launch milestone. The later prompts describe optional extensions—payments, alerts, profiles, matching, and integrations—so you can understand the next decisions without implementing them all. Finish with the cost and Cavuno comparisons.

Validation status: We built a local reference with Codex and tested fresh Clerk signup and sign-in, employer company creation, draft submission, rejection, editing, resubmission, approval, public browsing, external Apply, and closure. Ten automated backend tests and separate real-token permission checks passed. This was a supervised build with repairs, not a one-shot run of unchanged prompts. OAuth, production deployment, real email delivery, and the optional integrations below have not been validated.

For a custom frontend backed by Cavuno, use the separate TanStack Start + shadcn/ui starter kit. That template uses Cavuno's SDK and backend, so follow its own setup instructions rather than mixing it with this tutorial's stack.

Before you start

You will build the first version on your own computer, then put it online later. That is what running locally means. You do not need to know these tools already; here is what each one does.

A terminal is a window where you type commands instead of clicking buttons. On a Mac, open Terminal; on Windows, open PowerShell. Your coding editor may also have a Terminal menu. In this guide, code blocks marked as shell commands go there; prompts written as instructions go into your AI coding tool's chat.

Create development projects in Convex and Clerk for this tutorial. “Development” means a test setup for fictional jobs and accounts. “Production” is the separate setup you will eventually use for real visitors. You can leave hosting and buying a domain until the deployment stage.

You will still need to follow setup screens and check the app yourself. When an instruction is unfamiliar, ask your coding tool to explain it before running it. The local core does not need a payment provider, resume service, geocoder, or separate email-alert service. Keep test and production credentials separate. The stack table below shows where charges can begin; buying every paid plan upfront is unnecessary.

Decide what your first job board needs to do

Start with a narrow promise: help people find current climate technology jobs and apply on the employer's website.

The first version needs six things:

1. A public list of current jobs.
2. A page for each job, with a working application link.
3. Search and filters for finding relevant roles.
4. An employer account for submitting and managing jobs.
5. An operator screen for reviewing submissions and closing listings.
6. A deployed website with a domain and HTTPS.

Candidates can browse and apply without an account. Native applications, resume uploads, matching, and payments come later. That gives you a useful first milestone without asking the AI to implement every feature at once.

Start by sending this brief to your agent. Keep its plan in the conversation for now; after creating the project folder, ask it to save the agreed brief and decisions as PROJECT-BRIEF.md:

1
We are building Climate Roles, a job board for climate technology jobs.
2

3
Visitors browse current jobs, search by keyword, filter by work arrangement,
4
location eligibility and employment type, and apply on the employer's site.
5
Employers sign in, create drafts, submit them for review, and manage their
6
own listings. The operator approves, rejects with feedback, and closes jobs. For v1, edits
7
are allowed only on drafts and rejected listings; close a published job and
8
create a replacement draft when its public content needs changing.
9

10
Only approved, unexpired jobs appear in public results. Closing a job must
11
also remove its active application action. Candidates do not need accounts
12
for the initial external-application flow.
13

14
First write a short implementation plan with routes, records, permissions,
15
and acceptance checks. Identify decisions that affect later features.
16
Do not implement payments, resume uploads, or AI matching yet.

Read the proposed plan before implementation. Ask the agent to explain unresolved decisions and confirm the first-version scope in plain English. The following prompts assume you have agreed that plan; they should extend it rather than silently replace it.

Choose a niche you understand. The example is replaceable; the workflow is not. If you still need to decide who your board serves, use our broader guide to creating a job board.

Choose your AI building tool

Choose how you want to work before buying infrastructure.

Lovable documents a full-stack workflow including backend, authentication, hosting, and Git sync. Replit supports building and publishing apps. Give those bundled capabilities credit when comparing costs. A hosted builder does not necessarily need a separate hosting subscription and a separately purchased database.

Cursor is a candidate when you want to work directly with your repository. For this walkthrough, use that repository-based approach and one consistent stack. You can adapt the product prompts to a hosted builder, but its setup screens and implementation choices will differ. Ask it to explain its supported stack before specifying services.

Bolt and v0 are also worth investigating if you already use them. Avoid switching tools whenever you hit an error: preserving context and learning to describe a failure will usually help more than restarting the project.

Pick a technology stack and a design system

For the reference approach, use:

Prices and allowances checked September 7, 2026. They exclude tax, domain registration, your AI coding tool, and additional usage. Authentication emails in the core are handled by Clerk; Resend is for the later app-email extension. The free software rows cover the selected open-source packages, not paid Tailwind or design-system products.

A lean starting budget: $0 in incremental hosting/backend/authentication subscriptions for local development within free allowances. For a small commercial launch on this Vercel-based stack, budget $20/month while Convex and Clerk remain within their applicable free limits. Adding Convex Professional makes that $45/month for one developer; adding Resend Pro makes it $65/month, assuming Clerk stays free. These are separate scenarios, not required upgrades, and exclude the additional costs above. Vercel's Hobby rules matter when turning a personal prototype into a commercial board.

Watch usage as well as account counts. Convex meters backend resources, Clerk measures retained users rather than job board visits, hosting meters requests and compute, and email has daily as well as monthly limits. For example, 1,000 subscribers receiving a daily digest could require about 30,000 emails in a 30-day month, before confirmations or other messages. Subscriber capacity and email-send capacity are different things.

This is a coherent choice for the tutorial, not a requirement for every board. If you know another stack, familiarity may matter more than a small difference in subscription price.

Choose components before designing every page

shadcn/ui gives you editable component code, making it a useful foundation when working with an AI coding tool. Untitled UI is an alternative with React components, application examples, and design resources. Check that the assets you choose are included in your license; a Figma kit and a React implementation are different deliverables.

Choose one system. Define your type sizes, colors, spacing, borders, and content width once, then reuse them. Your job cards, forms, filters, and dashboards should look like parts of the same product.

Choose the visual direction now. Implement the component prompt below after the project and shadcn/ui are installed.

Follow one stage at a time

Keep using the same project as you build. Give the agent one stage's prompt, let it finish, then use the check before moving on. Ask it to keep PROJECT-BRIEF.md current and maintain BUILD-LOG.md with completed stages, tested results, unresolved failures, and the next step. If you start a new conversation or the agent loses track, have it read both files and inspect the existing project before changing anything.

If a check fails, stop at that stage. Send the agent the page address, what you clicked, what you expected, and what happened. Let it investigate and rerun the check. An agent saying “done” is not the checkpoint—the working experience is.

Set up the project and save a working checkpoint

Let your coding agent handle the setup

If your coding tool can edit files and run terminal commands, give it the setup work. It can check installed software, create the project, install packages, start the website, and investigate errors. The manual instructions below explain what it is doing and give you a fallback when a tool cannot perform a step.

Open your coding agent in a folder where you want to keep the project, then send:

1
Set up the Climate Roles tutorial project on this computer. First check the
2
operating system, Node.js, npm, Git, and the current folder. Explain anything
3
missing in plain English and help install a compatible version without
4
replacing an existing project or changing unrelated settings.
5

6
Use the tutorial's tested Next.js 16.3.4 scaffold with TypeScript, Tailwind,
7
App Router, npm, and ESLint in a new climate-roles folder. Save our agreed
8
brief as PROJECT-BRIEF.md. Install convex@1.45.0 and @clerk/nextjs@7.9.1.
9
Initialize shadcn@4.21.0 with defaults and add button, card, badge, input,
10
label, textarea, select, and table. Read installed-version documentation.
11
Run the development server, check the starter page, and give me its local URL.
12

13
Do the commands and file edits you can perform yourself. For account login,
14
credentials, or a step requiring me, give me the exact link and a short action,
15
then continue once it is complete. Keep secrets out of chat and Git. Report
16
what you actually verified and which services still need configuration.

Capabilities vary: an agent with terminal access can usually do much more than a chat-only assistant. You may still need to sign into accounts, complete verification, authorize an installation, or select billing. You remain responsible for checking the finished experience, but you do not need to type every command yourself.

Manual fallback: install the tools and check they work

If your agent has already completed a step, check its result and skip that step here. Otherwise, install Node.js and Git using the links above, then open a new terminal window. Run each command separately by pasting it and pressing Enter:

1
node --version

1
npm --version

1
git --version

Each should print a version number. If you see “command not found” or “not recognized,” the tool is not available in that terminal yet. Finish installing it and reopen the terminal before continuing. Our tested setup used Node.js 22.23.2; choose that version on the download page to match the reference. Later versions may require different setup steps.

Manual fallback: create the website on your computer

Choose a folder where you keep projects and open a terminal there. In an editor such as Cursor, open that folder and use its terminal. Then run:

1
npx create-next-app@16.3.4 climate-roles --ts --tailwind --eslint --app --use-npm --yes

This downloads the Next.js setup tool and creates a new folder called climate-roles containing your starter website. If npm asks to install the setup package, confirm the package name and continue. Wait until setup finishes and you can type another command.

The options already choose TypeScript (JavaScript with extra checks), Tailwind CSS (styling), App Router (how Next.js organizes pages), and ESLint (a code checker). You do not need to choose those settings yourself.

Next, move the terminal into your new project folder:

1
cd climate-roles

cd means “change directory.” Commands from now on run inside this project. Open the same climate-roles folder in your coding editor so the AI can work on its files.

Start the website:

1
npm run dev

The terminal prints a local address, usually http://localhost:3000. Open the address it actually shows in your browser. You should see the Next.js starter page. “Localhost” means your own computer; this is not yet a public website. Leave this terminal running while you use the app. Press Ctrl+C when you want to stop it.

Check: Do not add accounts or job features until that starter page loads. If it fails, copy the error message into your coding tool and ask it to fix the setup before continuing.

Our local run used Node.js 22.23.2, Next.js 16.3.4, React 19.2.8, Convex 1.45.0, and Clerk Next.js 7.9.1. These are the versions we tested, not a promise that they will always be the best versions to install. Review updates before launching. Keep package-lock.json, the generated file recording installed package versions, so subsequent installations can reproduce them. Ask your coding tool to read the project's framework instructions and installed-version documentation. Framework APIs change; an example remembered by a model can be out of date.

Connect the database and sign-in service

Ask your agent to do this connection work first. If it already installed the dependencies, do not repeat their installation. For the manual fallback, keep the website terminal running and open a second terminal in the same climate-roles folder. Run the following commands one line at a time. The first installs the Convex and Clerk libraries; the next two install the shared interface components; the last connects your backend and keeps it running:

1
npm install convex@1.45.0 @clerk/nextjs@7.9.1
2
npx shadcn@4.21.0 init --defaults --yes
3
npx shadcn@4.21.0 add button card badge input label textarea select table --yes
4
npx convex dev

Follow the Convex login prompts, sign in to your Convex account, and create a new development project for Climate Roles. In another browser tab, open the Clerk dashboard and create a development application for Climate Roles. Use the current Convex and Clerk integration guide and Clerk Next.js quickstart to connect identity to the backend. The commands above install shadcn/ui before any prompt refers to its components. Our run selected its Base UI foundation; do not assume older Radix component APIs apply.

An environment variable is a named setting, such as the address of your database. Some settings are secret keys. The file .env.local stores settings for the website on your computer; it belongs in the project folder and must not be committed to Git. Your AI can create the file structure and explain where to copy each value without asking you to paste secrets into chat.

The setup has two places for configuration:

The following checklist is for you and your coding tool together. You handle account setup and copying credentials in the dashboards; ask the AI to make the code changes using the connection prompt below. Authentication simply means proving who has signed in.

The issuer is the Clerk service that vouches for a signed-in user. Providers are code components that make sign-in and database access available to the rest of the website. Your agent handles those code details.

Connect authentication in this order:

1. Create a Clerk development application and enable the sign-in methods you intend to test.
2. Copy its publishable and secret keys into .env.local as NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY. Keep that file ignored by Git.
3. Activate the Convex integration in Clerk. Copy the Clerk Frontend API URL; this is the token issuer, not your Next.js website URL.
4. Configure that issuer in convex/auth.config.ts with applicationID: "convex". If you use process.env.CLERK_JWT_ISSUER_DOMAIN, set it in the Convex development environment. A value in Next.js's .env.local alone does not configure the deployed backend.
5. Wrap the application with ClerkProvider and ConvexProviderWithClerk, passing Clerk's useAuth hook to the latter. Use Convex's authenticated state before calling protected queries.
6. Add /sign-in and /sign-up routes. For this Next.js version, configure Clerk middleware in proxy.ts, following the current quickstart's matcher.
7. Restart the local website after adding keys. Sign in and call the authenticated backend check below.

For an isolated local experiment, we used CONVEX_AGENT_MODE=anonymous npx convex dev and a fresh accountless Clerk development app created with npx clerk@latest init --accountless --no-skills --yes. That avoids reusing an existing application's data. It is a local test route, not a production deployment. Clerk still needs its Convex token configuration. Use the cloud setup above for a hosted board.

Public connection identifiers are different from secret keys. Keep secrets out of browser code, screenshots, and version control. When email is added, place its API key in the environment where the sending code runs.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Connect the existing Next.js app to Convex and Clerk using their current
5
Next.js integration documentation. Inspect the installed versions first.
6
Use https://docs.convex.dev/auth/clerk and
7
https://clerk.com/docs/nextjs/getting-started/quickstart for setup.
8
Configure the providers, sign-in routes, and backend identity verification.
9
Ensure the Clerk token issuer and Convex audience agree. Put backend
10
environment settings in Convex, not only the website .env.local file.
11
Use one localhost origin consistently; do not mix it with 127.0.0.1.
12
Verify backend function deployment is ready before testing UI calls.
13

14
Tell me exactly which dashboard settings and environment variable names I
15
must configure, and where. Never ask me to paste secret values into chat.
16
Add a development-only identity-check page with a backend query that requires
17
sign-in. Show a simple "Backend recognizes your account" result while signed
18
in and "Sign in to check" while signed out. Keep raw tokens and secrets out
19
of the page. Give me its exact URL and steps to test it. Do not treat a
20
signed-in browser UI as proof of backend authentication.

Check: Open the identity-check URL your agent provides, sign in, and see “Backend recognizes your account.” Sign out and confirm it changes to “Sign in to check.” Ask the agent to verify separately that the backend rejects a signed-out request. Then ask it to save a Git checkpoint—a named snapshot of the working code—without including secret files.

Save a checkpoint you can return to

At each working stage, ask the agent:

1
Save a Git checkpoint of the current working stage. Check that this folder
2
is a Git repository; initialize it if needed. Confirm .env.local and other
3
credential/session files are ignored. Review the diff and stage only intended
4
project files. Commit with a message describing the working stage, then show
5
me the commit ID and a short summary without secret values. Do not push or
6
publish anything as part of this checkpoint.

Check: The agent should give you a commit ID—the identifier of the saved snapshot—and confirm what it includes. A folder existing on disk is not the same as a Git checkpoint. If Git needs your name/email configured, have the agent explain that step and choose the identity you want attached to commits.

Build the shared components

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Create Climate Roles' design foundation using the installed shadcn/ui
5
components. Read their current documentation before using their APIs.
6

7
Use a warm neutral background, dark readable text, and a forest-green accent.
8
Create shared typography, spacing, color, and border tokens.
9
Build JobCard, FilterBar, JobDetail, JobSubmissionForm, and StatusBadge.
10
Put them on a temporary development preview page using fictional data and
11
give me its URL. They are visual components at this stage; connect their
12
real data and actions in the following stages.
13

14
Show company, title, location eligibility, work arrangement, employment type,
15
and salary with currency and period. Include loading, empty, error, long-title,
16
mobile, and keyboard-focus states. Label fixture jobs as fictional demos.
17
Do not add another component library or pretend demo buttons are functional.

Check: Open the component-preview URL the agent provides. Resize the page to a phone width. Tab through its controls. Try a long job title and a missing salary. Make sure the application button and form labels remain clear.

Create the job records and public pages

A record is one saved item, such as a job or company. A field is one fact about it, such as its title. Define these before the agent builds search so filtering has reliable data to use.

“Remote” describes a work arrangement. “Must be based in Australia” describes eligibility. Store them separately. A salary of 100,000 is incomplete without currency and a pay period.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Implement the job board records and public pages from our approved brief.
5
Use this minimal Convex data model (Convex supplies _id and _creationTime):
6

7
companies
8
- name: string
9
- owner: verified issuer-qualified identity string
10
- index by_owner; enforce one company per owner in the creation mutation
11

12
operators
13
- identity: verified issuer-qualified identity string
14
- index by_identity; writable only through trusted internal bootstrap
15

16
jobs
17
- companyId: reference to companies
18
- companyName: server-derived company name for display/search
19
- owner: server-derived verified identity, matching the company's owner
20
- title, description, slug, applyUrl, location: strings
21
- type: Full-time | Part-time | Contract
22
- arrangement: Remote | Hybrid | On-site
23
- salaryMin, salaryMax: number or null (annual USD)
24
- status: draft | pending | published | rejected | closed
25
- reason: optional string for rejection feedback
26
- publishedAt, expiresAt: optional timestamps in milliseconds
27
- searchText: server-derived searchable text, refreshed when content changes
28
- indexes by_owner, by_status, by_slug
29
- full-text search on searchText, filterable by status/type/arrangement/location
30

31
Do not create password or session tables: Clerk handles sign-in. Never trust
32
owner, companyName, searchText, or privileged status changes from a form.
33
Validate company ownership on the backend, enforce unique slugs, and make
34
company creation atomic so concurrent requests cannot create two companies.
35
Treat indexes as lookup tools, not automatic uniqueness constraints.
36
Use application validation as well as field types. Explain any necessary
37
schema deviation before changing the agreed model.
38
Use validated fields and indexes appropriate to the actual queries.
39
Define job status as draft, pending, published, rejected, or closed. Only
40
published jobs can be public; draft and pending jobs may have no expiry yet.
41
For this first version use Full-time/Part-time/Contract employment types and
42
Remote/Hybrid/On-site work arrangements. Use a small fixed list of eligible
43
locations, including Australia and Worldwide, with one location per job.
44
Keep optional salary amounts annual and in USD, clearly labelled; leave
45
missing amounts empty. Multi-currency and multiple offices are later work.
46

47
Add /jobs and /jobs/[slug]. Use a stable unique slug (the readable identifier at the end of a job URL). Public reads may return
48
only published jobs whose expiry is in the future. Enforce that on the backend.
49
Render job descriptions safely, validate application URLs as HTTP/HTTPS,
50
and represent missing salary values explicitly rather than as zero.
51

52
Add a development-only seed process with 12 clearly fictional published,
53
unexpired jobs spanning different filters, with example.com application
54
URLs. Make it safe to rerun without duplicates, run it in the development
55
project, and report the number of records created. Do not expose a public seed or operator-creation endpoint.
56
Ensure records persist in the database, not only in memory or localStorage.

Check: Open a job's URL directly, refresh it, and open it in a private window. The same public record should appear. The agent should test private-draft and expired-job visibility with backend fixtures now; you will exercise their management screens after the employer stage is built. Expired fixtures must not offer an active Apply action.

Add search, filters, and application links

Start with keyword search and structured filters. You do not need a separate vector database to make the first version useful.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add keyword search, employment-type, work-arrangement, and location-eligibility
5
filters to /jobs. Combine selected filters consistently. Store the search
6
state in the URL so copying the link reproduces the result.
7
Keep pagination cursors compatible across requests as server time advances.
8
For the Convex reference approach, paginate a stable query before filtering
9
overdue records on the backend. A visible page can be empty or shorter than
10
requested and still have more records; keep Load more available when the
11
continuation cursor says so. Test time advancing between page requests.
12

13
Paginate results, reset pagination when filters change, and provide a clear
14
all-filters action. Show separate loading, no-results, and failed-request
15
states. Keep public visibility rules on the backend. Expiry checks must use trusted
16
server time, not a timestamp supplied by the browser. Scheduled closure is
17
useful cleanup, but public reads must also reject overdue jobs if it runs late.
18

19
Route Apply through a server endpoint that checks the job is still public
20
at click time before redirecting to its validated HTTP/HTTPS destination.
21
Prevent caching of that visibility decision and redirect response.
22
If closed or expired, show an unavailable result without redirecting. Test
23
a job page left open while the operator closes that job. Record the click
24
later as an apply click, never as a completed external application.

Check: Combine two filters, copy the URL, and open it in another browser. Try an impossible combination and clear it. Confirm every result is current and every application link goes to the intended employer page.

When keyword search misses useful roles, collect examples before adding semantic search. “Battery engineer” and “energy storage engineer” might be a good test pair. Convex includes vector search; Qdrant is an optional dedicated service. Choose based on the search you need rather than adding another bill automatically.

The actual local reference: keyword and location filters working together. Listings are fictional.

Let employers submit jobs and operators review them

Build the management screens while the application is still small. You will need them to correct a salary, reject spam, close a role, or help an employer who made a mistake.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Implement /employer/jobs, a new-job form, and /admin/jobs.
5
A signed-in employer first creates one company. Derive its owner from the
6
verified backend identity and make repeated company creation idempotent.
7
An employer can create/edit their own draft and submit it for review.
8

9
Use exactly these status values: draft, pending, published, rejected, closed.
10
Submitting a draft makes it pending. Only an operator can change pending to
11
published (approve) or rejected (with a reason). Set publishedAt on approval
12
and expiresAt to 30 days later; schedule closure and enforce expiry on reads.
13
Owners and operators may close any non-closed job, including withdrawing a
14
pending submission. Repeated closure is a no-op; closed jobs cannot reopen.
15
Editing a
16
rejected job returns it to draft and clears the old review reason. Repeated
17
submission of a pending job is a no-op. Owners may close their own jobs.
18
Operators approve or reject pending jobs, with a required rejection reason.
19
No in-place editing of published listings in v1: close and replace them with
20
a fresh draft that needs approval. Do not silently mutate approved content.
21

22
Check ownership and operator permissions on every backend read and write.
23
Derive identity from authentication, not an owner ID or role in the request.
24
Bootstrap the first operator through a documented trusted setup procedure.
25
Ordinary users must never be able to grant themselves that role.
26

27
Validate fields on the server and preserve form values after errors.
28
Validate finite, nonnegative salary amounts and minimum <= maximum when
29
both exist. Reject application URLs with embedded username/password values.
30
Give submit buttons explicit type="submit" and Cancel buttons type="button".
31
Show readable application errors; do not dump backend traces into the form.
32
Verify the form actually submits and persists a record in the real browser.
33
Make repeated submission safe. Show pending, rejected, active, and closed
34
states clearly to the employer.

Check: After the operator setup below, use three separate development identities: Employer A, Employer B, and the operator. Submit as A, approve as the operator, and view the public listing. B must not see A's private drafts or edit A's jobs. Ask the agent to test direct backend requests with B's identity too; hiding a button is insufficient. Use separate browser profiles or sign out before switching accounts so you know which identity is active.

The employer sees its own listing state. A closed job no longer offers edit or submission actions in this reference.

Bootstrap and test the operator deliberately

The operator is the person running the board and reviewing submissions. Use a dedicated development account for that role; do not promote Employer A or B.

Keep operator assignment in an internal Convex function, such as jobs:bootstrapOperator, with no public button or mutation that grants roles. Ask your agent to retrieve the operator's exact verified identity through its authenticated backend check or trusted development tools, rather than asking you to invent an identifier. Ask your agent to run the internal setup only after you identify the intended operator account and development project. If doing it yourself, the command is:

1
npx convex run jobs:bootstrapOperator '{"identity":"REPLACE_WITH_VERIFIED_TOKEN_IDENTIFIER"}'

This command assumes your implementation uses that function name and argument. Inspect its code before running it, and select the intended development deployment. Do not guess an email address or copy a user-controlled form value into an operator record. The reference implementation stores the issuer-qualified token identifier.

Use two separate development users to test ownership. Clerk documents reserved test email addresses and verification codes, so you can test email-code sign-in without sending real emails. This does not test real email delivery or OAuth.

The actual review screen: a submission stays pending until the operator approves or rejects it. This screenshot uses a fictional fixture, not customer data.

Fix what the browser exposes

Our first pass produced a form that looked complete but did nothing: its component button defaulted to type="button". Explicit type="submit" fixed the form. A fresh reload was needed to verify the updated DOM in our run. We also replaced raw backend error details with a readable salary-validation message.

A later regression check exposed a subtler problem: including a changing expiry timestamp in the database's pagination filter invalidated its next-page cursor. The reference now paginates the stable query, then removes overdue records on the backend before returning that page. A page can consequently contain fewer visible jobs; the UI must still allow continuation when the cursor says more records remain. A test advances time between page requests to catch this regression.

The application link also goes through a server route that rechecks whether the job is still public before redirecting. This matters when someone leaves a job page open while an operator closes the vacancy.

Use a repair prompt that names the evidence:

1
The company form displays, but clicking Create company does not submit it.
2
Inspect the rendered button type, form association, validation state, and
3
submit handler. Reproduce the failure before changing code. Fix the cause,
4
then verify in the browser that a company is persisted and the job-creation
5
screen appears. A compile or unit-test pass alone is not enough.

For automated backend checks in this reference stack, our run used Vitest 5, convex-test, and an edge runtime. The starter's Node 20 type definitions conflicted with the current test runner; matching them to our Node 22 runtime resolved the install. Avoid --force as a substitute for resolving the dependency mismatch.

1
npm install -D vitest@5 convex-test @edge-runtime/vm @types/node@22
2
npx vitest run
3
npx tsc --noEmit
4
npm run lint

These commands only verify tests your project actually contains. Require tests for another employer's read/write attempts, ordinary-user moderation attempts, repeated submission, rejected-job editing, unsafe URLs, reversed salary ranges, and expired public reads. Use fake timers and advance the test clock through expiry before running scheduled work; a test that directly calls the cleanup function does not prove the scheduler ran correctly. Add a separate test showing public reads exclude an overdue job before cleanup runs.

Check the complete core journey

At this point, you should have a small working job board system. Test it as three different people: a candidate browsing publicly, an employer managing their company, and an operator reviewing submissions. Keep a second ordinary employer account for the access checks.

The location example also connects Australia → New South Wales → Sydney and carries a regional browse page into filtered search. It demonstrates how data and navigation connect; it uses a small curated registry rather than worldwide address lookup.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md and inspect the current implementation.
2
Validate in the real browser with fictional data and separate accounts:
3
signup/sign-in/sign-out; employer company creation; draft/edit/submit;
4
operator rejection; employer correction/resubmission; approval/public detail;
5
search/filter/reload/pagination/empty states; external Apply; closure; and
6
ordinary-user denial at the operator screen. Check cross-account access
7
with real authenticated backend requests as well. Record the
8
route, action, expected result, and observed result for each. Fix failures
9
and rerun affected journeys, including backend permission checks.
10

11
Keep a working checkpoint and update the setup instructions with every repair
12
needed to reproduce it. Report untested paths explicitly. Do not count a
13
mocked identity test as a real sign-in, an apply click as a completed external
14
application, or a local run as a production deployment.

Our reference took follow-up repairs to reach this checkpoint. The prompts supplied useful direction, but they did not remove the need to inspect generated code and use the app. Google OAuth, real email delivery, and hosted deployment remain untested. A direct saved Apply URL after closure was also blocked by our browser tooling, so we do not count that browser path as verified; the closed-detail and backend visibility checks passed separately.

Decide what you want to build next

Once those checks pass, you have the core of a useful board. You have also seen the work behind accounts, private drafts, review decisions, search, and expiry. Before adding features, decide whether maintaining those systems is part of the project you want to own.

The work you have done gives you a better specification whichever route you choose. Moving to Cavuno does not automatically import this prototype's code or database; carry over your requirements, design preferences, and any data through the supported import paths.

If you continue independently, you can stop feature development here and prepare a launch. The later sections explain the additional workflows so you can choose what your niche actually needs.

Deploy your first working version

This stage puts your website on the internet. A repository is your saved code project; a service such as GitHub can hold a private copy online. Ask your agent to prepare that repository and walk you through connecting it to Vercel. You handle sign-in and any paid-plan choices. Create production instances for the backend and authentication service, configure the corresponding production values, and follow the providers' current deployment instructions. A development database should not quietly become your production database.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Prepare this app for a production deployment on Vercel with Convex and Clerk.
5
Read the providers' current deployment documentation and our installed-version
6
instructions. List the exact dashboard actions I must perform.
7

8
Separate development and production environment values. Verify production
9
authentication settings, backend deployment, custom-domain configuration,
10
and the process for removing demo records. Remove or disable development
11
identity/component-preview pages, seed tools, and test-operator setup UI.
12
Keep fictional pages noindex during testing. Add a documented rollback path.
13
Deploy first to a restricted preview or staging environment so browser
14
checks can run. Explain any production-domain checks that require a final
15
deployment. Keep public launch and search indexing disabled until the
16
applicable deployment checks pass and I approve opening the board.

Connect your domain using the DNS records supplied by the host. Check HTTPS, sign-in, and public job URLs on that domain.

Public job pages also need accurate titles, canonical URLs, sitemaps, and job structured data. Put JobPosting markup on individual eligible job pages and keep it consistent with visible content. Follow Google's job-posting requirements, including handling expired roles. Valid markup makes a job eligible for the feature; it does not guarantee inclusion or rankings.

For the wider launch plan, use our job board SEO guide to connect technical setup with keyword research and useful content.

Launch check: In a fresh browser, browse → filter → open job → apply. Then sign in as an employer → submit → approve as operator → find the published job. Replace fictional listings with real jobs you are entitled to publish. Recheck the application destinations.

Checkpoint: Only call this a launched board after completing the deployment and browser checks above. Our reference run validates the local core, not hosted production. The following sections are extension specifications; their integrations have not been built or tested in this reference run.

Decide whether you are ready for real users

Completing the local tutorial is one milestone. Before inviting employers or collecting candidate data, record evidence for each launch condition:

• The production domain has HTTPS, and signup, sign-in, sign-out, and account recovery work with production configuration.
• An employer can submit, receive a review outcome, correct a rejection, and find the approved job publicly; another employer cannot access private records.
• Search, mobile navigation, and application links work on the deployed site; closed and expired jobs lose their active application path.
• Fictional fixtures are removed, real listings are authorized and accurate, and indexing settings, canonical URLs, sitemaps, and job markup match real inventory.
• Someone receives operational errors, knows how to roll back, and has demonstrated a restore in an isolated environment.
• If you add payments, alerts, or resumes, their own payment-failure, unsubscribe, delivery, private-access, and deletion checks have passed first.

Keep unfinished items visible and limit access accordingly. Our local test build has not passed this production launch gate.

Add paid job postings

Use our job board monetization guide to choose an offer that fits your stage. Decide what an employer buys before connecting payments. For example: one reviewed listing, active for 30 days after publication. Explain what happens if a paid submission is rejected.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add one paid posting product using hosted checkout and the payment provider's
5
current documentation. Start in test mode. Keep payment state separate from
6
moderation state. Publication requires both approval and verified payment.
7

8
Create the checkout session on the server with a server-controlled price.
9
Bind it to the authenticated employer, intended listing, and product in a
10
server-side purchase record; verify that association during fulfilment.
11
Verify webhook signatures and payment status. Fulfil each purchase once even
12
if an event is retried. Visiting a success URL must never grant publication.
13
Document cancellation, rejected submissions, and refund handling.

Check: Test a successful purchase, cancellation, and duplicate delivery of the same event. Confirm the posting is granted once and a cancelled checkout grants nothing. Use the payment provider's test tools before switching to live mode.

Add job alerts people can unsubscribe from

A job alert has several parts: a saved preference, a confirmed email address, a schedule, matching jobs, delivery, and an unsubscribe route. Our email marketing guide for job boards explains how alerts fit alongside newsletters and employer communication.

Set up a sender domain in Resend, add its requested DNS records, and confirm verification. Sending successfully through an API does not prove delivery to an inbox.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add a daily job-alert subscription using our existing search filters and Resend.
5
Confirm ownership of the email address before activating the subscription.
6
Include a working unsubscribe link and suppress unsubscribed or bounced
7
addresses. Protect sign-up and confirmation requests against abuse.
8

9
Send only newly eligible jobs since the last successful digest. Track delivery
10
state and use the provider's supported idempotency behavior so a retry does
11
not casually send the same digest twice. Do not send an empty digest.
12
Keep secrets and recipient lists on the backend.

Check: Subscribe with an address you control, confirm it, publish a matching job, and trigger a test digest. Check the actual inbox and links. Unsubscribe and confirm the next run excludes you. Handle failures without incorrectly advancing the successful-delivery checkpoint.

Turn resumes into editable candidate profiles

Resume parsing can save candidates from retyping work experience. It also introduces private files, extraction failures, model usage, and information that needs correction.

Begin with a clearly documented set of supported files. A text PDF, an image-only scan, and a DOCX need different handling. Tell candidates what you support rather than accepting files you cannot process.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add a candidate account with private resume upload and an editable profile.
5
Use synthetic resumes for development. Set a file-size limit and supported
6
types, enforce ownership on upload/download/delete, and keep file contents
7
out of logs and analytics.
8
Validate actual file content rather than trusting its extension. Quarantine
9
uploads until the configured scanning checks pass, and serve originals as
10
authorized attachments with safe headers rather than inline active content.
11

12
Extract text with tools appropriate to the file type. Use a model to produce
13
validated structured fields for experience, education, and skills. Treat the
14
document as untrusted data; ignore instructions embedded inside it.
15
Leave missing information unknown. Never invent credentials or experience.
16

17
Show extracted values for correction before saving the profile. Provide
18
clear unsupported-file, failed-parse, and retry states. Document deletion
19
of the source file and derived data, including any backup retention.

Check: Try a clean sample, missing dates, unusual formatting, and an unsupported scan. Correct a parsed value and reload the profile. Use a second account to verify the resume and private profile are inaccessible.

The recurring cost includes storage and extraction/model usage. The development work includes the review screen, permissions, failure handling, and deletion behavior.

Match candidates with relevant jobs

Search answers a query. Personalized matching uses the candidate's profile and preferences to suggest jobs. Those are different experiences.

Start with explicit constraints such as location eligibility and employment type, then rank eligible jobs by relevant experience and skills. Do not let a similar-sounding title override a candidate's stated location requirements.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add /matches for signed-in candidates using their saved profile and explicit
5
preferences. Filter out closed and expired jobs and enforce eligibility
6
constraints before ranking. Provide a useful empty state for thin profiles
7
and for no eligible matches.
8

9
Propose a simple baseline and an optional embedding-based approach. Reuse our
10
existing search infrastructure where suitable. Explain model usage and how
11
results update when a job or profile changes. Do not present an arbitrary
12
similarity value as a validated probability of being hired.
13

14
Create a small synthetic evaluation set of candidates and jobs with manually
15
expected relevant and irrelevant examples. Report failures, not just scores.

Check: Give one candidate a strict location preference and include an otherwise similar but ineligible job. Confirm it is excluded. Close a recommended job and check that it disappears. Compare the results with your own judgment before assuming the system is useful.

Emailing personalized matches is another opt-in workflow. Keep it distinct from a saved-search alert. These recommendations help candidates explore roles; they should not silently become automated rejection decisions for employers.

Add analytics and a source of fresh jobs

Track the events that tell you whether the board is useful: job views, searches, apply clicks, employer submissions, and completed purchases. Define them before building dashboards.

An external apply click tells you someone left for the employer's application page. It does not tell you whether they finished applying. Avoid collecting resume text or private profile fields in analytics events.

Tinybird is one option for building analytical queries and reports. You may initially need a smaller setup. An employer report showing views and apply clicks still requires event collection and an interface, whichever database stores the events.

Start sourcing jobs through manual entry or CSV import. Add permitted recurring feeds when manual maintenance becomes a burden. Imports need stable source identifiers, duplicate handling, validation, and a policy for closing jobs that disappear. A feed that runs successfully can still fill your board with stale listings.

For a deeper sourcing plan, see our job board aggregator guide.

Connect the board to your other tools

A useful board also fits into your workflow: a published job can start a social-posting workflow, a CRM record can become a draft vacancy, and a withdrawn marketing permission can update your email tool. Choose one concrete workflow before asking an AI to “add integrations.”

For a custom board, that usually means an authenticated API and outbound webhooks. You own permission checks, event definitions, signing, retries, duplicate delivery, logs, and credential revocation. Zapier and n8n can orchestrate the steps, but they still need a reliable way to read and change your board.

This is an optional extension specification; it has not been implemented or tested in our local test build.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Add one integration journey: when an operator first publishes a job, emit a
5
job.published event to an operator-configured webhook. First propose the event
6
schema, authentication, signing, retry policy, and delivery-log interface.
7

8
Use a durable event ID and a stable job ID. Ordinary edits to an already
9
published job must not emit another first-publication event. Persist the event
10
with the publication change so a process failure cannot silently lose it.
11

12
Use a local fake receiver for tests. Verify the raw-body signature before any
13
receiver action. Test duplicate delivery, a timeout, a temporary 500 response,
14
an invalid signature, and recovery. Show that retries do not duplicate the
15
receiver's business action. Restrict production destinations against SSRF;
16
keep any loopback exception confined to the isolated test environment.
17

18
Do not include candidate data or credentials in the event. Do not send live
19
messages while testing. Report what was actually exercised.

Check: Publish a fictional job, observe its delivery record, simulate a receiver failure, and confirm eventual delivery produces one downstream action. Revoking the integration must stop future authorized access. A successful HTTP request alone does not prove this journey works.

Keep the board secure and operating

Security starts with permissions and data handling during the build. Operating the board means preserving those protections as you change it.

Configure traffic protection without overlooking the app

Cloudflare provides DDoS protection and related traffic-security products. Check what your hosting provider already supplies before adding another service. DNS, proxying, firewall rules, and application controls have different jobs.

Map which requests pass through your configured protection. A protected website domain does not automatically cover every directly reachable backend endpoint. Add limits to expensive or abusable actions such as resume parsing, matching, uploads, subscriptions, and signups.

Maintain a practical operating checklist

Test request limits with a small, controlled set of requests to your own test environment. You do not need to simulate a DDoS attack.

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Review the app's security boundaries and operating procedures. Identify the
5
public endpoints, private data, privileged actions, and expensive operations.
6
For each important control, show a concrete test and its observed result.
7

8
Prioritize cross-account access, resume downloads, operator permissions,
9
payment event verification, secrets in browser output, and request limits.
10
Create a short recovery procedure for an exposed key and a failed deployment.
11
Distinguish provider-managed controls from controls our application owns.
12
Do not report the app as secure merely because a scanner or build passed.

At this point, compare the recurring work with the time you want to spend on the business. If you would rather focus on attracting employers and helping candidates, Cavuno's plans are worth evaluating against this checklist. If you enjoy owning the software, keep these checks with your project and rerun the affected journeys as it changes.

Know what to do when the AI breaks something

Save a working checkpoint after each stage. When something fails, describe the route, account, action, expected result, and actual result. Include the error message with sensitive data removed.

1
After the last change, [account type] can no longer [action] on [route].
2
Expected: [behavior]. Actual: [behavior]. Reproduction steps: [steps].
3

4
Inspect the recent diff and reproduce the issue. Explain the cause before
5
changing code. Make the smallest justified fix, preserve existing behavior,
6
and rerun this journey plus the directly affected permission checks.
7
Do not replace the stack or remove validation to make the error disappear.

A small employer request becomes a maintenance decision

An employer writes: “The salary on our published job is wrong. Can you change it?” In this reference, approved jobs cannot be edited in place. The supported path is to close the listing and submit a corrected replacement for review. That is a deliberate first-version limitation, but it also means a new URL and another review cycle.

If your niche needs edits without that disruption, specify a revision workflow before changing the form:

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Design a change request for a published listing. Keep the currently approved
5
version public while an employer submits a proposed revision for review.
6
Store who requested and reviewed it. Rejection keeps the approved version;
7
approval updates the same public job URL. Closing the job must take precedence
8
over a pending revision. Explain salary, search, expiry, and alert behavior.
9

10
First show the state transitions and acceptance checks. Then implement in a
11
separate checkpoint. Test another employer's access, rejected revisions,
12
closure during review, and repeated approval without duplicate side effects.

This extension has not been built in the reference. It illustrates why maintenance includes product decisions, permissions, data changes, and regression checks. When evaluating Cavuno or another platform, try its supported editing workflow against the same employer request.

Compare the costs fairly

Separate building costs, running costs, and your time. A coding subscription used across several projects is different from API usage generated every time someone uploads a resume.

Here are illustrative vendor prices checked on September 7, 2026, in USD. They are not a minimum required stack or a measured bill for this tutorial.

Budget for the coding agent you choose

These are alternative building tools, not subscriptions you need to buy together. Prices checked September 7, 2026, in USD before applicable taxes; availability and local pricing can vary.

Tokens are the units used to measure text sent to and generated by a model. As an arithmetic example, 10 million uncached input tokens plus 1 million output tokens would cost $16.75 at those Muse Standard rates, or $1.20 at Contributor rates, before other billable tools. That is not an estimate of the tokens needed to build this board, nor evidence that one agent is cheaper for the same completed task.

If you already pay for a coding subscription and have sufficient allowance, its incremental subscription cost for this project may be $0. If you buy a $20/month option for the build, the lean $20/month hosting scenario becomes $40/month during months you keep both subscriptions, before domains, tax, and overages. Your deployed board does not need that coding subscription to serve visitors; resume parsing and matching use separately billed runtime services.

Include both the coding tool and the services in your build-and-run budget. Choose one coding tool, then add the infrastructure scenario you actually need:

These combined totals apply while you keep the coding subscription. They exclude domain registration, tax, overages, separately billed runtime AI, and optional services outside the selected scenario. The lean scenario does not include paid app-email or analytics services. Coding-tool allowances differ; these totals do not imply equivalent capacity or capability.

The selected paid-services subtotal is $114/month for one developer, excluding authentication, runtime AI, and other services and overages. That combination is an illustration of assembling paid services; it is not the cheapest way to launch. A lean board may remain within several free allowances, but check commercial-use terms: Vercel describes Hobby as intended for personal, non-commercial use. A hosted AI builder may bundle services that this stack buys separately.

For a concrete platform comparison, Cavuno Starter currently costs $39/month billed monthly, or $348 billed annually ($29/month equivalent). The live pricing page checked on September 7, 2026 lists 500 active jobs, 1,000 email subscribers, hosting, a custom domain with SSL, job aggregation, resume parsing, and 50 AI Builder credits per month. Starter retains the Cavuno footer credit; a custom email domain and removing that credit require Basic or above.

The $119–$134 combined DIY examples and $39 Starter price are not a measured like-for-like savings claim. The DIY examples buy a coding subscription and selected paid infrastructure; Cavuno includes application workflows within plan limits. Compare your actual requirements and usage on each side. Domain registration, payment processing, external automation subscriptions, and your operating time may still apply.

Model your own workload: active jobs, visits, search requests, subscribers, emails per month, and resumes parsed. Then compare a Cavuno plan that covers the same capacity. Keep payment processing and domain costs visible on both sides where applicable.

For budgeting beyond software, our job board startup cost guide covers the wider launch budget. Use the dated prices in this tutorial for its specific stack and recheck providers before committing.

Also record hours spent building, troubleshooting, updating, and operating the board. Leave those as hours unless you choose an explicit hourly value. We have not measured the reference build yet, so we make no claim about how long it takes.

What Cavuno supplies beyond this tutorial

The tutorial walks you through a useful first board and shows the work involved in getting it right. The next comparison is whether you want to keep assembling and maintaining the features around it, or use a job board platform that supplies them together.

AI coding tools help you build the software. Cavuno supplies a job board system you can configure and customize. The useful comparison includes both the experience you just built and the workflows you expect to need next.

A connected set of search and location pages

Cavuno includes programmatic pages for locations, categories, skills, and supported combinations. Its geographic hierarchy connects country, state, and city navigation—for example, Australia → New South Wales → Sydney—rather than leaving each location page disconnected. The hierarchy also supplies the breadcrumb trail and structured data. Its location directory builds parent/child relationships from place records, so the internal links follow the geography.

That matters as your inventory grows. Adding a Sydney vacancy has implications beyond the job detail page: which city and regional searches should include it, where a candidate can discover it, which related pages should link to each other, and what happens when the vacancy closes. In a custom build, you own those relationships and their tests.

Cavuno also handles canonical URLs, supported alias redirects, metadata templates, sitemap generation, and page-indexing rules. These are tools for maintaining a useful, discoverable site; they do not guarantee Google will index every page or rank it. Review the landing-page documentation and technical SEO guidance.

For the underlying page strategy, read our programmatic SEO guide for job boards. If your niche is a city or region, the local SEO guide covers that more specific growth plan.

Location lookup is another part of the build

The feature you type into is usually called place autocomplete or address autocomplete. Geocoding resolves a location to coordinates and geographic context. A custom board can use Mapbox Geocoding or Google Places Autocomplete, among other providers. A map is optional; consistent location data is useful even when you never display one.

Cavuno's location-input code uses Mapbox place identifiers and geographic context, then normalizes submissions on the server. The wider board connects those place records to browsing and location pages. In your own build, selecting “Sydney” is only the beginning: you need to distinguish places with the same name, maintain country and regional relationships, and keep remote-work eligibility separate from an office address.

The reference uses a small curated location list. Replacing it with global lookup is an optional extension, not a feature already validated by this tutorial:

1
Read PROJECT-BRIEF.md and BUILD-LOG.md, then inspect the existing project.
2
Preserve agreed decisions. Identify missing prerequisites before implementing.
3

4
Replace the curated location input with a provider-backed place picker.
5
Before implementing, identify the chosen endpoint, required credentials,
6
request costs, attribution, and permitted storage of its returned fields.
7

8
Let the employer select a place; do not treat unselected text as a verified
9
location. Use an internal place ID linked to the provider ID. Normalize the
10
permitted country, region, city, and coordinate fields on the server, and
11
model parent relationships without assuming every country has three levels.
12
Keep office locations and remote eligibility separate.
13

14
Handle keyboard selection, ambiguous names, clearing a selection, no results,
15
provider failure, and request limits. Debounce searches and prevent an older
16
response from replacing newer suggestions. Test a Sydney job appearing under
17
Sydney, New South Wales, and Australia, but not New Zealand. Explain how a
18
job with multiple office locations avoids appearing twice in a result list.

Check the chosen product's storage rules before designing the database. For example, Mapbox Geocoding distinguishes temporary results from permanent results, with different storage permissions. Do not assume every autocomplete product permits saving its full response indefinitely. Include lookup usage and the work of maintaining place data in your cost comparison.

The surrounding job board workflows

Availability depends on the selected plan, board configuration, and connected services. For example, profile matching must be enabled, paid workflows need payment configuration, and automated sourcing depends on its sources. Compare the workflows and limits you will actually use; buying a platform does not eliminate niche selection, employer relationships, content quality, or marketing.

Integrations you can build workflows around

Cavuno supplies several ways to connect the board to other software:

These are different interfaces to the job board system. Zapier and n8n run repeatable workflows; MCP lets an AI client work with supported board operations. Cursor or Codex can therefore be used with Cavuno as well as to build a board from scratch.

External automation services have their own charges and limits. Cavuno access also depends on the plan, credentials, and permissions. Choose minimum necessary access where supported, test with fictional records, and review an agent's proposed changes before authorizing consequential actions. An integration cannot manufacture a candidate's marketing consent: Cavuno's Zapier and n8n interfaces support finding or withdrawing permission, not granting it on someone else's behalf.

The AI builder has a job board system behind it

Cavuno's AI builder lets you create and customize your board with the platform's job board capabilities behind it. When comparing it with Lovable, Replit, Cursor, and similar tools, look beyond the first design: try the employer and candidate journeys, then compare the features and operating responsibilities as the board grows.

Those tools can build capable applications, and their bundled infrastructure can be good value. A custom build can make sense when your workflows are unusual, you want to learn, or maintaining the software is part of the project you want to own. Cavuno can make sense when you want to shape the board while using established job board workflows and operations. If you prefer a custom frontend in code, also explore the Cavuno SDK and verify that its supported workflows fit your requirements.

Check current inclusions, capacity, and AI Builder credits on the pricing page. Compare a plan with the same workload and features as your DIY scenario, including applicable payment and domain costs.

The local reference does not validate Cavuno's entire feature set or establish a production operating cost. Confirm your billed price and plan inclusions when evaluating a plan.

A third route: use an agent with Cavuno's starter kit

You can own and customize the frontend code while using Cavuno for the job board backend. Our TanStack Start + shadcn/ui template uses the Cavuno SDK and includes agent instructions for working with the supported platform contracts.

Its documented sandbox includes candidate and employer personas, an applicant pipeline, captured test emails, and Stripe test-mode checkout. This lets you explore more of the product while shaping its design. Follow the repository's current requirements and setup guide; it uses a different stack from Climate Roles. Moving to your own live board involves Cavuno configuration and applicable platform/hosting costs.

Climate Roles is the independent test build used for this article. The Cavuno starter kit is the route to explore when you want a custom frontend with the platform's existing workflows behind it. We inspected its documentation for this comparison; the tutorial's test results apply to Climate Roles, not to a new test run of the starter kit.

Check ownership and your route out

With a repository-based custom build, you can keep and change the application source, subject to its dependency and asset licenses. That is a meaningful advantage. Moving it still requires work: Convex functions and data, Clerk identities, file storage, deployment configuration, and external integrations do not become portable merely because the frontend is in Git. For hosted builders, verify code export and backend dependencies separately.

Cavuno documents data exports for jobs, companies, candidate profiles, subscribers, and blog content, with employer-account export available through the API. Check the fields and permissions you need. Candidate resume links require authenticated access, and employer application records are not available through the board-operator export. A CSV export is not a copy of the hosted application or a complete disaster-recovery backup.

Before choosing either route, export a small fictional dataset, inspect its relationships and consent/status fields, and work out how you would import it elsewhere. Also keep control of your domain and document where files, credentials, and backups live. These are evaluation checks; we have not completed a Cavuno migration or production restore for this tutorial.

Choose based on the work you want to own

Choose a custom build when controlling the implementation is part of the value: you have unusual workflows, want to learn, or have someone responsible for maintaining the software. Keep checkpoints of your own build, test each extension, and budget for operating it.

Choose Cavuno when your main work is building the audience, attracting employers, and running the board, and its supported workflows fit your plans. Use the same journeys from this tutorial to evaluate it: submit a job, review it, find it through search and location pages, and check the candidate experience. Then examine the additional features and limits your niche needs.

Ready to focus on running your board? Start with Cavuno, then use the journeys in this guide to evaluate it for your niche. Prefer to keep designing in code? Explore the Cavuno starter kit.

If you are still comparing approaches, use our job board software buyer's guide and current plans with your expected job inventory, subscriber count, and required workflows.