DEV Community: Davie Chris

The Audit You Should Run Before Touching Your Website Redesign

Davie Chris — Mon, 29 Jun 2026 11:42:25 +0000

A real scenario: a company relaunches its website after four months of work. The new site looks great. Two months later, organic traffic is down 40 percent. Three blog posts that were quietly driving most inquiries have new URLs with no redirects. A service page ranking on page one has been rewritten and dropped off entirely.

Nobody broke anything on purpose. Nobody audited what was working before they started.

Before a single wireframe is drawn, run these four audits. They take less time than fixing the damage after launch.

Plain Terms (Quick Reference)

301 redirect — Tells browsers and search engines a page has moved to a new URL, preserving its ranking value
Organic traffic — Visitors arriving from search engines without clicking a paid ad
Conversion rate — The percentage of visitors who complete a desired action: form fill, purchase, inquiry
Crawl — How search engines discover and index pages on your site

1. The SEO Audit

Document this before anything changes:

Every URL receiving organic traffic, even low volumes
Keywords each page ranks for in the top 20 positions
Pages with inbound backlinks from external sites
Current title tags, H1 headings, and meta descriptions on ranking pages Why it matters:

If a URL changes without a 301 redirect, its ranking history disappears. If a well-optimized H1 gets replaced with a cleaner but vaguer heading, rankings drop within weeks. Backlink targets that get deleted waste accumulated authority that took months to build.

A pre-redesign SEO audit is cheaper than recovering lost rankings after launch.

2. The Traffic and Analytics Audit

Export this before the project kicks off:

Top 20 pages by organic traffic over the last 12 months
Top 10 pages by conversion events
Pages with high engagement: time on page, scroll depth, low bounce rate
Exit pages: where users most commonly leave Why it matters:

High-traffic, high-conversion pages are not candidates for experimental redesigns. They are the benchmark the new design has to beat. It is also common to discover that the page driving the most conversions is not the one the team assumed was most important. That finding changes priorities for the entire project.

3. The Content Audit

Go through every page and make a decision:

Migrate — High-performing content with traffic, rankings, or backlinks attached
Consolidate — Thin pages covering similar topics, merged into one stronger page
Improve — Pages worth keeping but with outdated or weak content
Remove — Pages with no traffic, no backlinks, no ranking value, and no business purpose Every page that migrates without review is a page that may carry outdated information into the new site.

4. The Conversion Audit

Before replacing any form or CTA, document:

Current conversion rates on every form on the site
Heatmap and session recording data on high-traffic pages
Where users drop off in multi-step flows
Device split: what percentage of conversions come from mobile vs desktop Why it matters:

A contact form converting at 5 percent should not be replaced with a new design that has not been tested. It should be the floor the new design has to beat before going live. If mobile converts at 0.8 percent while desktop converts at 4 percent, the redesign has a clear priority that no amount of visual polish will fix without addressing it directly.

The One Document That Should Travel With the Project

Combine all four audits into a single reference document:

URLs that must be preserved or redirected, with specific destinations
Pages that must not be significantly altered without sign-off
Conversion benchmarks the new site must hit within 60 days of launch
A PageSpeed floor the new site must achieve before go-live
Content migration decisions: migrate, consolidate, improve, or remove Without this, the team building the new site has no map of what made the old one valuable. With it, success has a definition beyond how it looks on launch day.

If you are planning a redesign and want the audit and build handled together, web redesign and development done with pre-launch groundwork protects the organic and conversion value you have already built.

What did your last redesign break that you did not expect? Was it caught before launch or after?

You Probably Do Not Need a Load Balancer Yet. Here Is How to Know When You Do.

Davie Chris — Tue, 23 Jun 2026 10:57:42 +0000

Load balancers come up early in system design conversations. They appear in architecture diagrams, cloud provider dashboards, and infrastructure tutorials. They sound like something every serious production system should have.

Most early-stage apps do not need one yet. And adding one before you need it introduces operational complexity without the benefits that complexity is supposed to buy you.

This is a plain-language breakdown of what a load balancer actually does, how it does it, and how to know when your system has reached the point where one makes sense.

What a Load Balancer Actually Does

A load balancer sits in front of your application servers and distributes incoming requests across them. Instead of all traffic going to a single server, the load balancer receives each request and decides which server should handle it.

