Skip to content
    Web design

    How to get clients as a vibe-coding web designer

    The practical answer

    Find a business with a specific website problem, build the smallest prototype that makes the improvement clear, and offer a defined paid scope. Treat the prototype as a conversation starter. Track qualified conversations and signed work rather than how many demos or emails you produce.

    Tommy proposed this prototype-led approach from his website-building practice. The inspection lessons below come from our own Click and Mortar implementation: checking live booking availability, distinguishing form acceptance from delivery, and correcting a mobile media fallback. The prospect and pricing examples are illustrative; this is not a tested client-acquisition campaign or a claim of measured sales results.

    Four-step prototype-led client method: observe a verified issue, demonstrate one improvement, verify the demo, and define a priced scope with acceptance criteria.
    Keep the investment proportional to the next decision. A small credible demonstration can begin a conversation; it does not prove demand or guarantee a client. Open full-size graphic ↗

    Start with a problem you can show

    Imagine a local service business whose mobile page buries its booking link below a large hero video. Your opening offer is not “I can build with AI.” It is a small demonstration of a clearer route from the service description to an available appointment. That example is fictional, but the decision is practical: choose a problem the owner can recognize without understanding your tools.

    A fast prototype is useful only if it reduces uncertainty. It can show a proposed visual direction, a better mobile layout, or a clearer inquiry flow. It cannot establish demand, prove a conversion increase, or tell you what the owner can afford. Write your observation and the intended improvement before opening an AI coding tool.

    Our own booking work supplies a useful caution. A link on the page looked like a booking integration, but its destination initially reported an unavailable calendar. We checked the public dates and time slots after account access was restored. We did not book an appointment. Use that same distinction in a prospect demo: a button is not evidence that the complete business process works.

    Research a small, relevant prospect set

    Choose one business category you understand and one kind of problem you can fix. Manual discovery through Google Maps can help you locate businesses and their public websites. Visit the actual site and verify the observation yourself. A directory entry alone does not tell you that the business wants a redesign, who approves it, or whether its current provider is already rebuilding it.

    Keep a short research record: business website, observable issue, date checked, proposed improvement, and a suitable public contact route. Do not turn public visibility into permission to subscribe someone to your newsletter. Keep prospects separate from readers who explicitly requested your Field Notes.

    A purchased lead list may reduce discovery effort, but it does not verify relevance, freshness, permission, or deliverability. Google’s sender guidance advises against purchasing email addresses. For this method, begin with a small manually verified set and a contact approach appropriate to the recipient and your sending provider. Do not automate volume before you know whether the offer is useful.

    Discovery routeWhat still needs checking
    Manual Google Maps researchCurrent website, actual problem, relevant contact route and platform rules
    Purchased lead listProvenance, accuracy, permitted use, recipient relevance and provider restrictions
    Referral or existing relationshipCurrent need, decision maker, scope and permission to follow up

    References: Google: Email sender guidelines

    Choose a brand concept or a working prototype

    A brand-direction concept is enough when the question is visual: typography, color, imagery, and hierarchy. Show one representative page or section. Explain which material is a suggestion and which facts came from the business. Do not add invented testimonials, customer logos, awards, prices, or service claims to make the concept look finished.

    A working prototype is more useful when the question is behavior: a mobile menu, a filtered service list, or the steps in an inquiry. Host it at a clearly labeled preview URL if appropriate. Use fictional or permission-cleared content, keep demo forms from collecting real customer information, and make the concept’s unofficial status visible. A publicly reachable URL should never impersonate the business.

    Set a preparation budget before you build. One section, one key interaction, and one short explanation may be enough to ask whether the owner wants to talk. If you build an entire unpaid production site for every prospect, fast generation can hide substantial inspection and revision costs. Increase investment after a qualified conversation establishes the need.

    Inspect the promise before you share it

    The most useful lesson from our site work is to test what the interface claims. A form can show a success state before you have evidence that a notification arrived. A calendar can load without offering bookable times. An animation can look correct on desktop and expose an unwanted backing on mobile. These are different failures, and a polished screenshot will not catch them.

    Use a small acceptance checklist for the specific demo. Open the real preview URL on a narrow screen, follow the main action, and test the expected failure state. For a visual-only concept, say that forms and booking are illustrative. For a working integration, say exactly which part was verified. Do not represent an email provider’s acceptance as proof that a person read the message.

    Keep the demo readable when optional media fails. If the visitor needs a video to understand the service or find the next step, the demonstration is too dependent on the asset. Our animation and lead-capture Field Notes explain those implementation checks in more detail.

    • Verify every factual claim against an approved source.
    • Check the primary action, keyboard focus and mobile layout.
    • Label demo-only forms and interactions.
    • Remove private client details and credentials.
    • Write down what is tested and what remains illustrative.

    Price the deliverable, including the work after generation

    Quote a defined outcome: which pages, which integrations, who supplies copy, how revisions work, and what counts as acceptance. The speed of the first AI-generated version is only one input. Review, accessibility fixes, content cleanup, hosting configuration, handoff, and maintenance still consume time.

    Use a worksheet rather than copying an unexplained market price. An illustrative calculation is 18 delivery hours plus 6 review and handoff hours, multiplied by an internal planning rate of $75 per hour: $1,800. Add clearly stated external costs and a risk allowance if appropriate. These are invented planning inputs, not Click and Mortar’s price, a market benchmark, or a quote for a real business.

    Separate the initial build from recurring work. Name the hosting owner, ongoing service fees, maintenance scope, and what happens when the client wants another page or integration. A clear exclusion is useful: for example, a booking link is included, while migrating a customer database requires separate scoping. Do not advertise a fixed price for an undefined system.

    Offer worksheetWrite this before quoting
    Problem and desired actionWhat should the visitor be able to do?
    Included deliverablesPages, content, integrations and review rounds
    AcceptanceSpecific checks that make the work complete
    Client inputsCopy, assets, account access and decision owner
    Price and payment milestonesTotal, assumptions, external costs and payment timing
    After launchOwnership, support period and maintenance boundaries

    Make the outreach about the observed problem

    A useful message can be short: identify yourself, explain one specific observation, describe the proposed improvement, and ask whether the owner wants to see the concept. Do not claim that their website is losing a particular amount of money unless you have evidence. Avoid manufactured urgency or implying that they requested the work.

    For example: “I noticed the appointment link is difficult to find on the mobile service page. I made an independent concept showing a shorter route to booking. Would a quick look be useful?” This is sample body copy, not a complete send-ready commercial email. Add the required sender identification, postal address and opt-out information for the applicable context.

    In the United States, the FTC says CAN-SPAM covers commercial email, including business-to-business messages. Its guidance requires truthful sender information and subject lines, advertisement identification, a valid physical postal address, and a clear opt-out mechanism, among other requirements. Other jurisdictions and sending platforms can impose additional restrictions. Personalization does not remove those obligations.

    References: FTC: CAN-SPAM Act compliance guide for business

    Track the next decision, not just the send count

    Use a simple pipeline: researched, relevant contact identified, conversation started, qualified need, proposal, accepted, and delivered. Record why a prospect moves or stops. Separate “no reply” from “not interested,” and respect opt-outs. Never add nonresponders to a subscriber sequence.

    When an owner responds, ask about the business process before expanding the prototype. Where should inquiries arrive? Who maintains the calendar? Which content can they supply? Who owns the domain and hosting? These questions turn the attractive concept into a scope you can deliver responsibly.

    If people like the visuals but never discuss a project, review the audience, problem, offer and follow-up approach. Do not assume that sending more will fix the mismatch. Improve one part of the method at a time and keep your records honest. The goal is paid work you can complete well, with a clear handoff—not a folder full of impressive speculative websites.

    Common questions

    Should I build an entire website before contacting a prospect?

    Usually start with the smallest concept that makes one improvement understandable. Expand after a conversation confirms the need, decision maker and scope. A complete speculative site can consume substantial unpaid review time.

    Should I tell clients I use AI to build websites?

    Explain your workflow honestly when it affects the engagement. Make your responsibility for review, factual accuracy, testing and delivery clear. Do not sell generated output as evidence of verified business results.

    Is there a standard price for a vibe-coded website?

    This guide does not establish a market rate. Price the actual scope, integration risk, review effort, external costs and support obligations. The arithmetic example is a worksheet demonstration, not a recommended universal quote.

    Sources and further reading

    Primary references checked on September 11, 2026. Product claims belong to the cited provider; implementation recommendations reflect our judgment.

    Field Notes / for developers

    The next lesson, in your inbox.

    A short, practical blurb for every new note, with a link to the full method. Web development, useful motion, automation, and lessons from AI-assisted builds. Up to three emails a week.

    Developer notes, no sales sequence. Privacy · Prefer RSS?

    Learn by building / with Tommy

    Want a hand getting started?

    If you want to get into AI web design or get better at vibe coding, I’d love to help you get started at no charge. Bring a project, a stuck prompt, or a question. I find I learn more by teaching others.

    Book a free 30-minute learning call

    A practical conversation. No experience required.

    AI assists research and drafting. Articles are checked for source support and clear distinctions between examples and verified work. Read our editorial policy. Suggest a correction.

    Keep building your understanding.