DEV Community: Duskel

WordPress to Next.js Migration: A 12-Month Cost Test Before You Rebuild

Duskel — Mon, 27 Jul 2026 08:54:10 +0000

WordPress 7.1 entered beta on July 15. Your plugin bill stays.

The final release is due August 19, 2026. A core update can fix WordPress bugs, but it cannot remove the upkeep created by a page builder, shop system, security add-on, cache and forgotten plugins pulling in different directions.

A WordPress to Next.js migration makes sense when that upkeep costs more than rebuilding the visitor-facing site. Run the numbers before choosing a stack.

The 12-month cost test

Write down two totals using your own invoices and time logs.

Keep the current site

Hosting and paid plugin renewals
Staff or agency hours spent on updates and conflicts
Sales lost during slow pages or outages
Work delayed because the current setup blocks a change

Rebuild the visitor-facing site

Design and development
Moving content and checking every page
Redirecting old URLs
Hosting and upkeep for the first year

Compare the totals over the same 12 months. A rebuild has a business case when its cost is lower and it removes a repeated source of lost sales or staff time.

A lower-risk migration shape

WordPress can remain the writing screen your team knows. Next.js becomes the website customers see.

List the content types editors use today.
Pull published content from WordPress into the new pages.
Build common pages ahead of each visit so they open quickly.
Refresh a page after an editor publishes a change.

This keeps the familiar editor while removing many plugins from the customer-facing site.

Protect search traffic before launch

Every existing URL needs a destination on the new site. Build a redirect list before any page moves.

Also check:

Page titles and descriptions
The sitemap sent to search engines
The setting that tells Google which page is the official version
Links inside older articles

Run a crawl of the old site and the new one. Any missing page should block launch until it has a redirect or an intentional replacement.

Cases where staying on WordPress wins

Keep the current setup when the site is fast enough, the team depends on plugin-heavy shop features, or editors need changes that would require custom work in Next.js.

A rebuild should solve a measured cost. Version excitement alone is a poor reason to fund one.

Scope a WordPress rebuild: duskel.com/services/wordpress-development

RAG Chatbot Development for Small Business: What Actually Changed When We Swapped in Claude Sonnet 5

Duskel — Mon, 06 Jul 2026 16:40:00 +0000

Claude Sonnet 5 became the default free and Pro model on July 1. We had it running inside a client's retrieval pipeline four days later — not a toy demo, a production RAG chatbot for a small business client with about 40,000 support documents and a strict "don't make things up" requirement.

Here's what actually changed, and what didn't.

The setup

The client came to us the way a lot of small businesses do when they want to hire a developer to build a RAG system on their own data: a pile of PDFs, a shared drive, and a support inbox getting the same 30 questions on repeat. No enterprise budget, no in-house ML team, just a real need to stop answering the same email every day.

Our stack for this one is boring on purpose: pgvector for retrieval, a thin re-ranking step, and whatever LLM sits at the end answering with citations. That last part is a config value, not a rewrite. Swapping providers or model versions should be a one-line change. If it isn't, your architecture is the actual problem, not the model.

const generationModel = {
  provider: 'anthropic',
  model: 'claude-sonnet-5', // was claude-sonnet-4-6
  maxTokens: 1024,
  temperature: 0.1,
};

What got better

Two things stood out in the first 48 hours of testing against our existing eval set (about 120 real support questions with known-good answers):

Fewer confident wrong answers. Sonnet 5 was noticeably more willing to say "the documents don't cover this" instead of blending two unrelated policy sections into something plausible-sounding. That's the failure mode that actually costs small businesses money — not the chatbot being unhelpful, but the chatbot being wrong with a straight face.
Better use of retrieved context under pressure. When we deliberately fed it 8-10 chunks instead of 3-4 (a common real-world scenario when queries are vague), the answer quality held up better than the previous model. Less "picks the first chunk and ignores the rest."

Latency was roughly flat. Cost per query was flat. Neither was the reason to move.

What didn't change

The model swap did not fix bad chunking, and it did not fix a retrieval step that was already returning the wrong documents. We still spent most of our week on the boring stuff: chunk size, metadata filters, and re-ranking thresholds. That's the part of RAG chatbot development for small business clients that never makes it into vendor pitch decks, because it's not a feature you can screenshot.