The name describes the goal: balance the load. If you have three servers and ten thousand requests come in, the load balancer tries to spread those requests so no single server handles significantly more than its share. A server that is overwhelmed while two others sit mostly idle is a waste of capacity. A load balancer prevents that waste.

Beyond distributing traffic, load balancers do two other things that matter.

Health checking. A load balancer periodically checks whether each server behind it is responding correctly. If a server stops responding or starts returning errors, the load balancer removes it from the pool and stops sending it traffic. When it recovers, it gets added back. This means a single server failure does not take down the whole system, because traffic reroutes automatically to the servers that are still healthy.

Terminating connections. Load balancers handle the overhead of managing client connections, including SSL termination, so your application servers do not have to. A single load balancer can maintain thousands of open connections and forward requests to backend servers over efficient persistent connections. This reduces the per-connection overhead on each application server.

How Load Balancers Distribute Traffic

There are several algorithms for deciding which server gets the next request. The three most commonly used are worth understanding.

Round robin. Requests go to each server in turn. Server 1 gets request 1, Server 2 gets request 2, Server 3 gets request 3, Server 1 gets request 4, and so on. Simple, predictable, and works well when all requests are roughly the same cost to process.

Least connections. The next request goes to whichever server currently has the fewest active connections. This works better than round robin when requests vary significantly in how long they take. A server handling a slow database-heavy request is not a good candidate for the next fast request, and least connections accounts for that.

IP hash. The client's IP address determines which server handles the request, consistently. The same client always goes to the same server. This matters when your application stores session state in memory on the server rather than in a shared store. Without sticky routing, a user's session might exist on Server 1 but their next request goes to Server 2, which knows nothing about it.

Most managed load balancers support all three and let you switch between them without significant reconfiguration.

When a Load Balancer Actually Makes Sense

This is the part most tutorials skip. They explain what a load balancer does without explaining the conditions under which adding one is the right move rather than premature complexity.

You have outgrown vertical scaling. The simplest response to a server that is struggling under load is to give it more resources: a bigger instance, more CPU, more RAM. This is vertical scaling, and it is usually the right first move. It is cheaper, simpler, and does not require rearchitecting anything. A load balancer becomes relevant when you have hit the ceiling of what a single server can reasonably handle, or when the cost of the next vertical upgrade exceeds the cost of distributing across multiple smaller servers.

You need redundancy, not just capacity. A single server, no matter how powerful, is a single point of failure. If it goes down for any reason, the application is down. A load balancer in front of two servers means one can go down for maintenance, a crash, or a deployment and traffic continues flowing to the other. If your application needs to stay up during server failures or rolling deployments, a load balancer is part of what makes that possible.

You are running stateless application servers. Load balancers work cleanly when any server can handle any request without needing to know what happened on a previous request. If your application stores user session data in the server's memory rather than in a shared database or cache like Redis, distributing traffic across servers requires sticky sessions, which adds complexity and reduces the effectiveness of the load balancing. The cleaner solution is to move session state out of server memory first, then add the load balancer.

Traffic is genuinely variable and high. A load balancer pairs well with autoscaling: adding servers when traffic spikes and removing them when it drops. This combination makes sense when your traffic pattern has real variance and the cost of over-provisioning a single large server exceeds the cost of managing a dynamic pool. For applications with steady, predictable traffic, the autoscaling benefit is smaller.

What You Probably Need Instead Right Now

If your application is running on a single server and struggling, the diagnostic question before reaching for a load balancer is: what is actually the bottleneck?

Most single-server performance problems are not CPU or network saturation from too many concurrent requests. They are slow database queries, missing indexes, inefficient code paths, or memory pressure from application-level issues. A load balancer does nothing for any of these. Distributing slow queries across two servers gives you two servers running slow queries.

The order of operations that tends to produce better results: profile the application and fix the actual bottleneck, optimize the database layer, upgrade the server vertically if the bottleneck is genuinely resource-bound, and reach for horizontal scaling with a load balancer when vertical scaling is no longer the right answer.

Adding horizontal scaling infrastructure to a system with unresolved application-level problems spreads those problems across more servers without solving them.

Practical Starting Points

When you do reach the point where a load balancer makes sense, the managed options from cloud providers make the operational overhead significantly lower than running your own.

