A Web Design Company That Hand-Codes Every Site Web Design Company for Businesses That Want to Rank

Why a web design company should not be selling you a page builder

A page builder is a program that writes your website’s code for you, and the code it writes is the problem.

Watch what happens when a designer drags a two-column section onto a page in Elementor or Divi. The builder does not emit two columns.

It emits a wrapper, inside a container, inside a section, inside a row, inside a column, inside an inner wrapper, each with a generated class name and an inline style block, because the builder cannot know what you will do next and has to leave itself room for every possibility.

A heading and a paragraph that should be nine lines of HTML become sixty – and that is before anybody has styled anything.

Multiply that across a page and the browser is now parsing a document several times larger than the content in it, and it has to lay all of it out before anybody sees a word. Every element costs time.

Then there is the payload. Because the builder cannot know which of its features a given page uses, it loads most of them everywhere.

The animation library, the icon font, the popup script, the carousel, the accordion, the form handler, jQuery to hold it together, and the builder’s own stylesheet covering every module it ships whether or not that page has one.

A brochure page with a headline and three paragraphs will happily ship several hundred kilobytes of JavaScript that does nothing at all on that page. On a laptop on office wifi you will not notice.

On a phone with two bars on Highway 12 between Walla Walla and the Tri-Cities you will notice a great deal, and so will Google. Core Web Vitals are measured on real visits from real devices rather than in the room where the site was approved.

Real phones, real signal.

The third part is the one that costs the most and shows up last. The builder’s output is not portable.

Your content lives inside its shortcodes and its own database tables, so the day you want to leave, the pages do not come with you as content; they come as a wall of markup that only that plugin can read. That is the reason a five-year-old builder site cannot be redesigned, only rebuilt.

Rebuilt, not rescued.

None of this means the people using page builders are bad at their jobs. The tool is genuinely fast and it lets a designer ship without a developer, which is a real economic advantage for the agency selling it.

The costs just land somewhere else – on your load time, on your rankings, and on whoever has to touch the site in year four.

What a website design company should hand you at the end

At the end of a project you should be holding a website, not a subscription.

What we hand over is the theme code, the content in the database in a form anybody can read, the domain, the hosting, the analytics and the Search Console property, all of it in accounts with your name on them. Clients own their code, content and data outright.

That sentence is easy to write and most of the industry does not mean it, because the site is built inside a proprietary builder, the forms live in a third-party service the agency owns the seat for, and the analytics property was created under the agency’s Google account in 2019 by somebody who no longer works there.

The test is simple and you should run it on whoever you hire – including us. Ask what happens if you fire them next Tuesday.

A good answer is a list of logins and an offer to help with the handover. A bad answer involves the phrase “we’d have to look into that”, which means the site is a rental and nobody told you.

That happens constantly.

A custom block theme passes this test almost by accident. The content is in WordPress posts and pages the way WordPress intended, so it exports and imports like content.

The design lives in a theme, which is a folder of files any competent developer can open, read and change. Nothing in that arrangement requires us specifically, and it is worth being honest about the commercial consequence: it means we have to keep earning the relationship rather than holding the site hostage to keep it.

Templates, and the reason the cheap site costs more

The other way to get a website cheaply is to buy a theme off a marketplace and pour your content into it, and it fails differently than the builder does.

A marketplace theme is built to demo well for every possible buyer, which means it ships a restaurant layout, a gym layout, a law firm layout and eleven homepage variants, all of it in one codebase, all of it loading. It usually bundles a page builder as well – so you get both problems.

It ships with a demo import that installs six plugins you did not ask for, and it hands you a settings panel with four hundred options because the theme author had to anticipate everyone. You will use a sliver of it.

You will carry all of it on every page load.

The deeper cost is that the site now looks like the template, which costs you money rather than dignity. The layout was designed before anybody knew what your business does, so your content gets bent to fit boxes drawn for a hypothetical company.

The parts of your business that are genuinely unusual get quietly dropped, because there is no box for them. So they vanish.

The tasting room hours, the equipment list, the insurance you take, the six-step process that is the actual reason people hire you.

Competent and forgettable is worse than ugly. Ugly gets noticed and fixed; forgettable just sits there costing you the difference between the inquiries you get and the ones you should have.

Custom WordPress development, and when it is the wrong call