There's a real backlash brewing right now about AI-written code quality — a widely cited 153-million-line analysis this week shows duplication up roughly 4x and rising churn where teams lean hard on agents without review. We see the same pattern in RAG systems: teams swap in a shinier model and expect it to paper over a retrieval layer nobody actually designed. It won't. The model is maybe 20% of why a RAG chatbot hallucinates. The other 80% is what you feed it.

The actual takeaway

If your RAG pipeline is architected so the generation model is a config value, model releases are good news you can act on in days, not a migration project. If it's not — if "switch models" means touching prompt templates in six different files — that's worth fixing before you worry about which model is smartest this quarter.

We're a founder-led software studio, not a faceless agency, and we test new model releases against real client pipelines because that's the only way to know if they matter. If you're trying to hire a developer to build a RAG system on your own data — a small business, not an enterprise budget — see how we scope it at duskel.com/services or write to hello@duskel.com.

RAG Chatbot Development for B2B: Why We Stopped Hard-Coding One LLM Vendor

Duskel — Mon, 06 Jul 2026 14:39:26 +0000

The pipeline that broke on a Tuesday

In June 2026, Anthropic's Claude was pulled from availability for 20 days in several regions under export-control rules. If you'd built a client's RAG chatbot with a single hard-coded call to anthropic.messages.create(), that client's support bot went dark. Not because the model got worse. Because the vendor got yanked.

We run a small studio building RAG systems for B2B clients, several of them outside the US, and that's the exact scenario we now design against. Not as a hypothetical — as something that already happened to teams who didn't plan for it.

Most RAG chatbot builds get the wrong thing right

When an agency pitches a "RAG chatbot development" project, the demo is always the same: embed some docs, wire up a vector store, call one model, done. It answers questions well in the sales call. Nobody stress-tests what happens when:

the vendor changes pricing overnight
the vendor's API gets export-restricted in the client's country
the vendor deprecates the model you built prompts around

We treat the LLM call as the least stable part of the stack, and design everything else so swapping it out is a config change, not a rewrite.

What we actually build

A thin provider interface sits between the retrieval layer and the model call. Retrieval, chunking, reranking, and citation logic never touch a vendor SDK directly.

class LLMProvider:
 def generate(self, prompt: str, context: list[str]) -> str:
 raise NotImplementedError

class ClaudeProvider(LLMProvider):
 def generate(self, prompt, context):
 return anthropic_client.messages.create(...)

class LongCatProvider(LLMProvider):
 def generate(self, prompt, context):
 return longcat_client.chat(...)

# swap providers via config, not a redeploy
provider = PROVIDER_REGISTRY[settings.LLM_PROVIDER]

It's not clever. That's the point — boring abstractions are the ones that survive a vendor outage.

Why open-weight models changed the calculus

LongCat-2.0 shipped this month under a full MIT license — no regional restrictions, free to fine-tune and redistribute. For a foreign client who just watched a US-origin model vanish for three weeks, that's not a curiosity, it's a fallback path. We're not saying drop Claude — Sonnet 5, out since June 30, is genuinely the sharpest agentic model we've used in production, and it's still our default for reasoning-heavy retrieval. We're saying don't let one vendor be a single point of failure for a client's support desk or internal knowledge base.

The trust gap nobody's pricing in

There's a stat going around this week: 84% of developers now use AI coding tools, but only 29% trust the output unsupervised. We see the same split with RAG specifically — clients love what a demo can do, then ask "what happens when it's wrong in front of a customer?" The honest answer is: it will be, occasionally, and your architecture needs a human review step and a citation trail, not just a bigger prompt.

That's the part of AI RAG system integration for small business that gets skipped when the pitch is all demo and no failure mode.

What this means if you're scoping one

If you're evaluating a RAG chatbot development agency for B2B work, ask two questions before you ask about accuracy: what happens when the model vendor changes terms, and can you point the same pipeline at a different model without touching retrieval code. If the answer is "we'd rebuild it," you're buying a demo, not a system.

We've been building this vendor-flexible pattern into every RAG engagement lately, partly because it's good architecture, partly because the last month proved it isn't optional for clients operating outside the US.

If you're scoping something like this, duskel.com/services has how we approach it, or just email hello@duskel.com and tell us what you're building.