There is a gap in the website market that neither end serves well, and it is where this business lives.
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 costs tens of thousands with a timeline to match. Between them sits a large number of businesses that need something genuinely designed, genuinely theirs, and genuinely maintainable by their own staff afterwards, without a development team.
That middle is larger than it sounds and it is unusually stable. A business with fifteen employees and a real marketing function 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 disproportionate to a marketing site and the resulting thing needs a developer every time a page changes. They have been stuck between those options for as long as the web has existed, and visual development platforms are the first tooling that genuinely serves them: designed like a custom site, editable like a template. The business opportunity is not the platform, which anyone can learn. It is that this segment has money, recurring need, and no good alternative.
Visual development platforms serve that gap, and the rates reflect 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.
Worth addressing directly, because a tool that generates websites from a prompt is an obvious threat to a business built on building websites.
Generation is genuinely good at producing something that looks like a website. What it is poor at is 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 layout, forms that route to the right place, integrations with the systems they already use, performance under real content rather than placeholder text, and behaviour at every breakpoint with the awkward content they actually have.
The distinction matters because it is the same one running through the graphic design guide on this site. Visual output got cheap. Implementation that survives contact with a real business did not.
Three parts of this work are durable for that reason.
Less design than people assume, and less coding than the title suggests.
The hourly bands are published and the project approach is better.
Price the project rather than the hour, for the reason that recurs across every service guide on this site: your speed improves substantially with reusable components and experience, and hourly billing converts 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 define what happens when content arrives late. The last one matters more here than in most work, because a site cannot be finished without content and content is always the bottleneck.
Three revenue lines beyond the build are worth structuring from the start.
They are not interchangeable and clients rarely know the difference.
The buyer is specific: a business that needs a real site, has budget in the low thousands rather than the low tens of thousands, and has no development team.
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 continuously.
Businesses about to launch something. A new product, a new location, a rebrand or a funding announcement creates a dated need with a decision-maker already engaged. Unlike a general "our site is old" conversation, which can drift for a year, a launch has a date attached and a budget already allocated to it.
The most effective approach is the same one that works in technical documentation: diagnose before pitching. Look at a prospect's site, identify specific problems, and open with those rather than with your services.
Learning It Well Enough to Charge
The platforms are learnable in weeks and chargeable in months, and the gap between those two is where most people give up.
Learn the underlying concepts, not the interface. Both platforms are visual layers over HTML and CSS. Someone who understands the box model, flexbox, grid, inheritance and how responsive breakpoints actually work builds clean, maintainable sites quickly. Someone who has only learned which buttons to click builds sites that break in ways they cannot diagnose. This is the single largest difference between a $50 hour and a $150 hour, and the concepts are free to learn.
Build three real sites before charging. Not tutorials. 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 actual problems: awkward content, missing images, a service list that does not fit the layout.
Rebuild one site three times. Unusual advice and it works. The first attempt teaches the interface, the second teaches structure, the third teaches you what you would do differently, which is what a client is paying for.
Learn the CMS deeply, since it is the differentiator. Collections, reference and multi-reference fields, filtering and sorting, dynamic pages. Most people learn the visual editor and stop, 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, not just the build. Set yourself the test of whether a non-technical person could add a page without breaking anything. If not, the structure is wrong, whatever it looks like.
The honest timeline: a few weeks to build competently, a few months to build maintainably, and the second is the one worth paying for.
Building a Portfolio Without Clients
The same problem every service business has, with an unusually clean solution here because the work is public and verifiable.
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 functioning forms. Publish it as a concept with a written note on the specific problems you fixed.
Show the structure, not only the screenshots. A portfolio piece explaining how you modelled content, why case studies reference services, and how their team would add a new one, demonstrates the thinking clients cannot see in an image. Almost nobody does this, which is exactly why it works.
Pick one industry and rebuild three sites in it. Three professional services firms, or three clinics, or three manufacturers. That is a positioning statement rather than a portfolio, 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 to practise. Most will not reply. Some will, and a few of those become first clients. Keep it factual and about the site rather than critical of them.
Contribute templates or components publicly. Both platforms have ecosystems where work is visible. Something genuinely useful and free is a credential that stays findable.
The reason this works better than in most fields is that a website can be visited. A client can click through your concept build, resize the window, and see for themselves whether it holds up, which no claim about your experience can substitute for.
Rookie Mistakes
Selling a website when the client needs an outcome. They want more enquiries, or a shorter sales cycle, or fewer support calls. A site is the means. 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 produces a site that cannot grow. This is the most common source of rebuilds 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 afterwards produces layouts that break. Make content a dependency with a date.
Ignoring performance. Visual builders make it easy to produce heavy pages. Large unoptimised images and excessive animation cost load time, and load time costs the client.
Ignoring accessibility. Frequently skipped entirely, increasingly a legal question, and a genuine quality difference. The accessibility auditing guide on this site covers why this is becoming a requirement rather than a nicety.
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. A different product for a different buyer. Compete on structure, integration and maintainability.
Running the Project Without Losing Money
Site builds go over budget in predictable ways, and nearly all of them are preventable in the proposal rather than during the work.
Make content a dated dependency. The project cannot finish without content and content is always late. State in writing that the timeline starts when content is received, and what happens if it is not. Without this clause, their delay silently becomes your problem and 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 explicitly prevents a large misunderstanding.
Stage the payments. A deposit to start, a payment at design or build approval, and the balance before launch. The balance before launch 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 individual changes, because a stream has no end and no natural point at which the project is finished.
Get design sign-off before building. Changing a layout in the design stage is minutes; changing it after the components are built and populated is hours. Make approval an explicit gate.
Charge for the discovery if it is substantial. Content audits on a large existing site are real work. A paid discovery phase that produces a content model and sitemap is both defensible and a natural first engagement that de-risks the larger quote for both sides.
Put the launch checklist in the contract. Redirects, analytics, forms tested, favicons, meta tags, sitemap submitted. Naming these makes them deliverables rather than assumptions, and it prevents a launch-day scramble.
Turning Builds Into a Business
Project work has a ceiling set by your hours, and this field has a clear path past it.
Retainers are the first step. Maintenance, small updates, new pages. Modest individually and steady collectively, and they attach to clients whose sites you already know, which makes them efficient.
Productise a specific build. A defined site for a defined kind of business, at a fixed price and timeline, using components you have already made. Repeating the same build for the fifth firm in an 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 repeatedly, and while it rarely becomes substantial income alone, it markets you continuously to exactly the audience that hires builders.
Move up to systems work. Larger organisations need design systems, component libraries and governance rules so multiple people can publish without breaking things. That is consulting rather than building, and it pays accordingly.
Partner with designers rather than competing with them. A designer who wins work and cannot implement is a repeat referral source, not a rival. Two or three such relationships produce more consistent work than any marketing.
The pattern here is the same one that recurs across every service on this site: the first engagement is bought on the deliverable, and the durable income comes from the relationship that follows it. Building the site is the introduction.
Gotchas Worth Knowing
Platform costs are the client's, and they need explaining. These are subscription platforms with tiers, and a client surprised by an annual hosting bill after launch will blame you. Set out the costs before starting and have them hold the account.
Client-owned accounts, always. The site should live in the client's account with you invited, not in yours. It avoids an ugly conversation at the end of the relationship and it is simply the correct arrangement.
Platform limitations are real and hard to work around late. Discovering a constraint after building most of a site is expensive. Prototype anything unusual before quoting.
Migrations are underestimated. Moving an existing site means content, structure, redirects and preserving search visibility. Redirects in particular get skipped and cost the client traffic they had.
Platform changes are outside your control. Pricing, features and behaviour change on the vendor's schedule, sometimes disruptively. A maintenance retainer is partly insurance against this for both sides.
Scope creep arrives as small requests. One more page, one more form, a small change to a collection. Each is minor and collectively they consume the margin.
Third-party dependencies age badly. Sites frequently rely on external scripts, embedded widgets and integrations that 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 rather than the vendor. Documenting every external dependency at handover, with what it does and who owns the account, is a ten-minute job that prevents an unpleasant conversation.
Ownership of the design work should be stated. 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 much easier to agree before a project than after one.
The Content Model, Explained Properly
This deserves its own section because it is the deliverable that separates a site that lasts from one that gets rebuilt, and it is the thing clients neither ask for nor understand.
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 demonstrates and the industry it was for. A team member appears on the team page and also as the author of posts. Getting these relationships right means the site can grow by adding entries rather than by adding pages.
Model the content, not the current pages. The mistake 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, continually. Anything they will add repeatedly should be a collection rather than a hand-built page.
Watch for the thing that appears in three places. A service that shows on the services page, on relevant case studies and in the footer navigation should exist once and be referenced, not be written three times. Duplication is what makes a site expensive to maintain.
Keep fields specific. A single 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 constrain them helpfully.
Design for the least technical person who will edit it. If adding a case study requires knowing which fields to leave blank, the model is wrong. The test is whether someone can add one correctly without asking.
The commercial argument for spending real time here: 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 accommodate a new service line is a client who blames the builder, usually fairly.
Who This Suits
Direct, because the skill profile is specific and not the obvious one.
It suits people who are structurally minded rather than purely visual. The differentiator is content modelling, integrations and maintainability, not aesthetics. Designers who dislike systems thinking find the valuable half of the job tedious.
It suits designers who want to deliver rather than hand off. Someone who can design and build captures both fees and controls the outcome, which is a genuinely strong position.
It suits developers who like shipping quickly. Building in these platforms is far faster than writing a site from scratch, and for straightforward marketing sites the result is often better maintained.
It suits people who enjoy client work. This is a service business with discovery calls, revisions, content chasing and handover training. Anyone who wants to build in isolation will find the actual job is mostly communication.
It does not suit people who want passive income. Each site is a project, and the recurring revenue comes from maintenance retainers that must be sold and delivered.
It does not suit anyone unwilling to learn the underlying web concepts. The ceiling for someone who only knows the interface is low and visible in their work.
It does not suit anyone who cannot say no to scope. Visual work invites endless small requests, and a builder who accommodates all of them works for nothing.
Behind the Scenes: A Site Build
The realistic version 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 is gone. They want it modernised in six weeks.
Discovery is not about visual preferences. 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 of which are worth keeping, and nobody has decided which. That decision is theirs and it takes two weeks.
Then the content model, which is 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. Getting this right means 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 the whole project was.
Then real content arrives, and layouts that worked with placeholder text meet a service name that is 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 configured by someone who left.
Then redirects from the old site, which nobody asks about and which protects 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 is worth treating separately from a new build.
The content audit is the work. An existing site has pages accumulated 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 is usually incapable of doing it themselves. Price it separately.
Redirects are not optional. 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 that protects something they own, it is routinely skipped by cheap builders, and its absence shows up as a traffic drop six weeks after launch that nobody connects to the rebuild.
Preserve what is working before improving what is not. Find out which pages actually bring traffic and enquiries before restructuring. Rebuilding a site around a nicer structure while quietly breaking the two pages that generate all the leads is a real and common outcome.
Expect the old site to be undocumented. Forms routing somewhere nobody remembers, integrations set up by a departed contractor, a domain registered to a personal email. Budget discovery time for archaeology.
Launch carefully rather than dramatically. Test forms, check analytics is recording, verify redirects resolve, 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 scoped honestly, because the work is larger and the risk to the client is higher. They lose money when quoted as though they were new builds with existing text.
Where This Goes Next
Four judgements about direction. They are inference from what the platforms and the tooling are already doing rather than forecasts with dates.
Generation absorbs the first draft, not the build. Producing an initial layout from a prompt is already routine and will improve. Structuring content properly, integrating with a business's systems and handing over something maintainable is a different activity, and it is the one clients pay for after their second rebuild.
The template floor rises and the gap remains. Templates keep getting better, which raises the minimum acceptable site and shrinks the bottom of the market. The businesses needing something specific and maintainable remain, and they remain unable to serve themselves.
Content operations become the differentiator. As sites grow, the question stops being how it looks and becomes whether the marketing team can run it. Specialists who build for that operational reality will outcompete those who build for launch day.
Accessibility moves from optional to expected. Regulatory pressure is real and increasing, and sites built visually are frequently poor here. Building accessibly by default is a genuine advantage that costs little to acquire.
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 does nothing about content modelling, integrations or knowing what the business needs. A builder who adopts those features delivers faster at the same project price, which improves margin rather than eroding it. The threat is to people selling hours; the benefit accrues to people selling outcomes, which is another reason to price projects.
Client expectations rise faster than budgets. Because impressive sites are more visible and easier to produce, clients arrive expecting more for the same money. The defence is scoping precisely rather than absorbing it, and being able to explain what the extra cost buys.
Specialisation by industry beats specialisation 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.