We build on WordPress for almost everything, and there are businesses we send elsewhere.

Custom WordPress development means the site is built the way WordPress is designed to be built: a block theme, native editor blocks, custom post types where the business has real structured content, and PHP written for this site rather than configured in somebody’s options panel.

The practical result for you is that editing is the normal WordPress editor with no separate builder to learn, and the practical result for the site is that a page ships the CSS it uses and almost no JavaScript. Where a plugin is genuinely the right answer we use one.

Where a plugin exists to do something forty lines of code would do, we write the forty lines, because every plugin is code executing on every page load and a door somebody has to remember to lock. Fewer doors.

When it is the wrong call: if the store is the entire business, the catalog is large and volatile, there is real fulfillment volume behind it and nobody on your side wants to think about hosting or updates again, Shopify is very likely the better answer and we will say so out loud even though it is the smaller project for us.

That comparison is worked through properly on the ecommerce website design page, honestly, including what Shopify costs you in control and fees.

Website redesign, when there is already a site to protect

A redesign is a migration with a design project attached, and getting that order the wrong way round is why so many of them go quiet afterward.

So the work runs in a fixed order, and the first three steps happen before anybody opens a design tool.

Step one is the inventory. Every URL on the current site goes into one sheet with twelve months of traffic beside it – the terms it ranks for, and the links pointing at it from elsewhere.

Step two sorts that sheet into three piles: pages that pay and must arrive on the other side intact, pages worth rewriting rather than deleting, and pages nobody has opened in a year. Step three is the decision the sheet usually forces on you, which is whether you need a redesign at all.

A site that ranks, converts and loads quickly but looks dated is a restyling job and it is cheaper. A site that is slow, thin and built on a page builder needs rebuilding no matter how it looks.

The inventory is worth doing even if you never redesign, and it is reliably uncomfortable. There is usually one page nobody remembers writing, on a subject nobody thinks of as the business, bringing in a quarter of the organic traffic.

Deleting that page because it did not fit the new navigation is the most expensive thing a redesign can do, and it gets done cheerfully, in a meeting, by people trying to simplify.

Step four is addresses. When a page moves, somebody has to tell Google where it went, one page at a time, having looked at both ends.

The failure here is rarely forgetting; it is doing it in bulk. Pointing every old article at the new blog index avoids an error page and throws the article away.

A redirect to something unrelated reads as a dead end and gets dropped. Step five verifies the whole map after go-live rather than assuming it, and that is the step separating a redesign that held from one about to teach somebody a lesson.

Reverse the order and the story is the same every time. A business has had the same site for seven years and has come to dislike the look of it.

They have quietly stopped sending people the URL. Nobody has ever audited what that unloved site is doing for the business.

It gets replaced, the new one is genuinely better looking, and a season later the owner is asking why the phone sounds different. Something the old site was doing did not survive the move, and nobody had written down what it was.

Website maintenance services, and the part nobody sells honestly

Every website has a running cost. The only question is whether it shows up as an invoice or as a bad week.

What you are buying is the difference between finding out on a Tuesday and finding out from a customer. A contact form that stopped delivering because a mail provider changed a rule does not go down; it goes quiet, and every dashboard reports the site as perfectly healthy the entire time.

The same is true of a card type that silently stopped being accepted, or a plugin generating four hundred nonsense URLs that Search Console has been complaining about since March. None of those trip a monitor.

All of them cost money for as long as nobody looks. The question to put to whoever currently holds the contract is whether anybody has ever restored a backup, rather than whether backups exist, because we have opened enough inherited backups to be unromantic about the subject.

Updates are where the honest disagreement lives, and both of the popular answers are wrong. Never updating is how sites get broken into, and almost every compromised WordPress site we have been handed was running a plugin whose hole had been public, and fixed, for months.

Updating everything the moment it appears is how the booking form stops submitting on a Thursday. The dull version is the correct one: updates land on a staging copy first, a person clicks the things that make you money, and then the same set goes to production behind a fresh backup.

Then there is drift, which is why we treat maintenance as a design responsibility rather than a support desk. A chat widget nobody answers, a font used on a single page in 2022, a plugin installed to solve a problem that stopped existing.

Every addition is defensible by itself – and the sum of them is a site that loads noticeably slower than it did at launch. Somebody has to be responsible for taking things back out.

Ecommerce website design, when the site has to take money

