Typical Project Investment
What working with FLOWLINE costs — before we ask you to get on a call.
The figures below are typical ranges, not packages. No two specialized service businesses have the same website, search footprint, content, service structure or existing equity, so we don’t price them as though the work is identical.
You should be able to understand the likely scale of an engagement before you contact us.
Typical investment by service.
Four ways of working, each scoped to what the research says a business actually needs. They are not tiers of the same thing, and a bigger number is not a better outcome — the right engagement is the one that matches the problem.
Ranges reflect genuine differences in the work involved. What moves a project within its range is explained further down this page.
Website Foundation
Typical timeframe: 1–3 weeks
For businesses that need the research, architecture and priorities established before major changes are made. Sometimes the honest finding is that a rebuild isn’t what the site needs.
Full Website Rebuild
Typical timeframe: 4–10 weeks
For businesses whose website requires substantial restructuring, content work, design and development, search-equity preservation and implementation. The “+” is there because unusually large, technically complex or migration-heavy websites can exceed the typical range.
Website Maintenance & Ongoing Support
Ongoing
Monthly scope varies with how actively the site needs to be maintained and improved — monitoring, safe change management, technical health, and considered improvement as the business moves. This is not a plugin-update service.
Social Media Upkeep & Content Support
Ongoing
Scope varies with content frequency, planning, writing, graphics, repurposing, scheduling and how much ongoing support the business needs. What we’re capturing is the work you already do.
Sometimes the right answer is something smaller.
If a full rebuild or an ongoing engagement isn’t what a business needs, we may recommend a smaller, focused piece of work instead — a specific correction, one part of the structure, a single question answered properly.
The goal isn’t to move every business into the largest engagement. Focused or unusual work is scoped separately, and we’ll tell you what it involves before you commit to it.
What changes the scope?
Two businesses can ask for the same thing — “we need our website rebuilt” — and need very different amounts of work. The difference is almost never the size of the company. It’s the condition and complexity of what already exists.
Scope is tied to the actual work involved. A larger business is not charged more for being larger.
What’s there now, and how much of it is sound.
Each real service is something the site has to explain properly.
Genuine markets the business actually serves — not invented location pages.
Good material gets kept and reworked. Thin material has to be written.
Often the single largest variable in a rebuild.
Search equity — the visibility a site has already earned — has to be carried across deliberately, not left behind.
Platform, hosting and redirect work varies enormously between sites.
How pages connect is structural work, not decoration.
Anything the site has to talk to adds build and testing time.
What needs measuring, and whether it currently measures anything.
Anything beyond pages and forms is scoped on its own terms.
How much has to be understood before a recommendation is defensible.
How many people need to agree, and how review will work.
A rebuild isn’t priced by page count.
It would be simpler to say five pages costs one number, ten costs another and twenty costs a third. We don’t, because page count doesn’t describe the work.
A small site can carry difficult migration, preservation or technical requirements that take longer than a large one. A large site often already contains valuable material that should be kept rather than rewritten — which is work saved, not work added.
So the project gets scoped around the actual system: what’s there, what has to be protected, what genuinely needs building, and what should simply be left alone.
Typical timelines.
These are estimates based on comparable work, not guarantees, and we don’t publish launch dates on a pricing page — a date is something a proposal commits to once the scope is known.
1–3 weeks
4–10 weeks
Ongoing
Ongoing
What moves a timeline
Some sites take longer to understand than to rebuild.
Hosting, domain, analytics and platform access being available when needed.
Details only the business has — services, areas, specifics.
How quickly decisions can be made and confirmed.
Whether the material exists yet or has to be produced.
Redirects, platform moves and preservation work.
Anything custom is scoped and built on its own timeline.
New requirements mid-project move the finish line honestly.
Projects move fastest when the required access, information and feedback are available roughly as planned. Where something isn’t ready, we’d rather adjust the schedule openly than quietly miss a date.
No surprise scope.
A pricing page can only give you ranges. A proposal is where the actual number lives, and it should leave nothing for you to guess at. Before paid work starts, a FLOWLINE proposal should make all of this clear:
Described in terms you can hold us to.
Specifically, not by implication.
The more useful half of the list.
One number, or a defined monthly arrangement.
What the schedule looks like and what it depends on.
When payments fall, agreed before work starts.
The access, information and decisions the work depends on.
Where it applies, priced separately and clearly marked optional.
If something significant comes up that sits outside the agreed project, the right thing is to discuss it before it becomes additional paid work — not to discover it on an invoice.
How payment is structured.
Project engagements are divided into scheduled payments across the life of the project rather than charged as a single lump sum. Ongoing support and content work are billed on a recurring monthly basis.
We don’t work from an hourly rate. Hourly billing makes the cost of a project unknowable until it’s finished, which is the opposite of what this page is for.
Your proposal will show the total cost and the payment schedule before any work begins.
Third-party costs.
Some costs belong to the business rather than to the project, and they vary — many projects involve none of these. Where any of them do apply, we’ll identify them in the proposal rather than leaving them to appear later:
Where the site actually lives.
The domain name itself, renewed on its own cycle.
A paid plugin or licence, only where one is genuinely needed.
Ad spend is never part of a build or support price.
Third-party systems that charge their own fees.
Where real photography is the right answer.
Services the business runs and keeps.
Where it’s practical, we think business-critical accounts — hosting, domain, analytics — are better held in the client’s own name and access structure than solely inside accounts we control. It costs nothing to set up that way, and it matters later.
Your website should stay a usable business asset.
Some website work is built so that it only functions while you keep paying the company that built it. That isn’t how we want to work. Our implementation shouldn’t depend on keeping you inside an opaque proprietary system you can’t see into or move out of.
Accounts, access and ongoing responsibilities should be clear on both sides — who holds what, what renews, and what happens next. We’ll set that out rather than leave it vague.
A website should keep working as a business asset whether or not you continue with ongoing support. If you decide to stop, the aim is a clean handover, not a hostage situation.
What we don’t do with pricing.
Four commitments, stated plainly so you can hold us to them.
If the site needs a focused correction, that’s what we’ll say.
Page count is an output of the research, never an input to the price.
That’s the entire reason this page exists.
Anything significant gets raised before it becomes billable.
We investigate before recommending changes.
We identify what should stay intact before rebuilding.
Recommendations are grounded in actual website and technical work.
Performance, accessibility and search health matter alongside design.
The people researching the business shape the recommendation.
We publish the thinking behind the work.
Not sure what you need?
You don’t need to work out whether this is a Foundation, a rebuild or ongoing support before you get in touch. Working that out is our job, and it’s the part we’d do first anyway.
Show us the website. If it only needs a focused correction, we’ll tell you that. If it needs deeper structural work, we’ll explain why we think so — and what it would involve.