AWS Application Load Balancer, Google Cloud Load Balancing, and DigitalOcean Load Balancers all handle health checking, SSL termination, and traffic distribution without requiring you to manage the load balancer infrastructure itself. The configuration is straightforward and the cost at typical application scales is low relative to the reliability benefit.

For teams running on a single VPS and not yet on a major cloud provider, Nginx and HAProxy are the standard self-managed options. Both are production-proven, well-documented, and capable of handling substantial traffic. The trade-off is that you are responsible for the configuration, monitoring, and maintenance of the load balancer itself.

The Short Version

A load balancer distributes traffic across multiple servers, routes around unhealthy ones, and enables horizontal scaling. It solves real problems at the right scale.

The right scale for most applications is later than teams typically assume. Fix the application-level bottlenecks first. Scale vertically until it stops making sense. Then add horizontal scaling with a load balancer when redundancy or capacity genuinely requires it.

Infrastructure added before the problem it solves exists is not preparation. It is complexity you maintain for free until the problem arrives, if it ever does.

If you are building a web application and want the infrastructure decisions made at the right stage rather than the most impressive-sounding one, teams focused on web application development with production scale in mind tend to build systems that grow into their infrastructure rather than outgrow it.

MCP Is Not Just a Developer Thing. Your Product Team Needs to Understand It Too.

Davie Chris — Fri, 19 Jun 2026 10:17:56 +0000

I want to talk about something that keeps coming up in product conversations and almost always lands the same way.

A developer mentions MCP. The product manager nods. The meeting moves on. Nobody stops to ask what it actually changes.

That is a problem, because Model Context Protocol changes quite a bit, and the implications are not just technical.

So What Is MCP, Actually?

Model Context Protocol is an open standard that defines how AI models connect to external tools, data sources, and services. Before MCP, every AI integration was essentially custom glue code: a one-off connection between a model and a specific tool, built differently every time, maintained separately from everything else.

MCP standardizes that connection layer. Instead of bespoke integrations, you have a consistent protocol that any compatible AI model can use to talk to any compatible tool.

Think of it like USB. Before USB, every peripheral had its own connector, its own driver, its own setup process. USB did not make peripherals more powerful. It made connecting them dramatically simpler and more predictable. MCP does something similar for AI and the tools it works with.

What This Actually Unlocks

Here is where it gets interesting for product teams.

Before MCP, adding AI to a product meant deciding upfront exactly what the AI could touch. You scoped the integration, built the connection, and shipped it. If the AI needed access to something new, you built another integration. The AI's capabilities were essentially frozen at whatever you connected at build time.

With MCP, the connection layer is standardized and composable. An AI agent inside your product can, in principle, reach any MCP-compatible tool or data source without a custom integration for each one. New capability does not require new glue code for every combination.

For product teams, this changes the conversation from "what can we build the AI to do" to "what should we allow the AI to do." That is a fundamentally different kind of decision, and it belongs in product thinking, not just engineering.

The Questions Product Teams Should Be Asking

If your product is adding AI features, or if you are planning to, MCP is worth understanding at the conceptual level. Not the protocol spec, but the implications.

What context does your AI actually need? MCP makes it easier to give an AI model access to live data, user state, external services, and internal tools. That is only useful if you have thought through what context makes the AI genuinely more helpful rather than just more connected.

Where do you draw the permission boundary? The easier it is to connect tools, the more important it becomes to be deliberate about what the AI can and cannot touch. That is a product and trust decision before it is a technical one.

How does this change your feature roadmap? If AI features no longer require a custom integration for every data source, the constraint shifts from "can we build this connection" to "should we ship this capability." Some things that seemed out of scope become realistic. That deserves a conversation between product and engineering, not an assumption on either side.

Why This Matters More Than It Looks

The teams that are going to build the most useful AI features in the next couple of years are not necessarily the ones with the best models. They are the ones who are clear on what their AI should be able to do, what data it should have access to, and where the boundaries are.

MCP lowers the technical barrier to connecting AI with the rest of a product's stack. That is genuinely useful. But lower barriers mean the decisions about what to connect, and what not to, matter more than they did before.

Product teams that treat MCP as a developer detail are going to find themselves reacting to capability decisions that should have been made at the product level.

