A job board that employers pay to post on

A job board website business makes money by charging employers to publish a listing, so the product is not the search page — it is the billing lifecycle behind it. Checkout, listing expiry, renewal reminders, refunds and duplicate detection decide whether the board earns or leaks.

Key Takeaways

• A paid job board is a billing system with a search page attached, not the other way round.
• Listings must have an explicit expiry timestamp; "active" as a boolean is the single most common design mistake.
• Payment webhooks, not the browser redirect, are the source of truth for whether an employer paid.
• Duplicate and spam detection belongs before publish, because refunding after publish costs you money and trust.
• Job posting pages are thin content by default — indexation strategy is a business decision, not an afterthought.
• Boring hosting is fine for most boards; a scheduled renewal job and backups matter far more than a fancy stack.
• If you cannot answer "who deletes a fraudulent listing at 9pm on a Saturday", the board is not ready to sell posts.

What is a job board website business, in engineering terms?

A job board website business is a web application that stores employer-submitted vacancies, gates their visibility behind a payment, and removes them on a schedule. The core objects are the employer account, the order, the listing and the expiry timestamp. Everything else — search, alerts, SEO pages — sits on top of those four.

That framing matters because founders usually describe the product as "a place to find jobs", then build search first and billing last. The result is a board where listings never expire, the database grows stale, and candidates stop trusting it. In practice, the boards that survive are the ones that treat a listing as a time-limited commercial object with a paper trail.

Why does the billing lifecycle break in production?

Payment confirmation arrives twice, late, or not at all, so a board that trusts the browser redirect will publish unpaid listings and reject paid ones. The reliable pattern is to write an order row from the payment provider's webhook, verify its signature, and make the handler idempotent using the provider's event ID as a unique key.

The other half is time. A listing sold for thirty days needs a job that runs every few minutes, flips expired rows out of the published state, and sends a renewal reminder before the deadline. Cron on a single server is fine until you run two app servers and the job fires twice, sending duplicate emails and double-charging renewals. Use a database-backed lock or a single scheduler with a lease.

When do you actually need a paid job board — and when don't you?

You need one when a specific audience is concentrated enough that employers will pay to reach it: a niche, a region, a profession. You do not need one when the audience is generic, because a general board competes directly with platforms that have more traffic than you will ever accumulate.

There is also a cheaper intermediate step. If you already run a content site or a community, a free board with paid featured placement tests demand without building a full checkout first. We have seen teams spend months on subscription billing for a board that never got twenty listings. Start with a single price, a single duration, and one payment provider. Compare that to the trade-offs in WordPress versus a custom website before you commit to a stack, because a board that is mostly forms and lists can live on WordPress for a long time.

How does a paid job board work end to end?

An employer creates an account, submits a vacancy, and is sent to a hosted checkout page. The provider confirms payment by webhook, the listing enters a moderation queue, and on approval it becomes publicly visible and is added to the sitemap. A scheduled job expires it later.

The mechanism that catches most teams is state. A listing moves through draft → pending_payment → pending_review → published → expired → archived, and every transition needs an audit row with who or what caused it. Without that, disputes become archaeology. Stripe's own documentation on hosted checkout and fulfilment is worth reading before you design the order table, because it explains why fulfilment belongs on the webhook rather than the success page.

Step-by-step: what does the setup sequence look like?

1. Model the data first. Create employers, orders, listings and listing_events. Give listings a published_at and an expires_at column rather than an is_active flag.
2. Wire the payment provider in test mode. Create a product and a price, redirect to the hosted checkout, and store the session or intent ID against the order row.
3. Handle the webhook. Verify the signature, insert the event ID into a unique index, and only then update the order. Replays must be no-ops.
4. Build the moderation queue. A simple admin screen listing pending submissions with approve, reject and edit actions is enough at the start.
5. Add the expiry job. Run it on a schedule and make it safe to run twice.
6. Generate the sitemap on publish and ping search engines, or let the sitemap file regenerate on a schedule and stay consistent.
7. Write the alerts. New listing, payment failed, webhook signature failure, and a daily count of published versus pending.

-- dry run first: see what the expiry job would touch
SELECT id, employer_id, expires_at
FROM listings
WHERE status = 'published'
  AND expires_at < now()
ORDER BY expires_at
LIMIT 50;

Run the SELECT before the UPDATE, always. Changing listing status in bulk is a state-changing operation: take a database backup or confirm you have point-in-time recovery before the first production run, and wrap the update in a transaction so a partial failure does not leave half the board expired.

Which configuration actually matters?

Four settings decide most of the operational pain: listing duration, renewal reminder offset, moderation mode and indexation policy. Duration drives cash flow and freshness. Reminder offset drives renewal rate. Moderation mode decides whether spam reaches the public page. Indexation decides whether you rank or drown.

