Recruitment Website Design: How to Build and Own It Yourself

Step 1. Get the site into a repo on your own machine

Your website is a folder of files, and right now it most likely sits on somebody else's computer. That is exactly why you have to ask them whenever you want a word changed.

Get that folder onto your own machine and into a repo: the same folder plus a complete history of every change, who made it, and a button to undo any of it. Then keep a copy online on GitHub, which is your backup and how anyone else on your team can work on the site. Do this on day one. Mine sits on one Mac with no online copy, which is the one thing I would do differently.

Here is the prompt. Fill in the two bracketed lines and paste the whole thing into Claude.

I have a website I want to take ownership of and start editing myself.
I am not a developer, so explain each step in plain English, and stop and
wait for me after each one.

My situation:
- My site is currently on: [WordPress / Webflow / Wix / Squarespace / a coded site / I am not sure]
- The files are at: [a folder on my computer / a hosting account / I do not know]

Please:
1. Tell me whether I can take these files and own them, or whether I need to
   rebuild elsewhere first. Be honest if the answer is that I have to move.
2. If I can own them, put the folder under version control and walk me through
   creating a PRIVATE repo on GitHub and pushing it there.
3. At the end, show me the history, and show me how to undo a change.

Step 2. Install the design skills, so the assistant has taste to borrow

Claude writes good code by default. It has no design judgement by default. You give it some with skills: folders of written instructions it reads before starting. Think of it as handing a competent builder a style guide written by an architect. You download the folder, drop it into your skills folder, and there is nothing to configure. All four are free and open source.

That first one includes a detector you run against any page to flag the generic, obviously-AI-made look. It is why I trust the output, because it gives you something to argue with other than your own eye at 11pm.

Step 3. Choose a design direction, and give it a name

Ask for three complete directions, each with a name and a world behind it, then pick one. Mine is called Signal and the world is an airport gate board: slate and ink, split-flap type, one violet for the primary action. Naming the world makes every later decision quick, because choosing a button shape becomes "would this be on a gate board?"

Give me THREE complete design directions for my recruitment website. Not one.

For each direction, tell me:
- a name, and the world it comes from
- the palette, and what each colour is used for
- the typography
- one thing this direction would never do

My agency: [what you place, and who for]
Who visits the site: [clients, candidates, or both]

Describe all three in words first. Do not write any code yet. I want to
choose before anything gets built.

Step 4. Keep your colours and fonts in one file

This is the single most useful idea in the process and it is simpler than it sounds. Your colours and fonts belong in one file that every page looks up, instead of each page keeping its own copy. Those stored settings are called design tokens, and a token is just a named setting.

So instead of fifty pages each saying "this heading is purple, specifically #8A00FF", every page says "this heading uses the brand colour", and one file says what that is. Change the file, and all fifty change with it.

Move every colour, font, spacing value and corner radius used anywhere on my
site into ONE settings file, and make every page read from that file instead
of keeping its own copy.

While you do it:
- check every colour pair for contrast, and tell me any that score under
  4.5 to 1 when used as body text
- tell me how many files you had to touch

When you are done, change one colour in that file so I can watch every page
follow, then change it back.

All 51 pages of my site changed appearance through two saved checkpoints three minutes apart, and I never opened most of them. The first changed fonts, colours and corner shapes and removed the old glow effects. The second changed the header, footer and buttons. That was the whole re-skin.

While you are in there, check your brand colour works as text. Readability is measured as a ratio, and anything under 4.5 to 1 is too hard to read as body text. My brand purple scores 3.3 to 1 on dark. It fails, and you can see it failing:

So the brand purple became a fill colour for buttons and panels only, and a lighter version of it does all the text. Your brand colour is not automatically a text colour, and almost nobody checks.

Step 5. Build on a branch and review it locally

Work on a branch. Run it on your own laptop, at an address nobody else can open, and walk through every page at your own pace with nothing touching the live version.

This is where you find out what Claude is genuinely good at. My old design had 96 pill-shaped elements across 39 files that needed squaring. But 42 other elements were real circles: avatars, status dots, icon wells. An ordinary find-and-replace would have squared all 138 and turned every profile photo into a box. What Claude wrote instead tested whether each one had the same fixed width and height, which is what makes a circle a circle, and left those alone. Two days of a developer's time, from one instruction.

Step 6. Port your existing copy word for word

A re-skin changes the formatting and leaves the words alone. I learned this the expensive way: my first attempt let Claude write fresh copy for three pages and all three were discarded. Your existing copy carries whatever search positions and conversion you have, and rewriting it as a side effect of a visual change is how agencies lose both without noticing.

Step 7. Deploy, then prove it is actually live

Publishing is two separate things and they are easy to confuse. Your new version gets uploaded, then your domain gets pointed at it, and most tools do the first automatically and the second only when told. Check both the plain domain and the www version, which are separate settings.

The check that catches it: open a page that exists only in the new version. A page-not-found error means your domain is still serving the old site, whatever the log says.

Publish the site, then prove to me it is actually live.

After publishing:
1. Tell me which version my domain is currently pointing at.
2. Check BOTH the plain domain and the www version. They are separate settings.
3. Open a page or a phrase that only exists in this new version, and show me
   the result.

If any of those three fail, tell me plainly what is still pointing at the old
version and what to do about it. Do not tell me it worked because the publish
log said so.

This cost me a full publish cycle. My new version uploaded perfectly and even worked on its own temporary address, while recruitergtm.com carried on serving the old one and the log said success throughout. Worse, the plain domain and the www version are two separate settings, so I updated one, saw no change, and could not work out why.