If your team is working through what AI integration looks like inside a web application, the architectural decisions that come before the build matter as much as the build itself. Teams doing custom web application development with AI features built in from the start tend to end up with cleaner results than teams retrofitting AI into an existing system.

How We Decide When to Refactor and When to Rewrite

Davie Chris — Tue, 16 Jun 2026 10:06:03 +0000

Every developer has been in this meeting.

The codebase is struggling. Features are taking three times longer than they should. The team dreads touching certain files. A new developer joined two months ago and still is not fully productive because the system is so hard to understand. Someone finally says it out loud: maybe we should just rewrite the whole thing.

And then the room splits.

Half the team wants to burn it down and start fresh. The other half has been burned by rewrites before and knows how that story usually ends. Both sides are drawing from real experience. Both sides are right about something.

The truth is that neither refactoring nor rewriting is universally the correct answer. The right call depends on a specific set of conditions that are worth examining honestly before committing to either path. Because the cost of choosing wrong is significant in both directions.

Why Rewrites Feel Appealing and Usually Disappoint

The appeal of a full rewrite is psychological as much as technical.

A blank slate means no inherited constraints, no decisions made by people who have long since left the company, no embarrassing patterns you have been working around for years. You get to do it right this time. The excitement is real and it is not irrational.

The problem is that rewrites almost always take longer than estimated, frequently reproduce the same mistakes as the original in new clothing, and create a period of painful paralysis where the old system is still running in production while the new one is being built. You are maintaining two codebases simultaneously. The old one still needs bug fixes. The new one is perpetually almost ready.

Joel Spolsky wrote about this phenomenon over twenty years ago and called it one of the worst mistakes a software company can make. The lesson has not aged. Teams still walk into rewrites optimistically and emerge eighteen months later having delivered something that, on a good day, matches the functionality of what they replaced.

That is not an argument against ever rewriting. It is an argument for being brutally honest about why you want to.

The Conditions That Actually Justify a Rewrite

A rewrite makes sense when the problems you are dealing with are architectural rather than surface-level. Specifically, when the foundation of the system prevents you from building what the business needs and no amount of incremental improvement will change that.

A few conditions where we have found a rewrite to be the right call:

The data model is fundamentally wrong. If the way data is structured in the database does not reflect how the business actually works, and changing it would require touching nearly every part of the application, you may be better off redesigning from scratch. Trying to migrate a broken data model incrementally is one of the most painful things a development team can do.

The technology is genuinely end of life. Not just old, but abandoned. No security patches, no community support, incompatible with modern infrastructure. There is a difference between a codebase running on a framework that is a few versions behind and one running on something that has not had a commit in four years and has known unpatched vulnerabilities.

The business requirements have changed so fundamentally that the original system was solving a different problem. A codebase built for a single-tenant application that now needs to serve thousands of tenants is not just a refactoring project. The assumptions baked into every layer of that system are wrong for the new use case.

Nobody alive understands how it works. This sounds dramatic but it happens. If the system has no documentation, the developers who built it are gone, and the current team cannot confidently explain what a significant portion of the code does, you are not really refactoring anything. You are guessing. That is its own kind of risk.

Even when these conditions are met, the right rewrite is usually not a big bang replacement. It is a strangler fig pattern: build the new system incrementally alongside the old one, migrate functionality piece by piece, and decommission the old system gradually rather than all at once.

The Conditions That Point Toward Refactoring

Most of the time, the honest answer is that the system does not need to be rewritten. It needs to be cleaned up.

Refactoring makes sense when the core architecture is sound but the implementation has accumulated problems over time. Duplicated logic, inconsistent patterns, missing tests, functions that have grown to hundreds of lines, classes that have taken on responsibilities they were never designed for.

These problems are real. They slow teams down, they introduce bugs, they make onboarding harder. But they are fixable without replacing everything.

A few signals that point toward refactoring over rewriting:

Features can still be added, just more slowly than they should be. If the system is frustrating but functional, that is a refactoring problem. Slowness is a symptom of accumulated debt, not architectural failure.

The team understands the system well enough to work in it. If developers can explain what the code does, even if they do not like how it does it, that understanding is an asset. A rewrite discards it entirely.

The problems are concentrated in specific areas. Most codebases have a handful of modules that cause the majority of the pain. If you can identify them, you can target them. A full rewrite because one module is a mess is like demolishing a house because one room needs renovation.