Setting	What it drives	If you get it wrong
Listing duration	Cash flow cycle and how fresh the board looks to candidates	Stale pages accumulate and employers repost to stay visible
Renewal reminder offset	Renewal rate, the single biggest lever on repeat revenue	Listings expire silently and employers never come back
Moderation mode	Whether a listing is reviewed before or after it goes public	Spam and scams reach the public page and damage candidate trust
Indexation policy	Which listing and category URLs search engines keep	Thousands of thin, duplicated pages dilute the whole domain
Expiry job schedule	How quickly an expired listing stops being publicly visible	Expired roles stay live, and refund disputes follow

Indexation deserves its own decision. A board with three hundred near-identical "Sales Executive — Kathmandu" pages produces thin, duplicated content that search engines will discount. The usual compromise is to index category and location landing pages, index listings that are still live, and return a proper 410 or redirect once a listing expires. Decide that before launch, because retrofitting canonical rules across thousands of URLs is unpleasant.

How do you verify the board is actually working?

Verify with a test purchase end to end in test mode, then check the database rather than the screen: one order row, one listing row, correct expires_at. Replay the webhook twice and confirm the second call changes nothing. Then force a listing to expire and confirm it disappears publicly.

Run the same checks after every deploy. A staging environment that mirrors production data shape is worth the setup — the staging environment checklist covers the parts people forget, like outbound email and payment webhooks firing from the wrong environment. Nothing is more embarrassing than a test listing published live with a real price on it.

What are the failure modes, and how do you debug them?

The dominant failure is a paid listing that never publishes because the webhook was dropped. Check the provider's event log first, then your own webhook table. A signature mismatch usually means the raw body was parsed before verification; a 500 means your handler threw after the order was already written, so fix idempotency before replaying.

Second is the duplicate. Employers re-submit when they do not see the listing, or repost the same role weekly to stay at the top. Fuzzy matching on title plus employer plus location catches most of it, and a cooldown window catches the rest. Third is email deliverability: renewal reminders that land in spam quietly kill renewal revenue, so set SPF, DKIM and DMARC on the sending domain before launch, not after.

Fourth is the slow query. Full-text search over listings is usually fine in Postgres with a GIN index, and Postgres full-text search controls document how to weight the title above the body. Only reach for a separate search engine when you have a measured reason.

What does it cost to run, and who operates it?

Costs are dominated by engineer time, not infrastructure. A modest board runs comfortably on a small VPS or a managed platform with a managed Postgres instance; the drivers are listing volume, image storage for logos, and transactional email volume, which grows with every reminder you send.

Payment processing takes a percentage per transaction, and that number is set by your provider, not by your hosting — check the provider's current published rates rather than trusting a figure from a blog post. Operational overhead is the real bill: someone must handle fraudulent listings, refund requests and failed payments. Budget an hour a day, not an hour a month. If you want that handled rather than owned, our software development team builds and runs boards in your own accounts.

What are the security considerations?

Never store card data; use a hosted checkout or a provider's tokenised fields so the card number never touches your server. Verify every webhook signature against the raw request body. Treat the employer dashboard as multi-tenant: every query must be scoped by the owning employer ID, or one account can edit another's listing.

Then there is content. Job boards attract scams — fake employers collecting CVs, and money-mule recruitment. Require email verification on employer accounts, rate-limit submissions, and keep an audit trail of who approved each listing. Keep the accounts and the payment provider in the business's own name; the reasoning is the same as in the accounts a business should own.

What mistakes do teams make most often?

• Using a boolean is_active instead of real timestamps, so nothing ever expires cleanly.
• Trusting the success-page redirect instead of the webhook.
• Shipping without an admin moderation screen, then moderating by editing the database by hand.
• Indexing every expired listing and tanking the site's overall quality signal.
• No duplicate detection, so the board fills with the same role posted five times.
• Sending renewal reminders from a domain with no email authentication configured.

A realistic scenario

A Kathmandu training institute runs a small community for hospitality staff. They launch a board charging a flat fee per thirty-day listing. In month one, nineteen employers pay. Two listings never appear because their webhook handler returns a 500 on a missing field; the developer finds it in the provider's event log the same week. One employer disputes a charge because they reposted the same job twice.

By month three they add duplicate detection on employer plus title plus location, a seven-day renewal reminder, and an admin queue. Renewal rate goes from roughly a third to over half, because employers now get a reminder instead of silently expiring. The engineering work is small; the operational discipline is what changed the number. That pattern — build a little, operate it properly — is what separates a board that earns from one that stalls at twenty listings.

In short

Build the order table and the expiry job before you build the search page. Treat the webhook as the truth, make every handler idempotent, moderate before publishing, and decide your indexation rules up front. Then run it with alerts and a nightly backup, and answer the renewal question honestly: reminders, not hope, drive repeat revenue.

People also search for

• How long does it take to build a job board?
• Custom software versus an off-the-shelf job board script
• Shared hosting, VPS or cloud for a job board
• What does a scalable website actually mean?
• Integrating payments and email into a web application
• Handing over a website your team can run
• What a cheap build really costs over three years
• Should you rebuild or fix what you have?

If you are weighing up a paid job board for your industry, our team can help you scope the billing lifecycle, the moderation workflow and the hosting, then hand it over with the accounts in your name. Talk to us about your board, or see how we have delivered similar platforms in our portfolio.