Designing a personal or professional website from scratch
Build Your Own Website with AI: No Code, Almost Free | AI for Growth, Step 1 of 6
A prompt that interviews you one question at a time, then writes the complete brief for the coding assistant that builds the site.
The prompt
Designing a personal or professional website from scratch
I want you to help me design my ideal personal or professional website from scratch.
I am at the beginning of my AI journey, so keep the process simple. Use plain English.
Explain any technical term the first time you use it.
I will give you:
1. My CV or résumé.
2. A link to my LinkedIn profile.
3. Any other websites, profiles, examples or materials that may help.
Start by reviewing those materials so you understand my background, experience, current
work and professional credibility.
If you can access the LinkedIn link directly, review it. If you cannot, ask me to paste the
relevant LinkedIn text instead.
## Your goal
Your job is to learn enough about me to eventually create one complete website build prompt
that I can give to a coding LLM such as Claude Code, Codex, Gemini or another coding
assistant.
Do not create the final build prompt yet.
First, interview me.
## How to interview me
Ask me **one question at a time**.
Wait for my answer before asking the next question.
Do not give me a long questionnaire.
If my answer raises an important follow-up question, ask that next.
If I am unsure about something, recommend what you think would work best and briefly
explain why.
Keep each question simple.
Avoid technical jargon unless it is genuinely necessary.
Do not ask me for information that is already clear from my CV, LinkedIn or previous
answers.
Remember everything I tell you and use it to shape later questions.
If two of my answers conflict, ask me to resolve the conflict.
If I am making the website unnecessarily complicated, tell me.
If something would be better added in a later version, tell me.
Prefer a simple first version that works well.
## What you need to understand
Over the course of the interview, work out:
* What I want the website to achieve.
* Who the main visitor is.
* Who I want to hire me, buy from me, follow me or contact me.
* What I actually offer.
* What makes me credible.
* What work, projects, case studies or results I can show.
* What parts of my background should be prominent.
* What parts should stay in the background.
* How I want to describe myself.
* What I want visitors to think after seeing the site.
* What tone the site should have.
* What actions I want visitors to take.
* What the main calls to action should be.
* What pages the website needs.
* What belongs on the homepage.
* Whether I need pages for projects, writing, videos, prompts, case studies, FAQs, contact
or anything else.
* Whether I have a newsletter, YouTube channel, LinkedIn, X, Substack or other content to
connect.
* What content should appear automatically.
* What content I will add manually later.
* What visual style I like.
* What websites I like and why.
* Colours, typography, photographs and branding.
* What I definitely do not want the website to look or sound like.
* Whether I need light and dark mode.
* How forms should work.
* How booking should work.
* Whether people should be able to sign up to a newsletter directly on the site.
* Whether the site needs SEO, which means helping search engines understand and rank the
site.
* Whether it needs AEO, which means helping AI answer engines understand and surface the
site.
* Whether analytics are needed at launch.
* What privacy, legal and cookie pages are needed.
* Accessibility requirements.
* Mobile behaviour.
* Where the site will be hosted.
* How it will connect to GitHub.
* What technical stack should be used.
* Whether the site should be mostly static or more application-like.
* What should be automatic and what should stay simple.
* What information is still missing before the site can be built.
Do not mechanically ask every item above.
Use judgement.
Skip anything irrelevant.
## Important rule
Keep asking questions until you believe you understand the website well enough that a
coding LLM could build it without repeatedly coming back to me for decisions.
When you are nearly finished, tell me approximately how many important questions remain if
I ask.
Do not create the final build prompt until the interview is complete.
## When the interview is complete
Tell me that you have enough information.
Then create one complete **Website Build Prompt** that I can copy and paste into my coding
LLM.
The final build prompt should be self-contained.
It should include everything the coding LLM needs to understand the project.
Include:
* purpose of the website;
* target audience;
* positioning;
* offer;
* tone of voice;
* copywriting rules;
* complete page structure;
* homepage structure;
* navigation;
* calls to action;
* projects or case studies;
* content integrations;
* newsletter requirements;
* video requirements;
* design direction;
* mobile behaviour;
* accessibility;
* SEO;
* AEO;
* structured data;
* forms;
* booking;
* privacy and legal requirements;
* cookie requirements;
* technology stack;
* GitHub workflow;
* hosting requirements;
* performance;
* security;
* testing;
* error handling;
* README requirements;
* environment variables;
* placeholders I still need to provide;
* final pre-launch checks.
If reference websites have been provided, clearly distinguish between:
* websites used as design inspiration;
* websites used as factual or content sources.
Tell the coding LLM not to copy another website.
It should extract useful principles and create an original design.
## How the coding LLM should work
The final build prompt must tell the coding LLM to:
1. Inspect the repository first.
2. Review all source material and reference websites.
3. Create a clear implementation plan.
4. Validate that plan against the brief.
5. Then build the complete website autonomously.
6. Make sensible decisions without constantly asking me questions.
7. Use TODOs only where genuinely missing information prevents a correct answer.
8. Never invent facts about me.
9. Never invent clients, testimonials, results, credentials, numbers or statistics.
10. Test everything it builds.
11. Inspect the test results.
12. Fix the problems it finds.
13. Retest.
14. Continue until the defined acceptance criteria pass or it reaches a genuine blocker.
15. Never push to GitHub or deploy unless I explicitly tell it to.
## Agentic build loop
The coding LLM should work in a **bounded agentic loop**.
That means:
**Plan → Build → Test → Inspect → Fix → Retest**
Repeat this loop until:
* the site builds successfully;
* the important functionality works;
* accessibility requirements pass;
* mobile and desktop layouts work;
* SEO and AEO requirements are implemented;
* forms and interactions work;
* there are no obvious broken links or unfinished sections;
* the requirements in the brief have been satisfied as far as possible.
A successful first build is not the finish line.
The LLM must inspect its own work and improve it.
However, the loop must stay inside the agreed scope.
Do not add features merely because they seem interesting.
Do not redesign the project around new ideas that were not requested.
Do not keep iterating indefinitely.
When all achievable requirements pass, stop.
If something genuinely requires information or credentials from me, leave a clear TODO and
continue with everything else.
## Testing and final audit
The build prompt should require a proper pre-launch audit covering:
* production build;
* TypeScript or compile errors;
* broken links;
* desktop layout;
* mobile layout;
* keyboard navigation;
* accessibility;
* forms;
* modals;
* navigation;
* dark mode if used;
* SEO metadata;
* sitemap;
* robots.txt;
* structured data;
* Open Graph sharing;
* performance;
* image optimisation;
* unnecessary JavaScript;
* security basics;
* missing content;
* factual accuracy.
The coding LLM should fix issues it can fix before stopping.
## Final handoff
When the coding LLM finishes, it should provide a concise handoff report containing:
* what it built;
* what it tested;
* whether the production build passes;
* remaining TODOs;
* anything I still need to configure;
* any credentials or environment variables I need to add;
* exact commands I should run;
* whether the repository is ready to push and deploy.
It should then stop and wait for my instruction.
## Writing style
Throughout this process, keep your explanations accessible to someone doing this for the
first time.
Do not assume I understand web development.
If you recommend a technical choice, explain briefly why it matters.
Do not overwhelm me with several decisions at once.
Start by reviewing my CV and LinkedIn profile.
Then ask me the **first question only**.Most people brief a website badly, and not through carelessness. You are asked to describe something you have never built, for an audience you have not yet had to define, in one go. The result is a brief full of things that sound right, and a build that has to stop every few minutes to ask you what you actually meant.
This prompt inverts the order. It refuses to write anything until it has interviewed you, and it asks one question at a time. That constraint is the part doing the work. A questionnaire gets skimmed and half answered. A single question, waiting on its own, gets a real answer, and the answer shapes the next question rather than sitting in a list.
How to use it
Have your CV and your LinkedIn profile to hand before you start, and paste the LinkedIn text if the model cannot open the link. Answer briefly. Where it offers a recommendation, take it unless you have a reason not to, because the recommendation is usually the simpler option and a simple first version is the one that gets finished.
The output is not the website. It is a long build prompt for a coding assistant. It should feel too long. Its whole purpose is to answer, in advance, the questions the assistant would otherwise interrupt you with halfway through.
What to watch for
If it starts drafting the build prompt while it is still learning about you, tell it to keep interviewing. Models are eager to produce the deliverable.
The instruction that matters most is the one near the end: never invent facts, clients, results or credentials. On a personal site, an invented detail is not a rough edge. It is something you will have to explain to somebody who checked.
If a prompt gets you most of the way there and you want the rest of it built properly, that is the work.