The business cannot afford to stop shipping features. Rewrites require capacity. Real capacity, not theoretical capacity. If the business needs features delivered while the technical work is happening, a rewrite will either starve the product or starve itself.

The Honest Conversation Nobody Wants to Have

Here is the part that gets skipped most often.

Before deciding between refactoring and rewriting, someone needs to ask why the system got to this state. Not to assign blame, but because the answer tells you whether the problem is technical or organizational.

If the codebase is in poor shape because of accumulated pressure, changing requirements, and the normal entropy of software development, that is a technical problem with technical solutions. Refactor the worst parts, establish better practices going forward, allocate time for regular maintenance.

If the codebase is in poor shape because the team does not have a culture of code review, or because technical debt is always deprioritized in favor of new features, or because there is no ownership of quality, a rewrite will not fix any of that. You will have a new codebase and the same organizational dynamics that degraded the old one. In two years you will be having this meeting again.

The rewrite vs. refactor decision is a technical decision that often has a non-technical root cause. Getting that root cause right matters as much as the technical choice.

How We Actually Make the Call

When we are evaluating a struggling codebase, whether our own or one we have inherited from a client, we work through a few specific questions before recommending a direction.

Can we draw a clear boundary around the worst parts of the system and address them in isolation? If yes, that is almost always the starting point. Targeted improvement before wholesale replacement.

Is the core data model consistent with what the business actually needs today? If the answer is no and the gap is large, that shifts the calculation significantly toward a rebuild.

What does the team understand and what have they lost? Institutional knowledge of how a system works has real value. We weigh what a rewrite costs in lost knowledge against what it gains in technical freedom.

What does the business need over the next twelve months? A rewrite is a bet that the investment now pays off later. That bet only makes sense if the business has the runway and stability to absorb the transition period.

Most of the time we end up recommending a structured refactoring plan with clear targets and a defined timeline, rather than a full rewrite. Not because rewrites are always wrong, but because they are almost always oversold and underestimated by the teams proposing them.

The cases where we recommend a rewrite are real. But they are fewer than most teams think when they are standing in the middle of a painful codebase and imagining how good it would feel to start over.

Starting over feels good. Finishing the rewrite is where it gets hard.

If you are working through this decision on a specific system and want a second opinion on what the right path looks like, talking to a team that has done both is usually worth the conversation before committing either way.

The Real Cost of Technical Debt Nobody Talks About

Davie Chris — Tue, 09 Jun 2026 08:29:05 +0000

The Real Cost of Technical Debt Nobody Talks About

We talk about technical debt like it's a number on a spreadsheet.

"Yeah, we have some tech debt. We'll clean it up next sprint."

Next sprint becomes next quarter. Next quarter becomes next year. And somewhere along the way, that debt stopped being a footnote and started being the reason your team dreads touching certain parts of the codebase.

I've seen it happen more times than I can count. And the actual cost of it almost never gets discussed honestly — not with clients, not with stakeholders, and sometimes not even between developers.

So let's talk about it.

It Doesn't Show Up on Any Invoice

That's the first problem.

Technical debt is invisible on paper. Nobody sends you a bill that says "you skipped proper architecture three years ago, here's what that costs you now." It shows up in slower feature delivery. In developers going quiet when someone asks how long a change will take. In the subtle dread that comes before touching a module nobody fully understands anymore.

The cost is real. It's just distributed in ways that are easy to ignore until they aren't.

A feature that should take three days takes two weeks because it touches code that was never designed to be touched that way. A bug fix introduces two new bugs because the original logic was never documented and nobody alive on the team fully understands what it was trying to do.

That's not a delivery problem. That's a debt repayment.

The Three Types Nobody Warns You About

Most developers think of technical debt as messy code. And sure, that's part of it. But in practice, the types that cost the most aren't always the obvious ones.

1. Architecture debt

This is the expensive one. It's the decision made early in a project to structure things in a way that made sense at the time but doesn't scale. Monoliths that were never designed to become monoliths. Databases that were normalized for a use case that no longer exists. Auth systems bolted on after the fact because security was "phase two."

Architecture debt doesn't just slow you down. At a certain point, it stops you entirely. The only path forward is a rewrite, and rewrites are terrifying, expensive, and often politically impossible to sell.

