How to Build a Recruiting Agency Website Without Code

To build a recruiting agency website without code, describe your two audiences separately, treat vacancies as data rather than pages, and let an AI builder assemble the site. On Zugo a single-page agency site takes about a minute, and a job board with applications takes a few minutes to build.

Recruiting sites fail in a specific way. They are written for one audience and read by two, so the employer sees candidate language and the candidate sees sales language, and both leave. Splitting the site by audience is the whole trick.

Why does a recruiting site need two front doors?

An employer and a candidate arrive with opposite questions. The employer wants to know whether you can fill a hard role and what it costs. The candidate wants to know whether you have anything worth their Tuesday evening.

Answering both on one home page produces mush. Answering them on two clearly labelled paths, "hire talent" and "find a job", lets each visitor self-select in one click and then read a page written entirely for them.

That split also changes your calls to action. The employer path ends in a briefing form: role, seniority, location, budget, urgency. The candidate path ends in a job list and an application. Different forms, different tone, different proof.

It changes the proof too. An employer is convinced by time to shortlist, sectors you place in every month, and what happens if a hire leaves in the first three months. A candidate is convinced by live vacancies with real salary ranges and a consultant who replies. Publishing both sets of evidence on the same page dilutes each of them.

What should the prompt say?

Name your sectors, your seniority range and your geography. A recruiting prompt without those returns a page that could belong to any agency on earth, and generic is fatal in a market where the client is choosing between four suppliers.

Build a website for [agency], a recruitment agency specialising in
[sectors] at [seniority levels] across [geography].
Two paths from the home page: "Hire talent" and "Find a job".
Employer path: how we work in 4 steps, sectors we cover, typical
time to shortlist, guarantee terms, case summaries, briefing form
(role, seniority, location, salary range, start date, notes).
Candidate path: job board with filters (sector, location, salary,
contract type, remote), job detail page, application form with
CV upload, speculative application form, advice articles.
Also: about, team, contact.
Tone: direct and factual, no talk of passion or synergy.

Ask for the job board as one template rendering many vacancies, not as a page per role. Say it in those words. It is the difference between a site you can post to weekly and a site you dread updating.

Zugo ships 25 ready templates, and a service or landing template gives you a structure to rewrite in your own words. The prompt principles in general are covered in how to build an app with AI.

What does a job board actually need to store?

Two tables, plus a file. Naming them in the prompt is what separates a working board from a list you edit by hand.

Say that a vacancy disappears from the board when its status changes or its closing date passes. Expired roles on a public board are the single loudest signal that an agency is not paying attention, and automating it is one sentence in the prompt.

Add a "source" field to applications even if you never use it at first. Knowing whether candidates came from the board, a job aggregator or a referral is the only way to decide where to spend advertising money later.

How do CV uploads and applications work?

A CV upload needs real storage and a real database, because files are large and applications are personal data you are accountable for.

Connect Supabase and you get Postgres for the vacancies and applications, file storage for CVs, and accounts so your consultants can sign in to a private view. That private view is what turns the website into a tool rather than a brochure: a list of applications per vacancy, filterable by stage.

Add Resend so each application also emails the consultant who owns the role. A pipeline nobody opened over a weekend loses candidates to whoever replied first, and in recruitment speed is most of the product.

Test the upload with a real file. Try a 15 megabyte PDF, a .docx, and a file with a space and an accent in the name. Those three cases catch nearly every upload bug that would otherwise appear on your busiest day.

Be deliberate about retention. Decide how long you keep a CV, say so on the form, and give people a way to ask for removal. The builder will draft that wording for you, and you should read it as a statement about your agency rather than about the tool.

What does a recruiting site cost to build and run?

A multi-page build with a job board is billed as a platform: 12 credits flat for the first three pages, then 3 credits for each additional page. A single-page agency site with no board is 6 credits and about a minute.

Zugo's Free tier gives you 5 credits to try the flow. Pro is $25 per month for 200 credits, which works out to 16 full platforms or 66 edits, and includes connecting your own domain. Business is $99 per month for teams.

Because an edit costs 3 credits, keeping the site current is cheap in a way that matters here: "add a contract type filter", "show salary as a range not a single figure", "move the application form above the requirements list". Hi-Fi mode doubles both figures, 12 to build and 6 to edit, and is best spent on the two landing pages rather than the whole board.

Until you attach a domain the site lives at youragency.zugo.run. Pointing your own domain at it takes a few minutes, as described in connecting a custom domain.

Where does an AI builder stop for a recruitment agency?

Four honest boundaries.

A full applicant tracking system is a product, not a page. Multi-stage pipelines with interview scheduling, scorecards, offer management, client portals and reporting is real software. You can build a useful subset: vacancies, applications, stages, notes. Zugo does not replace a development team on the full thing.

Job aggregator feeds are integrations with contracts. Posting automatically to the large job boards means their APIs, their credentials, their formatting rules and usually their commercial terms. The builder makes the site, a developer makes the pipe, and GitHub export means that developer starts from your real code.

CV parsing and matching are their own field. Extracting structured data from a résumé reliably, then ranking candidates against a role, is a specialist service you would integrate rather than prompt into existence. Anything that ranks people also needs a fairness review, which is a policy decision and not a build step.

Data protection is your responsibility. Candidate records are personal data with retention and access obligations that vary by country. Connecting a database does not make a system compliant. Decide the policy with a lawyer, then reflect it in the site.

Before a build reaches you it is booted in a sandbox: it has to load and render, and a failure is reported as a failure rather than handed over as a blank page. That lowers the risk of publishing something broken and does not remove your own testing. Apply to your own vacancy from a phone, with a real CV, and confirm both the email and the database row arrived.

Split the site by audience, treat vacancies as data, connect storage before you advertise a role, and test one full application yourself. You can start on the free credits at zugo.dev and have a live job board this week.