Somebody in Milton-Freewater puts two bottles in a cart at nine at night, reaches the shipping step, sees a number nobody warned them about, and closes the tab.

A store records that. A brochure site never would.

It can be wrong for years and nobody finds out, because there is no number on it, the owner likes it, and the people who would have complained simply left without saying anything. Attach a checkout and you have changed what kind of project it is, because now the site argues back.

A store publishes a verdict every day: this many sessions, this many carts started, this many finished, this much money. That is uncomfortable, and it is the best thing about the work, because it ends the arguments about taste that stall every other kind of project.

Nobody has to win the debate about the product photograph. You run it for two weeks instead.

The structural consequence is that a store is built out of templates rather than pages. However big the catalog, there are about five real screens in it: the category listing, the product page, the cart, the checkout and the account area.

Everything else is one of those five with different data poured into it. So the work concentrates in a very small number of files.

An hour spent on the product template is worth more than a week spent on the homepage – which takes a far smaller share of the traffic than anybody believes before they go and look.

The platform question comes ahead of all of it and gets answered badly more often than anything else in this trade. Usually because whoever is answering only builds one of the two.

Shopify sells you a boundary. WooCommerce sells you a building.

Shopify runs the servers, the compliance and the checkout, and you work inside what they permit, which is plenty until the day it is not. WooCommerce turns WordPress into a store, so the URLs, the templates and the content structure are yours, you host it, and nothing stops you doing something unwise.

Neither is better. They are two different sets of problems and the real decision is which set you would rather own.

The rough test is whether content is doing the selling. A shop that grows through search, long product education and a site that is half publication belongs on WordPress.

A shop that grows through paid acquisition into a large, fast-moving catalog with a warehouse behind it belongs on Shopify. We say so even though it is the smaller project for us.

Then the parts that never appear in a mockup, which is where stores actually go wrong. Filter navigation quietly generating thousands of crawlable URLs.

Product feeds. Category pages written for the words people search, which are category words far more often than product names.

And a checkout somebody has put a real card through, and pulled a real refund back through, before launch rather than after.

Web design in Walla Walla and the Tri-Cities

We are a local shop before we are anything else, and we work with clients across the Walla Walla Valley and the Tri-Cities, and with clients nowhere near either.

Being here changes the brief in ways that are hard to fake from a distance. A tasting room’s traffic has a shape that follows release weekends and harvest.

A contractor’s phone rings when it snows. A business on the Walla Walla side that also wants work in Kennewick, Richland and Pasco has a structure problem before it has a design problem.

One page trying to rank in two markets tends to rank in neither. And the connection question is not theoretical out here; a customer looking you up from a truck outside Dayton is on a phone signal that punishes a heavy page far harder than office wifi ever will.

Weight is not abstract here.

One business, two markets, is the structural question that comes up most often around here. A shop in Walla Walla that also wants work in Kennewick or Richland cannot solve it by adding city names to the footer, and it cannot solve it by writing the same page twice with the nouns swapped.

It needs a page per market with something genuinely different on each, which usually means different work shown, different questions answered and a different reason to be trusted there. That decision belongs in the sitemap in week one, not in an SEO conversation eight months after launch.

Some of the work is not local at all, and we say that plainly rather than pretending to be a purely regional shop. Distance does not change the build.

It changes how often we can usefully be in a room, which matters at the start of a project and much less after that.

The local page carries what belongs there: who we build for around here, the map pack and how local search actually works in a small market. It also carries what a website costs in this valley, and the WordPress and Shopify question answered for businesses of this size.

It is live now. Start with Walla Walla web design if you are in the Valley or the Tri-Cities, and treat this page as the general version of the same argument.

Where SEO fits, and why it is not a phase at the end

Search is a structural decision and it gets made in week one, whether or not anybody says the word.

The URL structure, the heading hierarchy, how many pages the site has and what each one is for, which pages link to which – all of that is decided during design and all of it is search work.

A site with one page called Services that lists nine services has made a choice that caps what it can ever rank for, and no amount of optimization afterward gets around it.

That is why our builds come out as a hub and spoke structure by default: a parent page that covers a subject properly and child pages that go deep on the parts of it people actually search for. This page is one of them, which you are welcome to hold against us.

Fair enough.