2. Dependency debt

The project that runs on a package last updated in 2019. The plugin that three critical features depend on but that hasn't had a security patch in two years. The custom library a developer wrote who left the company in 2021 and took the context with them.

Dependency debt is quiet until it's catastrophic. An unmaintained package with a known vulnerability doesn't announce itself. It waits.

3. Knowledge debt

This one almost never gets called technical debt, but it should.

When the understanding of how a system works lives in one person's head, or worse, in nobody's head anymore, you have debt. Every time that person is unavailable, you pay interest. Every time a new developer joins and spends three weeks trying to understand what's happening before they can contribute, that's the debt servicing itself.

Why Teams Keep Accumulating It

Nobody sets out to write bad code. Nobody plans for their architecture to become a liability.

It happens because of pressure.

Deadlines that don't move. Scope that expands without timeline adjustment. The classic "we'll refactor this later" that becomes a cultural habit rather than an actual plan. Junior developers shipping features without code review because the senior developer is already maxed out.

And here's the uncomfortable part: sometimes it's the right call in the moment. Shipping something imperfect is often better than not shipping at all. The problem isn't that debt gets created. The problem is that it never gets repaid.

Interest compounds. In finance and in codebases.

What It Actually Costs: A Real Scenario

Let's make this concrete.

A team builds a web application in year one. They move fast, ship often, and make some structural decisions they know are shortcuts. The system works. Clients are happy. The business grows.

Year two: The team wants to add a new feature. It requires touching the core data model. What should be a two-week job takes six weeks because the original model wasn't designed for this use case. Two developers spend significant time understanding the existing code before writing a single new line.

Year three: A security vulnerability is discovered in a dependency the app relies on. Patching it requires updating three other packages, which breaks two other things, which requires another week of firefighting.

Year four: A key developer leaves. They were the only person who fully understood the authentication layer. Onboarding their replacement takes four months instead of four weeks.

By year four, the business has paid far more in accumulated interest than it would have cost to build things properly in year one. But the connection between the original shortcuts and the current costs is invisible to anyone who wasn't there from the beginning.

This is not a hypothetical. This is a pattern we see consistently in inherited projects and codebases that come to us for custom web development and system rebuilds.

How to Actually Address It

Acknowledging debt is step one. Here's what actually helps:

Make it visible. Technical debt that isn't tracked doesn't get addressed. Log it somewhere. A simple Notion doc, a label in your issue tracker, anything that makes it a real thing with a real list.

Treat repayment as non-negotiable. Not every sprint. Not "when we have time." A consistent percentage of development capacity allocated to debt repayment. Some teams do 20%. Some do 10%. The number matters less than the consistency.

Stop framing it as a developer problem. Technical debt is a business risk. Framing it that way in stakeholder conversations changes how seriously it gets taken. "Our authentication layer hasn't been updated in three years and relies on a deprecated package" lands differently than "the code is a bit messy."

Document before you refactor. The instinct is to rewrite immediately. The smarter move is to document what the existing system does first. You cannot replace something you don't fully understand, and understanding it before you touch it saves you from the classic trap of rewriting a system only to rediscover why the original decisions were made.

The Teams That Handle It Best

The teams that manage technical debt well share a few traits.

They talk about it openly. Not defensively, not as an indictment of past decisions, but as a normal part of how software development works. Debt is not a failure. Unacknowledged, unmanaged debt is.

They build in time for it. Not because they have extra capacity, but because they understand that not building in time for it costs more.

They involve non-technical stakeholders in the conversation. Not to explain every detail, but to make the business risk legible. When a CTO can tell a CEO "we need two sprints of refactoring or we won't be able to build X in Q3", that's debt being managed like the business risk it is.

Final Thought

Technical debt is not a sign that your team is bad at their jobs. It's a sign that your team shipped under real-world constraints, which is what almost every team does.

The difference between a codebase that remains workable and one that becomes a liability is not whether debt was created. It's whether anyone had the discipline and the organizational support to pay it back.

If you're staring at a codebase that's become more weight than asset, you're not alone. And the first step is usually the same: stop adding to it while you figure out what you're dealing with.

We work with teams navigating exactly this kind of challenge. If your system has grown faster than its architecture, our team at Spice Factory helps businesses untangle, rebuild, and build right.