A local shop owner shows you their website on their phone, and they wince. It is slow, it is ugly, and they know it is costing them customers. You open a blank Framer canvas that evening. A week later the new site goes live, and the owner is already asking what else you could fix.
Compare that with the job you are in now. Maybe you are a designer whose work gets reworked by committee, or someone who has always liked making things look good but never got paid for it. Meanwhile AI design tools improve every month, and the people they squeeze are the ones who only make mockups.
Here is the window. Businesses still need someone to build, launch and maintain real sites they can edit themselves. That work resists automation better than pure design does, and clients stick with the builder who understands their content. The builders landing those clients now are the ones local businesses will refer to each other next year.
What it takes: you can begin at $0, because the free tiers carry you while you are still learning, and even a properly kitted-out setup tops out around $600. The work tends to start paying somewhere between two and five months in, and a steady month at the quiet end of this looks like $1,000. You need no server and no code.
Tonight, open a free project and rebuild one page of a site you already admire, from scratch, just to see how close you get.
Picture the two ends of the market. At one end, template builders produce a site in an afternoon for almost nothing, and it looks like a template. At the other, custom development produces exactly what a business wants, and it costs tens of thousands with a timeline to match. Between them sit a large number of businesses that need something genuinely designed, genuinely their own, and genuinely maintainable by their own staff afterwards, with no development team.
That middle is bigger than it sounds, and it is unusually stable. Think of a business with fifteen employees and a real marketing function. They cannot use a template, because their content does not fit one and their brand matters to them. They also cannot justify a custom build, because the cost is out of all proportion for a marketing site and the result needs a developer every time a page changes. They have been stuck between those two options for as long as the web has existed, and visual development platforms are the first tools that genuinely serve them: designed like a custom site, editable like a template. Anyone can learn the platform. Your opportunity is the segment itself, which has money, a recurring need, and no good alternative. Can you think of three businesses near you that fit that description right now?
Visual development platforms fill that gap, and the rates show it. Published figures put Webflow developers at $50 to $200 an hour, with freelancers on marketplaces at the lower end around $50 to $90. Framer freelancers are quoted at $60 to $150 an hour, with project rates of $3,000 to $10,000.
Let us face this head on, because a tool that generates websites from a prompt looks like an obvious threat to a business built on building websites.
Generation is genuinely good at producing something that looks like a website. It is poor at everything that makes a website work for a specific business: content structure that matches how they actually publish, a CMS a non-technical marketer can update without breaking the layout, forms that go to the right place, connections to the systems they already use, performance with real content in place of placeholder text, and behaviour at every screen size with the awkward content they actually have.
That distinction matters because it is the same one running through the graphic design guide on this site. Visual output got cheap. Building something that survives contact with a real business stayed expensive.
Three parts of this work last for that reason.
There is less design in it than people assume, and less coding than the title suggests.
You have seen what a build actually asks of you. What someone will pay you for it is a separate question, and it is the one that decides whether this is a hobby.
The hourly bands are published, and the project approach serves you better.
Price the project rather than the hour, for the reason that comes up in every service guide on this site: your speed improves a lot with reusable components and experience, and hourly billing turns that improvement into a pay cut.
Scope a project fixed build by page count and template count rather than by hours, name the number of revision rounds, state what the client supplies and by when, and spell out what happens when content arrives late. That last one matters more here than in most work, because a site cannot be finished without content, and content is always the bottleneck. Have you ever had a project stall because someone else was late with their part?
Three income lines beyond the build are worth setting up from the start.
If a single brochure build at the low end brings in 1,000 dollars this month and the costs leave enough, that is the swimming lessons your daughter asked about, paid by a five-page site for the bakery down the road. Price the care plan that follows separately, because smaller money arriving every month is what lets you keep saying yes.
Imagine a care plan from a few happy clients arriving every month without new sales calls. That is the gym membership and the phone bill paid, quietly, while you build the next site. Small monthly payments are what turn freelance work into something you can plan your life around.
The two platforms do different jobs, and clients rarely know the difference.
That settles the tooling, and you could build a good site tomorrow. None of it earns a thing until somebody asks you to, and that is the harder half of the job.
Your buyer is specific: a business that needs a real site, has a budget in the low thousands rather than the low tens of thousands, and has no development team.
Small and mid-sized businesses rebuilding an outdated site. The most common job. Their current site is slow, impossible to maintain and embarrassing, and they know it.
Startups and product companies needing a marketing site. They have engineers, and those engineers should be doing other work. This is a strong pitch because it frees expensive people from a job they resent.
Agencies needing overflow help. Design agencies win work they cannot build, and they need someone reliable more often than they need someone cheap. The rate is lower because they hold the client relationship. In exchange you get steady work, a wide variety of briefs, and no sales to do while you are still learning. For most people this is the fastest route to consistent income in this field.
Designers who cannot build. A designer with a client and a Figma file needs someone to build it. This partnership lasts, because they keep winning work.
Businesses whose site cannot be updated without a developer. This is the most reliable pain to sell against, because it costs them money and patience all the time.
Businesses about to launch something. A new product, a new location, a rebrand or a funding announcement creates a need with a date on it and a decision-maker already paying attention. A general "our site is old" conversation can drift for a year. A launch has a date attached and a budget already set aside.
The approach that works best is the same one that works in technical documentation: diagnose before you pitch. Look at a prospect's site, find specific problems, and open with those before you mention your services. Which local business site annoyed you the last time you tried to use it?
Every week you spend learning without pitching is a week another builder sends the message you meant to send. Your portfolio grows faster with real sites than with practice ones. Tonight, write down three local business sites that frustrate you, and draft the first message about one specific fix.
Learning It Well Enough to Charge
You can learn these platforms in weeks and charge for them in months, and the gap between those two is where most people give up.
Learn the concepts underneath the interface. Both platforms are visual layers over HTML and CSS. If you understand the box model, flexbox, grid, inheritance and how responsive breakpoints really work, you will build clean, maintainable sites quickly. If you have only learned which buttons to click, your sites will break in ways you cannot diagnose. This is the single biggest difference between a $50 hour and a $150 hour, and the concepts are free to learn.
Build three real sites before you charge. Tutorials will not teach you what these do. Pick three businesses whose sites are poor, rebuild them properly, and publish them as concept work with a note on what you changed and why. You will hit the real problems: awkward content, missing images, a service list that will not fit the layout.
Rebuild one site three times. Unusual advice, and it works. The first attempt teaches you the interface, the second teaches you structure, and the third teaches you what you would do differently, which is exactly what a client pays for.
Learn the CMS deeply, since it sets you apart. Collections, reference and multi-reference fields, filtering and sorting, dynamic pages. Most people learn the visual editor and stop there, which is why so many portfolio sites look fine and cannot grow.
Learn one integration properly. Connecting forms to a CRM, or payments, or a booking system. This is where real businesses live and where template users get stuck.
Study the handover as closely as the build. Set yourself one test: could a non-technical person add a page without breaking anything? If not, the structure is wrong, however good it looks.
The honest timeline: a few weeks to build competently, a few months to build maintainably, and the second is what people pay for. Could you give this five evenings a week for those few months, or is two more realistic for your life?
Building a Portfolio Without Clients
Every service business has this problem, and here the answer is unusually clean because the work is public and anyone can check it.
Rebuild real businesses, properly. Pick companies with genuinely poor sites in an industry you want to work in. Build a full replacement, with real content taken from their existing site, a working content model and forms that work. Publish it as a concept with a written note on the specific problems you fixed.
Show the structure as well as the screenshots. A portfolio piece explaining how you modelled the content, why case studies reference services, and how their team would add a new one shows the thinking a client cannot see in an image. Almost nobody does this, which is exactly why it works for you.
Pick one industry and rebuild three sites in it. Three professional services firms, or three clinics, or three manufacturers. That reads as a positioning statement, and it lets you say something specific about how businesses in that sector should structure a site.
Send it to the business. Politely, without pressure, framed as something you built for practice. Most will not reply. Some will, and a few of those become your first clients. Keep it factual and about the site, and steer clear of criticising them.
Share templates or components publicly. Both platforms have communities where work is visible. Something genuinely useful and free is a credential that keeps being found.
This works better here than in most fields because a website can be visited. A client can click through your concept build, resize the window, and see for themselves whether it holds up. No claim about your experience can do that for you.
Rookie Mistakes
Selling a website when the client needs an outcome. They want more enquiries, or a shorter sales cycle, or fewer support calls. The site is how they get there. Asking what the site is for changes both the build and the price.
Skipping the content model. Building pages before deciding how content is structured gives you a site that cannot grow. This is the most common cause of a rebuild a year later.
Accepting unlimited revisions. Visual work invites endless small changes. Two rounds, defined, with a stated rate for more.
Starting without content. Building with placeholder text and fitting real content in afterwards gives you layouts that break. Make content a dependency with a date.
Ignoring performance. Visual builders make heavy pages easy. Big unoptimised images and too much animation cost load time, and load time costs your client.
Ignoring accessibility. Often skipped entirely, increasingly a legal question, and a genuine difference in quality. The accessibility auditing guide on this site explains why this is becoming a requirement.
No handover. A client who cannot update their own site will either call you constantly for free or resent you. Documentation and a training session are part of the job.
Competing with template marketplaces on price. They sell a different product to a different buyer. Compete on structure, integration and maintainability.
Running the Project Without Losing Money
So you can win the work. Whether you end the month ahead is decided after the deposit clears, by how you run the project itself.
Site builds go over budget in predictable ways, and you can prevent nearly all of them in the proposal before any work starts.
Make content a dated dependency. The project cannot finish without content, and content is always late. State in writing that the timeline starts when you receive the content, and what happens if it never comes. Without this clause, their delay quietly becomes your problem and eats your margin.
Define a page and a template. Scope by template count rather than page count, because fifty case studies built from one template is one piece of work and five bespoke landing pages is five. Clients naturally think in pages, so translating it for them heads off a big misunderstanding.
Stage the payments. A deposit to start, a payment at design or build approval, and the balance before launch. That last one matters: a site handed over on a promise of payment is a site you no longer control.
Cap revisions and mean it. Two rounds is standard. Bundle feedback into rounds rather than accepting a stream of single changes, because a stream has no end and no natural point where the project is done. Could you say "that falls in round three, which is billed at my day rate" to a client you like?
Get design sign-off before you build. Changing a layout at the design stage takes minutes. Changing it after the components are built and filled takes hours. Make approval a clear gate.
Charge for discovery if it is substantial. Auditing the content on a large existing site is real work. A paid discovery phase that produces a content model and sitemap is easy to defend, and it makes a natural first engagement that lowers the risk of the larger quote for both of you.
Put the launch checklist in the contract. Redirects, analytics, forms tested, favicons, meta tags, sitemap submitted. Naming these turns them into deliverables, so nobody has to assume, and it saves you a launch-day scramble.
There is a moment at the end of a clean launch, redirects tested and sitemap submitted, when a site you built goes live under a client's name with yours in the footer. That quiet pride is yours to keep. Startup costs here top out around 600 dollars, so what you are really building as you go is a trade that belongs to you.
Turning Builds Into a Business
By now each build is a job you can price, deliver and get paid for. What follows decides whether those jobs stack up into something steadier than a queue of one-offs.
Project work has a ceiling set by your hours, and this field has a clear path past it.
Retainers come first. Maintenance, small updates, new pages. Small one by one and steady together, and they attach to clients whose sites you already know, which makes them efficient.
Turn a specific build into a product. A defined site for a defined kind of business, at a fixed price and timeline, using components you have already made. The fifth build for a firm in the same industry takes a fraction of the time of the first, and that margin is yours if you priced the outcome.
Sell templates. Both platforms have marketplaces. A template is a build you sell again and again, and while it rarely becomes big income on its own, it keeps marketing you to exactly the audience that hires builders.
Move up to systems work. Larger organisations need design systems, component libraries and rules so several people can publish without breaking things. That is consulting, and it pays like consulting.
Partner with designers. A designer who wins work and cannot build it is a repeat source of referrals for you, and no threat at all. Two or three relationships like that bring more consistent work than any marketing.
The pattern here is the one that runs through every service on this site: clients buy the first job for the deliverable, and the lasting income comes from the relationship that follows. Building the site is the introduction. Which of your past clients or employers would you most like to be working with again in two years?
Gotchas Worth Knowing
Platform costs belong to the client, and they need explaining. These are subscription platforms with tiers, and a client surprised by an annual hosting bill after launch will blame you. Lay out the costs before you start and have them hold the account.
Client-owned accounts, always. The site should live in the client's account with you invited in. Keeping it in yours invites an ugly conversation when the relationship ends, and client ownership is simply the correct arrangement.
Platform limits are real and hard to work around late. Finding a constraint after you have built most of a site is expensive. Prototype anything unusual before you quote.
Migrations get underestimated. Moving an existing site means content, structure, redirects and keeping search visibility. Redirects in particular get skipped and cost the client traffic they already had.
Platform changes are out of your hands. Pricing, features and behaviour change on the vendor's schedule, sometimes disruptively. A maintenance retainer is partly insurance against this for both of you.
Scope creep arrives as small requests. One more page, one more form, a small change to a collection. Each is minor, and together they eat your margin.
Third-party dependencies age badly. Sites often rely on outside scripts, embedded widgets and integrations the client bought separately. Those services change their APIs, raise prices or shut down, and when something breaks two years later, the client calls you instead of the vendor. Documenting every outside dependency at handover, with what it does and who owns the account, is a ten-minute job that spares you an unpleasant conversation.
State who owns the design work. Whether the client owns the site, the components and any custom assets, and what you may show publicly, is worth a clause. Portfolio rights in particular are far easier to agree before a project than after one.
The Content Model, Explained Properly
This gets its own section because it is the deliverable that decides whether a site lasts or gets rebuilt, and clients neither ask for it nor understand it.
A content model defines what kinds of content exist, what fields each has, and how they relate. A blog post has an author, a date and categories. A case study references the services it shows off and the industry it was for. A team member appears on the team page and also as the author of posts. Get these relationships right and the site grows by adding entries, with no new pages to build.
Model the content over the current pages. The trap is to look at the existing site and recreate its pages. Look instead at what the business actually publishes over time, and design for that.
Ask what they will add in two years. More case studies, certainly. More services, probably. Locations, if they expand. Team members, constantly. Anything they will add again and again should be a collection rather than a hand-built page.
Watch for the thing that shows up in three places. A service that appears on the services page, on the relevant case studies and in the footer navigation should exist once and be referenced from each place. Writing it three times is what makes a site expensive to maintain.
Keep fields specific. One rich text field for everything is easy to build and terrible to maintain, because it lets an editor break the layout. Separate fields for headline, summary, body, image and metadata guide editors helpfully.
Design for the least technical person who will edit it. If adding a case study means knowing which fields to leave blank, the model is wrong. The test is whether someone can add one correctly without asking you.
Here is the commercial case for spending real time on this: a client whose site outlives its rebuild cycle is a client who tells other people. A client rebuilding in eighteen months because the structure could not fit a new service line is a client who blames the builder, usually fairly. Who will be editing your client's site after you leave, and have you ever met them?
Who This Suits
I will be direct, because the right person for this is specific, and it may surprise you.
It suits you if you think in structures more than in pictures. What sets you apart is content modelling, integrations and maintainability, ahead of looks. Designers who dislike systems thinking find the valuable half of the job tedious.
It suits you if you are a designer who wants to deliver the finished thing yourself. If you can design and build, you capture both fees and control the result, which is a genuinely strong position.
It suits you if you are a developer who likes shipping quickly. Building on these platforms is far faster than writing a site from scratch, and for straightforward marketing sites the result is often easier to maintain.
It suits you if you enjoy client work. This is a service business with discovery calls, revisions, chasing content and handover training. If you want to build alone, you will find the real job is mostly communication.
It does not suit you if you want passive income. Each site is a project, and the recurring money comes from maintenance retainers that you have to sell and deliver.
It does not suit you if you will not learn the underlying web concepts. The ceiling for someone who only knows the interface is low, and it shows in their work.
It does not suit you if you cannot say no to extra scope. Visual work invites endless small requests, and a builder who agrees to all of them works for nothing. Be honest with yourself: when a client asks for "one tiny change" at 9pm, what do you usually do?
Behind the Scenes: A Site Build
What it really looks like is a content problem wearing a design costume.
A business gets in touch because their site is four years old, nobody can update it, and the person who built it has left. They want it modernised in six weeks.
Discovery has little to do with visual taste. It is about what the site needs to do, what content exists, who will maintain it and what systems it must connect to. The revealing question is usually who will update this, and the answer is often somebody who has never used a CMS.
Then the content audit, which is where the timeline slips. Their existing site has eighty pages, perhaps thirty worth keeping, and nobody has decided which. That decision is theirs, and it takes two weeks.
Then the content model, the most important document and the one the client cares least about. Case studies relate to services and to industries; blog posts have authors and categories; team members appear in two places. Get this right and they can add a case study in three years without calling anyone.
Then the build, which is the fast part, and the part they imagined was the whole project.
Then real content arrives, and layouts that worked with placeholder text meet a service name four words long and a case study with no image. Every design meets reality here.
Then integrations, which always take longer than expected because the client's CRM was set up by someone who left.
Then redirects from the old site, which nobody asks about and which protect the traffic they already have.
Then handover: documentation, a recorded walkthrough, and a session where someone from their team adds a page while you watch. That session is when the project becomes valuable to them, and it is the one people skip.
The Migration Engagement
Rebuilding an existing site is the most common job in this field and the one most often mispriced, so it deserves separate treatment from a new build.
The content audit is the work. An existing site has pages piled up over years, some valuable, many not, and nobody has decided which. Producing that inventory, with a keep, merge, rewrite or delete decision against each page, is a deliverable in its own right, and the client usually cannot do it themselves. Price it separately.
Redirects are compulsory. Every URL that changes needs a redirect from the old address to the new one, or the client loses the search visibility and inbound links they already had. This is invisible work protecting something they own, cheap builders skip it routinely, and its absence shows up as a traffic drop six weeks after launch that nobody links to the rebuild.
Protect what is working before you improve what is broken. Find out which pages actually bring traffic and enquiries before you restructure. Rebuilding a site around a nicer structure while quietly breaking the two pages that bring in all the leads is a real and common outcome.
Expect the old site to be undocumented. Forms sending enquiries somewhere nobody remembers, integrations set up by a contractor who left, a domain registered to a personal email. Budget discovery time for digging.
Launch carefully and quietly. Test forms, check analytics is recording, confirm redirects work, and submit the new sitemap. A launch checklist agreed in the contract turns this from a panic into a process.
Migrations pay better than new builds when you scope them honestly, because the work is larger and the risk to the client is higher. They lose you money when quoted as new builds that happen to have existing text.
Migrations and retainers are where the top of this range lives. If you held something close to 10,000 a month for most of a year, and what remained after costs could cover your salary by itself, the conversation with your manager would change. What would you say in that conversation? Few builders get there, and those who do mostly started with one migration quoted honestly, content audit included.
Where This Goes Next
Four judgements about direction. They are inference from what the platforms and the tooling are already doing, and none of them carries a date.
Generation takes over the first draft. Producing an initial layout from a prompt is already routine and will improve. Structuring content properly, connecting a business's systems and handing over something maintainable is a separate activity, and it is the one clients pay for after their second rebuild.
The template floor rises and the gap stays. Templates keep improving, which raises the minimum acceptable site and shrinks the bottom of the market. The businesses that need something specific and maintainable are still there, and they still cannot serve themselves.
Content operations set the best builders apart. As sites grow, the question shifts from how it looks to whether the marketing team can run it. Specialists who build for that day-to-day reality will beat those who build for launch day.
Accessibility moves from optional to expected. Regulatory pressure is real and growing, and sites built visually are often poor here. Building accessibly by default is a genuine advantage that costs you little to learn.
The platforms themselves add AI, which helps you more than it threatens you. Both are building generation and assistance into the editor. That speeds up the parts you were already fast at and leaves content modelling, integrations and knowing what the business needs untouched. If you adopt those features, you deliver faster at the same project price, so your margin grows. The threat falls on people selling hours, and the benefit goes to people selling outcomes, which is one more reason to price by the project.
Client expectations rise faster than budgets. Because impressive sites are more visible and easier to make, clients arrive expecting more for the same money. Your defence is scoping precisely, so you never quietly absorb the extra, and being able to explain what the extra cost buys.
Specialising by industry beats specialising by platform. Knowing Webflow deeply is table stakes. Knowing how professional services firms, or clinics, or manufacturers actually use a website, and what their content model needs to look like, is what lets you quote confidently and finish quickly. Which industry do you already understand from the inside?
Every industry gets its go-to builder eventually. Clinics, law firms, local restaurants: someone becomes the person they all call. The builders who pick a niche now and build a few good sites in it will own those referrals. Waiting means arriving when that name is already somebody else's.