What a build gets as standard is the floor rather than a campaign. One H1 per page and headings that do not skip levels, semantic HTML, schema that validates, images in modern formats at the size they display, no render-blocking third-party scripts in the head, and Core Web Vitals measured on a phone.

Accessibility to WCAG AA comes with that rather than as an add-on, because the structure a screen reader needs and the structure a crawler needs are the same structure.

Everything past the floor is ongoing work and it is priced separately, because pretending otherwise is how agencies sell a build and then explain six months later why the phone is not ringing.

That work lives on small business SEO, and the two industries we do the most of it in have their own pages: marketing for dentists and wine marketing.

SEO takes three to six months to become visible and nine to twelve to be worth what you paid, and anybody who tells you faster is selling something.

What a website costs

The low end is a site of roughly eight to twelve pages on a custom block theme built to a brand you already have, with content you supply and tighten with us.

The middle is where most projects land: fifteen to twenty-five pages, copy written or heavily rewritten, photography direction, a few custom post types where the business has structured content like staff, locations or a menu, and forms wired into something that actually notifies a person.

The high end is thirty pages or more, a new visual identity applied across the site, booking or membership integration, and migration off a platform that fights you on the way out.

Every number includes the things we will not sell as upgrades: the structure and keyword work in week one, semantic markup and heading hierarchy, schema, image handling, accessibility, the pre-launch checklist and the launch itself.

What sits outside a build price and gets quoted separately is photography, copywriting at volume, and any ongoing marketing after the site is live. A build is a build.

Pretending it is also a marketing campaign is how a project ends with everybody disappointed.

The rest of the numbers, so every page on this site agrees with this one:

Below about four thousand dollars nobody is hand-coding anything, and the hours are why. A custom build is somewhere between sixty and a hundred and fifty hours of work depending on the size of it, so a two-thousand-dollar site is a purchased template with your logo dropped into it.

That is a legitimate thing to buy when the budget is the budget. It is just worth knowing which one you are buying.

Ask which one it is.

How we work, and what a web design agency owes you week by week

The week-by-week is the part most agencies keep vague, and vagueness is where projects go to die.

Week one is discovery and structure. What the business sells, who buys it, what the money actually comes from, and then the sitemap – which is the single most important document in the project and the one clients are most often not shown.

If there is an existing site, this is also when it gets crawled and inventoried. Week two is content mapping, keyword work against the sitemap, and the decision about what each page is for before anybody opens a design tool.

Weeks three and four are design, and we design templates rather than screens: the homepage, one interior page, one service page, and whatever else is structurally different. Every other page is a composition of parts that already exist.

That is why we harvest components once and reuse them rather than redrawing a card three ways. You approve rendered pages in a browser on a real phone, not flat images, because a picture of a website is not a website.

Weeks five through the end are build on staging, with content going in as it is approved. Staging is open to you and closed to search engines.

You review it with real content in it, because a site reviewed with placeholder text is a site nobody has actually read. We would much rather have the argument about the hero headline in week five than in week eleven on the live domain.

Then the pre-launch pass, which is deliberately tedious. Somebody sends a test through every form and watches the notification arrive.

Measurement is wired up and confirmed working while the site is still on staging. Robots and meta robots correct, which means the staging block is off.

Schema validates, the sitemap generates, the 404 page is useful, every image has alt text or is explicitly marked decorative, and every redirect resolves in one hop. Launch goes in the calendar early in the week and early in the day, with everybody who might need to fix something awake and at a desk.

What a web design agency owes you through all of that is a straight answer about where the project is and what is holding it up, and the usual answer is content sitting in somebody’s inbox.

Writing it is a service we sell rather than a favor we do, and buying it is nearly always cheaper than a month of nothing happening.

How long a build takes

Four to six weeks for a small business website, and the variable is rarely the development.

Six to ten weeks for a winery site or a store, because catalogs, product data and photography add a phase that a brochure site does not have. Six to twelve weeks for a redesign, because the inventory, the redirect map and the verification afterward are real work sitting on top of the build.

Those are working timelines from kickoff to launch, not sales timelines, and we would rather quote eight weeks and hit it than quote four and spend the last month apologizing.

What stretches a project is almost always the same two things. Copy that has not been written – and approvals that need four people in a room who are never in a room at the same time.

Both are fixable at the start and neither is fixable in week nine. Start there.

Common questions