How to Build a Job Board Without Code: Step by Step Guide
How to Build a Job Board Without Code: Step by Step Guide
To build a job board without code, describe three things in plain language: the job listing fields, how employers post, and how candidates apply. Connect Supabase for the database and logins, then let the builder generate the screens. It bills as a platform at 12 credits plus 3 per page beyond the first three.
The hard part of a job board was never the software. It is having jobs and having readers, and one of those has to exist before the other. Build the smallest board that serves the audience you already have, rather than a general marketplace nobody visits.
What kind of job board are you actually building?
There are three shapes, and they need different builds. A curated niche board where you post every job yourself is the simplest: one table, one form, no employer accounts at all. Most successful small boards start here and many never leave.
A self-serve board where employers create accounts, post jobs, and pay is a real application. It needs authentication, a moderation step, a payment flow, and an admin view. Everything about it is heavier, and it only pays off once employers are asking to post without being chased.
An aggregator that pulls listings from other sites is a fourth thing entirely, and largely a legal and engineering problem rather than a design one. A generated app is the wrong tool for it, and this guide does not cover it.
What data model should you describe?
Three objects carry a board. Write the fields out before you open the builder, because adding a field later is a cheap edit and changing the shape of the model after real listings and applications exist is not cheap at all.
- Jobs. Title, company, location, remote policy, employment type, salary range with currency, description, how to apply, posted date, expiry date, status.
- Companies. Name, logo slot, one-line description, website, contact email.
- Applications. Candidate name, email, link or attachment, message, the job it belongs to, date, status.
Two fields decide whether the board is useful. A salary range, because a board that shows salaries gets read and a board that hides them gets skimmed. And an expiry date, because nothing kills a job board's credibility faster than a front page of roles that were filled in March.
What should the build prompt say?
Build a job board for [niche], hosted at [domain].
Login through Supabase. Two roles: admin and employer.
Objects:
- Jobs: title, company, location, remote (onsite/hybrid/remote),
type (full-time/contract/part-time), salary min and max in US
dollars, description, apply method (link or in-app form),
posted date, expiry date, status (draft/live/expired)
- Companies: name, logo, one-line description, website, contact email
- Applications: name, email, link, message, job, date, status
Screens:
1. Board: list of live jobs, newest first, filter by location,
remote policy and type, search by title
2. Job page: full description, salary, company block, apply button
3. Post a job: employer form, saves as draft pending admin approval
4. Employer dashboard: their own jobs and application counts
5. Admin: approve or reject drafts, expire jobs, see all applications
Jobs expire automatically on the expiry date and leave the board.
Salaries always shown in US dollars. Dates as YYYY-MM-DD.
"Saves as draft pending admin approval" is the single most valuable line in that prompt. An unmoderated board fills with recruitment spam within weeks, and retrofitting moderation is much more work than asking for it on day one.
What does a job board cost to build?
A board is a platform build rather than a single page, priced at 12 credits for the first three screens and 3 for each screen after that. The table shows the three shapes described above with their real cost.
| Build | Screens | Credits | What it gives you |
|---|---|---|---|
| Curated board | Board, job page, admin post form | 12 | You post everything, no employer accounts |
| Self-serve board | Adds employer posting and dashboard | 18 | Employers post, you approve |
| Full board | Adds an admin screen for moderation and applications | 21 | The full posting, approval and application flow |
| One change afterwards | n/a | 3 | New filter, reworded field, different sort order |
Free comes with 5 credits, below the cost of a single page, so it is a way to look around rather than to launch. Pro is $25 per month for 200 credits, which is where the iteration cycle lives. Business is $99 per month. The pricing guide has the detail.
How do you charge employers?
Stripe, and the simplest model that works is a flat fee per posting. It needs no subscription logic, no seat counting, and no proration, and it is what most small boards charge. Describe it as "paying unlocks the job from draft to live" and the payment becomes part of the posting flow rather than a separate errand.
Two upgrades come later, once employers are repeat customers. A featured listing at a higher price, which is a boolean on the job and a sort rule on the board. And a subscription for agencies posting continuously, which Stripe supports directly. The connector details are in payments in an AI-built app.
Do not charge before there is traffic. A board with no readers cannot sell postings at any price, and the usual sequence is free postings until employers start arriving on their own, then a modest fee that filters out the least serious.
How do candidates apply, and where do applications go?
Two options, and picking one deliberately matters. An external apply link sends the candidate to the employer's own system, which means no data for you and no work for you. An in-app form keeps applications in your database, which is more useful and more responsibility.
If you take applications yourself, Supabase stores them in a real Postgres database under your own account, with logins for employers so each sees only their own. Resend emails the employer when an application arrives, because a dashboard nobody opens is not a notification. Setup is in connecting Supabase.
Applications are personal data, so decide the retention rule before launch rather than after a request to delete one. Who can see an application, how long it is kept, and what happens when a job expires are three sentences that belong in the prompt and in your privacy policy.
Close the loop on rejections while you are at it. A board that lets an employer mark an application as closed, and sends the candidate one line saying so, earns more goodwill than any styling decision on the page. That is one status field and one email template, and it separates a board people recommend from one they try once and forget.
What will a generated job board not do?
- Aggregate other boards. Scraping and feed ingestion is engineering work with legal edges, and no prompt produces it responsibly.
- Integrate with applicant tracking systems. Pushing candidates into a specific ATS through its API is developer work. Export to GitHub and hand it over.
- Search at scale. Filters and title search are fine. Ranked full-text search over tens of thousands of listings is a different system.
- Bring you traffic. The build is an evening. The audience is the actual project, and it is measured in months.
Zugo does not replace a development team on a marketplace that becomes a business. What it does well is get a real, working, moderated board in front of a niche audience fast enough to find out whether that audience wants one.
What should you launch with?
A curated board: one page listing jobs, one page per job, and an admin form only you can reach. That is 12 credits. Post fifteen real jobs you found by hand, share it with the community you already have, and see whether anyone comes back next week.
If they do, add employer posting and payment. If they do not, you have spent an evening rather than a quarter. A companion email list, built the way a newsletter signup describes, is usually the second thing worth adding. Start at zugo.dev.