DEV Community: Aqib Javaid

Marketplace Website Development Cost: What to Budget

Aqib Javaid — Wed, 04 Nov 2026 10:40:25 +0000

If you are planning a marketplace, the first question is almost always the same: what does marketplace website development cost? The honest answer is that the price is driven by a handful of decisions that have nothing to do with how the site looks. Payments between three parties, trust and safety, search, messaging and admin tooling are where the budget goes.

I'm Aqib Javaid, a senior full-stack engineer, and I've built marketplace-style platforms where money, content and multiple user roles all have to work together. This guide breaks down what actually moves the cost, gives rough planning ranges by scope, and shows where founders overspend. The ranges are planning estimates, not quotes. A real number needs a scoped spec.

What makes a marketplace more expensive than a normal website?

A brochure site has one audience. A marketplace has at least three: buyers, sellers (or vendors, or service providers) and you, the operator. Every feature has to be built three times over, once for each side's view and permissions.

Four things separate a marketplace from a typical web app:

Split payments. Money goes from buyer to seller, minus your commission, and sometimes with refunds, disputes and payouts on a schedule.
Two-sided accounts. Sellers need onboarding, profiles, listings and dashboards. Buyers need search, favourites, orders and messaging.
Trust and moderation. Reviews, reporting, listing approval and admin controls are not optional once real strangers transact.
Liquidity tooling. Search, filters, notifications and email flows that bring both sides back.

None of these are exotic, but each one adds weeks, and they interact. That is why a "simple Airbnb for X" is rarely simple.

How much does a marketplace cost at different scopes?

Treat these as rough planning ranges for a senior engineer or small team building a custom product. Agency rates, location and team size will move them in either direction.

Scope	What is included	Typical planning range
Validation MVP	One listing type, simple seller profiles, basic search, one payment flow, admin panel	$15,000 to $35,000
Launch-ready marketplace	Seller onboarding, split payments with payouts, messaging, reviews, email notifications, admin moderation	$35,000 to $80,000
Scaled platform	Multi-language, real-time messaging, advanced search, multiple payment methods, analytics, mobile apps	$80,000 and up

The wide spread exists because "marketplace" covers a services board and a full multi-vendor commerce platform equally. If you are still deciding what to include in version one, the same logic I use in the SaaS MVP development cost breakdown applies here: build the smallest thing that proves buyers and sellers will actually transact.

Where does the money actually go?

On a typical build, I see the budget split roughly like this: payments and payouts, seller onboarding and dashboards, search and listings, messaging and notifications, admin and moderation, then design and QA. Payments are consistently the line founders underestimate.

Payments and payouts

Taking one payment is a day of work. Taking a payment, holding the platform fee, paying the seller later, handling refunds and reconciling it all is a project. Stripe's own Connect marketplace documentation is the right place to see how fund flows work, and the choice of charge type changes who is liable for disputes and refunds. Decide this before you design the seller dashboard, because it shapes the whole data model.

On the Imperial Votes platform, the payment logic had to support different countries, currencies and payment gateways, alongside organizer dashboards and paid voting. Multi-gateway support was a major part of the work, not an afterthought.

Multi-language and localisation

If your marketplace serves more than one country, translation becomes a content system, not a plugin. On Planuojam, a multilingual event planning marketplace, we rescued a failing platform by building a headless marketplace in Next.js and Strapi 5 that supports five languages, real-time messaging and Stripe payments. We added an AWS Translate-powered engine in Strapi to automate nested content localisation while preserving SEO integrity. Strapi's internationalization docs cover the baseline, but anything beyond the baseline takes custom work, and it should be priced in.

Messaging and notifications

Buyer-to-seller messaging looks small on a feature list. Real-time delivery, unread counts, email fallbacks and abuse controls make it a mid-sized feature. If you can launch with a simple contact form and add live chat once you have traffic, you save real money.

Admin and moderation

Founders forget that they are the third user. You need to approve sellers, remove listings, handle refunds, see payouts and export reports. A weak admin panel turns every support request into a developer ticket.

Build custom, use a SaaS platform, or start with a plugin?

Not every marketplace needs custom code on day one.

Approach	Best for	Trade-off
Marketplace SaaS or plugin	Testing demand quickly with standard flows	Limited customisation, fees, and you may outgrow it
Custom build on a proven stack	Unique workflows, multiple payment rules, SEO-led growth	Higher upfront cost, full control
Hybrid: CMS plus custom app	Content-heavy marketplaces needing editorial control	Needs good architecture so the pieces stay in sync

My rule of thumb: if your differentiator is the workflow or the pricing model, build custom. If your differentiator is supply or community, test with an off-the-shelf tool first. For the stack itself, I usually reach for Next.js and React on the front end with a Laravel or Strapi backend, depending on whether the product is application-heavy or content-heavy. The Next.js documentation is a good starting reference for what the framework handles out of the box.

If the platform will have subscriptions, tiers or multiple organisations on it, read the multi-tenant database trade-offs before you commit to a data model. Changing it later is expensive. Our SaaS development service covers exactly this kind of architecture work.

How can you reduce marketplace development cost without cutting corners?

Pick one side to serve first. Launch with a supply you personally curate, so you don't need full seller self-service on day one.
Keep one payment method and one currency until revenue proves you need more.
Use managed services for email, search and file storage instead of building them.
Delay the mobile apps. A responsive web app validates demand for a fraction of the price. The mobile app development cost guide shows when native is worth it.
Write the spec before you hire. Most budget overruns come from features added mid-build, not from the original scope.
Budget for after launch. Plan for hosting, fixes and iteration from the start.

Tip

Before you ask for quotes, write one page describing who pays whom, when, and who handles a refund. That one page removes more estimate variance than any feature list.

When should you not build a custom marketplace?

Skip the custom build if you have no proof that sellers will list and buyers will pay. A spreadsheet, a form and manual payouts can validate demand for almost nothing. I would rather you spend $2,000 learning that the idea doesn't work than $50,000 finding out after launch.

Also avoid building if a niche Shopify store or WooCommerce setup already covers your model. Our custom versus Shopify comparison explains where that line sits for commerce-style products.

Frequently asked questions

How long does it take to build a marketplace?

A focused validation MVP usually takes two to three months with a small team. A launch-ready platform with split payments, messaging and moderation more often takes four to six months. Multi-language or mobile app scope extends that.

What are the ongoing costs after launch?

Expect hosting, third-party fees (payment processing, email, maps or search), security updates and a steady stream of improvements. Plan a monthly maintenance budget rather than treating launch as the finish line.

Can I build the marketplace in phases?

Yes, and I recommend it. Phase one proves transactions work. Phase two adds the features that raise retention, such as reviews and messaging. Phase three scales with localisation or mobile.

Do I need a developer or an agency?

For a focused MVP, a senior full-stack engineer is often faster and cheaper than an agency because there are fewer handoffs. Larger platforms with design, QA and project management needs may justify a team.

Key takeaways

Marketplace cost is driven by payments, two-sided accounts, moderation and admin tooling, not by page design.
Planning ranges run from roughly $15,000 for a validation MVP to $80,000 and up for a scaled, multi-language platform.
Decide your payment model (who holds funds, who handles refunds) before you design anything else.
Validate demand manually first, then build only the side of the marketplace you need to start transacting.
Write a one-page spec of the money flow before requesting quotes.

If you are scoping a marketplace and want a realistic number, book a call and I'll walk through your requirements with you.

Originally published at aqibjavaid.site.

SaaS MVP Development Cost: What to Budget Before You Build

Aqib Javaid — Mon, 02 Nov 2026 14:14:16 +0000

Founders ask me the same question early in almost every SaaS conversation: "What will the MVP cost?" The honest answer is that SaaS MVP development cost is mostly decided by a handful of scope choices you make before a developer writes a line of code. The tech stack matters far less than people expect.

This guide walks through the pieces that make up the budget, the features that quietly inflate it, and how I help founders cut a first version down to something that proves demand. It complements my general guide to custom web app MVP cost, with a focus on subscription software. If you are planning a build, my SaaS development service is the place to start.

I am not giving fixed price figures here, because a number without a scope is meaningless. What I can give you is the structure of the estimate, so you can judge any quote you receive.

What an MVP is (and is not)#

An MVP is the smallest product that lets real users complete the one job you are selling, so you can learn whether they will pay for it. It is not a cheap version of the final product. It is a deliberately narrow product.

Most overspending comes from treating the MVP as "version one of everything." Each extra feature adds build time, testing, support and a longer wait before you learn anything.

The building blocks of a SaaS budget#

Every SaaS product shares a core of plumbing before your unique value appears. Know what is in it:

Block	What it includes	Why it costs more than it looks
Accounts and auth	Sign-up, login, password reset, email verification, optional social login	Security details and edge cases
Roles and permissions	Admin, member, owner; team invites	Grows with every new role
Billing	Plans, trials, upgrades, failed payments, invoices, taxes	Billing is a state machine, not a form
Core feature	The one thing users came for	Your actual product
Admin tools	Manage users, support, content	Needed from day one for support
Notifications	Transactional email, in-app alerts	Deliverability and templates
Infrastructure	Hosting, environments, backups, monitoring	Often forgotten in estimates
Design and UX	Flows, UI, responsive layouts	Quality drives conversion
Testing and QA	Automated tests, manual passes	Prevents costly regressions

When you receive a quote, check that each of these is accounted for. A suspiciously low number usually leaves out billing, admin tools or testing.

Features that quietly inflate the cost#

Multi-tenancy#

If each customer is a separate organisation with isolated data, you need a tenancy model from the start. It touches every query and permission check. I explain the options in shared vs separate database for multi-tenant SaaS. Decide this early, because retrofitting it is expensive.

Billing complexity#

A single flat monthly plan is straightforward. Add usage-based pricing, multiple currencies, seat-based plans, coupons, proration and annual contracts, and the effort multiplies. Start with the simplest model that lets you charge, and let customer feedback justify more. My notes on subscription billing architecture in Laravel show why this area deserves care.

🛠 Engineering Service

Need specialized help with SaaS Development?

Build scalable SaaS products from MVP to production, including subscriptions, multi-tenant architecture, dashboards, integrations, automation, and complex business workflows.

Discuss Architecture →About this service

Integrations#

Each third-party integration (CRM, accounting, calendar, data providers) adds authentication, error handling and maintenance. Pick the one or two that are essential to the first customers and defer the rest.

Real-time features#

Live updates, chat and collaborative editing are powerful and costly. Use them only where the product is meaningless without them. On the Imperial Votes platform, a custom online voting product for contests and pageants, I built it from scratch using Next.js, Prisma and PostgreSQL with Stripe and Paystack for payments and Socket.IO for live behaviour. Features like payments and real-time updates were core to that product, so they belonged in the first version. For many other products they would not.

Custom admin and analytics#

Dashboards, reports and exports look small on a wireframe and are large in code. Use off-the-shelf analytics early, and build custom reporting after you know what users ask for.

Mobile apps#

A responsive web app often serves an MVP. Native apps double the surface area. Add them when you have evidence that mobile is where users are.

How to scope the first version#

Write the one-sentence promise. "Help X do Y without Z." Every feature must serve it.
List user journeys, not features. Sign up, do the core job, pay. If a journey is not needed to learn something, defer it.
Sort into must, should and later. Be strict about "must": would the first ten customers refuse to use it without this?
Replace features with manual processes. Onboard customers by hand, invoice the first few manually, review data in a spreadsheet. These are valid MVP techniques.
Buy before you build. Use proven services for auth, email, payments and error tracking where it fits.

For a deeper look at decisions to make before development starts, read technical decisions before building a SaaS product.

Cost drivers outside the code#

Unclear requirements. Changes during development cost more than changes in planning.
Slow feedback. Delays in decisions and approvals stretch a project and increase cost.
Team structure. A senior engineer working directly with a founder usually moves faster than a layered team, but suits some projects better than others.
Post-launch work. Budget for fixes, small improvements and hosting. A common rule of thumb is to keep a reserve for the months after launch rather than spending everything on version one.

How to compare quotes#

When two quotes differ widely, compare these before you compare price:

Is the scope written down in terms of user journeys?
Does it include billing, admin, notifications and testing?
Who owns the code and where is it hosted?
What is the plan for the first three months after launch?
Can the work be delivered in phases with a review after each?

A phased approach, with a working slice every couple of weeks, is the best protection against surprises. You see progress, you can change direction and you can stop with something usable.

When not to build custom software yet#

If you can test the idea with a no-code tool, a spreadsheet and a payment link, do that first. Custom software is justified when the workflow cannot be faked, or when no-code tools cannot deliver the experience or control you need. I have helped teams move off those tools once they hit limits, as in migrating a no-code app to Next.js and Postgres, but a first prototype in a simpler tool can save months.

The principle behind all of this is to launch with a small feature set and learn from real users before you invest further.

Frequently asked questions#

How long does it take to build a SaaS MVP?#

It depends on scope, but a focused first version is typically measured in weeks to a few months, not a year. If the plan says a year, the scope is probably too large.

Should I use Laravel or Next.js for a SaaS MVP?#

Either can work. Laravel gives you authentication, queues, billing integrations and an admin-friendly structure quickly. Next.js suits products with rich front ends. The choice should follow your product and team, and I compare the options in my Laravel vs Node.js for SaaS article.

Do I need multi-tenancy from day one?#

If customers are organisations with their own users and data, yes. If your product is for individuals, probably not.

What should I keep out of the MVP?#

Anything you cannot connect to a measurable learning goal: advanced reporting, multiple integrations, custom roles, native apps and elaborate settings screens.

Key takeaways#

MVP cost is driven by scope choices: tenancy, billing, integrations, real-time features and admin tools.
Check every quote for auth, billing, admin, notifications, infrastructure and testing.
Define the first version by user journeys and cut anything that does not help you learn.
Phase the work, review after each phase and keep a reserve for post-launch.

If you are planning a SaaS product and want help turning an idea into a scoped first version, book a call or get in touch.

Originally published at aqibjavaid.site.

Laravel N+1 Query Problem: How to Find and Fix It

Aqib Javaid — Mon, 02 Nov 2026 14:14:03 +0000

When a Laravel page that used to load in half a second suddenly takes four, the cause is very often the same: the N+1 query problem. One query fetches a list, and then your code quietly runs one more query for every row. With 10 rows nobody notices. With 500 rows the database is doing 501 round trips for a single page.

This article shows how to find N+1 queries, fix them properly and keep them from returning. It builds on my guide to finding slow queries in Laravel, and if your whole application feels slow, my database optimization and backend performance service is where I start.

What the problem looks like#

Imagine a list of orders that shows each customer's name:

php

Copy

$orders = Order::latest()->take(50)->get();

foreach ($orders as $order) {
    echo $order->customer->name; // runs a query per order
}

That is 1 query for orders plus 50 for customers: 51 queries. The code looks innocent because relationship access reads like a property. Eloquent loads relations lazily by default, so each first access hits the database.

It gets worse when it hides in places you do not expect: a Blade loop, an API resource, an accessor that touches a relation, or a policy check inside a loop.

How to find N+1 queries#

Use Laravel's built-in guard#

The simplest tool is to make lazy loading an error in non-production environments. In a service provider:

php

Copy

use Illuminate\Database\Eloquent\Model;

public function boot(): void
{
    Model::preventLazyLoading(! app()->isProduction());
}

Now any lazy load throws an exception during development and tests, with the model and relation named. This turns a silent performance bug into a visible failure. The behaviour is documented in the Eloquent relationships docs.

In production, you can log violations instead of throwing, using Model::handleLazyLoadingViolationUsing().

Use a debugging tool#

Laravel Debugbar or Telescope shows the number of queries per request and highlights duplicates.
Clockwork gives a timeline in the browser.
For production, an APM or logging setup that records query counts per request lets you find the worst endpoints. I cover this in observability for Laravel.

Count queries in a test#

php

Copy

DB::enableQueryLog();
$this->getJson('/api/orders')->assertOk();
$this->assertLessThan(10, count(DB::getQueryLog()));

Tests that assert a query budget on your busiest endpoints catch regressions before release.

🛠 Engineering Service

Need specialized help with Database Optimization & Backend Performance?

Find and fix database and backend bottlenecks in data-heavy applications, with a focus on query performance, indexing, architecture, and scalability.

Discuss Architecture →About this service

The fixes#

Eager loading with `with()`#

Load the relation up front. Laravel runs one extra query for all related records instead of one per row:

php

Copy

$orders = Order::with('customer')->latest()->take(50)->get();

Now it is 2 queries, regardless of how many orders there are.

Eager load nested relations with dot notation, and select only the columns you need:

php

Copy

Order::with(['customer:id,name', 'items.product:id,name,price'])->get();

Remember to include the key columns Eloquent needs to match records, such as id and foreign keys.

Counts and aggregates with `withCount()`#

Showing "12 comments" per post by calling $post->comments->count() loads every comment. Use:

php

Copy

Post::withCount('comments')->get(); // adds comments_count

There are also withSum, withAvg, withMin and withMax for aggregates computed in SQL.

Conditional eager loading#

If a relation is only needed sometimes, use load() or loadMissing() after the fact:

php

Copy

$orders->loadMissing('customer');

In API resources, use whenLoaded('customer') so the resource does not trigger a lazy load by accident.

Default eager loads: use sparingly#

You can set $with on a model to always load certain relations. It is convenient and dangerous, because every query for that model now loads those relations whether they are needed or not. Prefer explicit with() in the places that need it.

Where N+1 hides#

Hiding place	Why it happens	Fix
Blade loops	`@foreach` accesses `$item->relation`	Eager load in the controller
API resources	Resource reads a relation per item	`whenLoaded()` plus eager load
Accessors	An attribute method touches a relation	Eager load or compute in SQL
Policies and gates	Authorisation queries per row	Preload permissions once
Counts in views	`->count()` on a loaded relation	`withCount()`
Nested relations	Parent loaded, children lazily loaded	Dot notation in `with()`

Eager loading is not always the answer#

Sometimes the better fix is different:

Pagination: do not load thousands of records at all. Paginate or use cursors.
Joins or subqueries: for sorting or filtering by a related value, a join can be better than loading models.
Chunking: for big exports and jobs, use chunkById() or lazy collections to limit memory, then eager load per chunk.
Caching: if the result is expensive and changes rarely, cache it. See Redis caching in Laravel, and remember that cache hides a slow query, it does not fix it.
Indexes: a query that runs once but scans a whole table is a different problem. Check EXPLAIN and add the right index.

Eager loading can also overshoot: loading large relations you do not display wastes memory. Select only what you need.

A real-world pattern#

Data-heavy dashboards are where N+1 bites hardest. On the Violerts NYC compliance platform, the backend consolidates property data from several city sources and serves it to a React frontend through REST APIs. In any system with related records shown in lists and maps, the habits are the same: eager load what a view needs, aggregate in SQL and keep query counts predictable per endpoint. I treat query count as a metric to watch, in the same way as response time.

A simple routine for existing apps#

Turn on preventLazyLoading in local and CI environments.
Run your main pages and API endpoints and note any exceptions.
Fix each with with(), withCount() or a query change.
Add query-count assertions to tests for your busiest endpoints.
In production, log slow requests and high query counts, and review them regularly.
Re-check after major features. N+1 problems come back as code changes.

For broader MySQL tuning (slow log, EXPLAIN, indexes), the MySQL documentation on EXPLAIN is the reference to keep open.

Frequently asked questions#

Does Laravel fix N+1 automatically?#

No. By default, Eloquent lazy loads. You need to eager load or enable preventLazyLoading to catch it.

Will eager loading always be faster?#

Usually, for lists. For a single record where you rarely need the relation, lazy loading is fine. Measure rather than assume.

Is N+1 still a problem with a fast database?#

Yes. Each query has network and parsing overhead, so hundreds of small queries add up even when each one is fast, and they load the database under traffic.

How many queries per page is too many?#

There is no fixed number, but a list page that needs more than a dozen or so queries deserves a look, and counts that grow with the number of rows are a red flag.

Key takeaways#

N+1 happens when code lazy loads a relation inside a loop; the query count grows with the row count.
Use Model::preventLazyLoading() in development and tests to make it visible.
Fix with with(), withCount() and loadMissing(), selecting only needed columns.
Guard against regressions with query-count tests and production monitoring.

If your Laravel application is slow and you want an expert to find out why, book a call or contact me.

Originally published at aqibjavaid.site.

How to Migrate WordPress to Next.js Without Losing SEO

Aqib Javaid — Mon, 02 Nov 2026 14:13:33 +0000

Moving a WordPress site to Next.js can make it faster and easier to evolve. Done badly, it can also wipe out years of search rankings in a week. The technology rarely causes that. Missing redirects, changed URLs, lost metadata and a forgotten sitemap do. This guide is the plan I follow to migrate WordPress to Next.js without losing SEO, written for business owners and the developers they hire.

If you are still deciding whether to move at all, read Next.js vs WordPress for a business website first. If you have decided, my React and Next.js development service covers builds like this.

Principle: keep everything Google already knows#

Search engines have learned your URLs, titles, headings, links and content. A migration is safe when, after launch, the same URLs return the same content (or a clean redirect to its new home), with the same metadata and a fast, crawlable page. Everything below serves that principle.

Step 1: Take a full inventory before touching code#

Build a spreadsheet of what exists now:

Every indexed URL: crawl the site and export URLs from your sitemap, analytics and Google Search Console.
For each URL: title, meta description, H1, canonical, status code, internal links in, organic traffic and impressions.
Rankings for your key pages and queries.
Structured data, redirects already in place, and any special files like robots.txt, ads.txt or verification files.

Save a copy of this baseline. It is how you will prove, a month later, whether the migration worked.

Step 2: Decide the URL strategy#

The safest approach is to keep URLs identical. WordPress commonly uses paths like /blog/post-name/ with a trailing slash, category archives and pagination. Next.js can reproduce these through its routing and configuration (for example, the trailingSlash option and dynamic routes).

If a URL must change, give every old URL a one-to-one 301 redirect to its new equivalent. Avoid redirecting everything to the home page, which Google treats as a soft 404. Avoid chains: old to new in a single hop.

Step 3: Choose how content is managed#

You rarely want to hand-code content into React. Options:

Headless WordPress: keep WordPress as the editor and fetch content through its API into Next.js. The editing experience stays familiar.
A headless CMS such as Strapi or Contentful, with content migrated across.
Markdown or MDX files in the repository, which suit developer-run blogs.

On the Nooora Beauty Concierge site, I joined a project where some sections came from Strapi and others were hard-coded, and client content changes required a developer. The work was moving major content areas into Strapi, adding dynamic service pages and building SEO and sitemap support, so the client could update content themselves on a platform that depends on search visibility. The lesson applies to any migration: decide who edits content and make the CMS support that person.

Step 4: Recreate on-page SEO exactly#

For every page, carry over:

Title tags and meta descriptions. In the Next.js App Router, use the Metadata API (generateMetadata) to render them server-side.
Canonical URLs that point to the preferred version.
Heading structure, especially H1.
Open Graph and social tags.
Image alt text and sensible dimensions.
Structured data (JSON-LD) for articles, products, organisation and breadcrumbs.
Internal links, with the same anchors where possible.

The Next.js docs on metadata explain the API. Plugins like Yoast or Rank Math store this data in WordPress, so export it rather than rewriting it by hand.

🛠 Engineering Service

Need specialized help with React & Next.js Development?

Build fast, responsive React and Next.js applications with modern TypeScript architecture, API integrations, reusable components, and production-ready frontend experiences.

Discuss Architecture →About this service

Step 5: Render pages so crawlers can read them#

Use server rendering or static generation for public pages, not client-only rendering. Google can process JavaScript, but delivering complete HTML in the first response is faster and more reliable. Next.js does this by default for Server Components. Check the page source after building, not just what you see in the browser.

Use incremental static regeneration or on-demand revalidation so new posts appear without a full rebuild.

Step 6: Build redirects, sitemap and robots#

Redirects: define them in next.config.js or middleware. For large lists, load them from a file or a database table, and test every one.
Sitemap: generate sitemap.xml from your content source and include only canonical, indexable URLs. Submit it in Search Console.
robots.txt: make sure you do not accidentally carry over a staging "disallow all" rule. This is one of the most common launch mistakes.
Trailing slash and case rules: pick one version and redirect the other.

Step 7: Check performance and Core Web Vitals#

Speed is one of the reasons to migrate, so confirm it. Use next/image for responsive images, load fonts efficiently and avoid shipping heavy client-side JavaScript on content pages. Measure with PageSpeed Insights before and after. A migration that is slower than the original is a failed migration.

Step 8: Test on staging, thoroughly#

Block staging from search engines with authentication, not just a noindex tag that might ship to production. Then:

Crawl staging and compare URLs, titles, canonicals and status codes to your baseline.
Test every redirect from the old URL list.
Validate structured data.
Check forms, search, comments and any plugin-powered features you must replace.

I took a similar approach in rebuilding Tattoo Panda from WordPress to plain PHP with Contentful, where every page was checked against the original. The method is the same whichever stack you move to: compare the new site to the old one page by page.

Step 9: Launch with care#

Choose a low-traffic window and avoid launching alongside a redesign of the copy, which makes cause and effect impossible to separate.
Keep the old server available briefly, in case you need to compare or roll back.
Update DNS, then immediately re-test redirects, robots.txt and the sitemap on the live domain.
Submit the sitemap and use Search Console's URL Inspection on key pages.

Step 10: Monitor for 8 to 12 weeks#

Watch:

Search Console: Pages report for indexing errors, Performance report for impressions and clicks versus your baseline, and crawl stats.
404s from logs and Search Console, adding redirects for any you missed.
Rankings for priority pages.
Analytics: traffic, conversions and form submissions.

A small dip in the first weeks is common as Google re-crawls. A sustained drop after a clean migration usually points to a specific problem, such as missing redirects or changed content, and the baseline helps you find it.

⚠️Warning

Do not change domain, URLs, design and content in the same release. Each is a separate risk. Migrate the platform first, change other things afterwards.

When not to migrate#

If your WordPress site is fast, easy to edit and ranking well, a migration adds risk with limited benefit. Consider it when you need custom application features, outgrow what plugins can safely do or have performance problems that cannot be fixed within WordPress. For a broader look at the decision to change a system versus improve it, see rewrite vs refactor.

Frequently asked questions#

Will I lose rankings when I migrate?#

Not if URLs, content and metadata are preserved and redirects are correct. Temporary fluctuation is normal, but a planned migration should return to baseline.

Can I keep using the WordPress editor?#

Yes, with headless WordPress. You trade some plugin features for a faster front end.

How long does a migration take?#

It depends on the number of templates and features, not just the number of pages. A small brochure site can take weeks; a large site with custom features takes longer.

Do I need to keep my old URLs?#

It is the safest approach. If you change them, use one-to-one 301 redirects and monitor.

Key takeaways#

Inventory every URL, title and ranking before you start.
Keep URLs the same, or map each old URL to its new one with a single 301.
Reproduce metadata, canonicals, structured data and sitemaps, and render HTML on the server.
Test on a protected staging site, launch carefully and monitor for weeks.

If you are planning a WordPress to Next.js move and want it done without a ranking drop, book a call or contact me.

Originally published at aqibjavaid.site.

UPS and FedEx API Integration in Laravel: Real-Time Shipping Rates

Aqib Javaid — Mon, 02 Nov 2026 14:13:24 +0000

If your business ships parcels, showing accurate shipping costs in real time is not optional. Customers abandon carts when shipping is a surprise, and staff waste hours quoting by hand. Both UPS and FedEx publish APIs that return rates for a given package and destination, and wiring them into a Laravel application is very doable. The difficulty is not the first successful request. It is everything that happens when the carrier is slow, the address is wrong or the response format changes.

This guide covers how I approach UPS and FedEx API integration in Laravel, based on building the rate calculation for a logistics quote system. It is part of the broader work I do in API development and integrations.

What the integration needs to do#

Before writing code, be precise about the job. A quote engine has to:

Accept package details (weight, dimensions, quantity) and origin and destination addresses.
Ask each carrier for its available services and prices.
Convert the different responses into one common format.
Show the user the options, and store the quote so it can be sent, accepted or audited later.
Keep working, with a clear message, when a carrier is unavailable.

On the EXPRECO logistics quote system, I built this in Laravel and Livewire, integrating UPS and FedEx APIs to calculate real-time shipping rates from package details and destination, plus a ticketing workflow so businesses could respond to customers and share quotes from the platform.

Step 1: Get credentials and read the docs#

Both carriers require a developer account and application credentials. Their authentication has moved toward OAuth 2.0 client credentials, so check the current documentation rather than relying on older tutorials that describe retired access-key methods. The official portals are the UPS Developer Portal and the FedEx Developer Portal.

Practical notes:

Start in the sandbox environment. Rates there may not match production, so validate with real accounts before launch.
Decide whether you need published rates or your negotiated account rates. They are different requests with different credentials.
Read the terms about caching and displaying rates. Some programmes have rules.

Step 2: Build a carrier abstraction#

Do not scatter HTTP calls through controllers. Create a small interface that every carrier implements:

php

Copy

interface RateProvider
{
    /** @return Collection<int, RateQuote> */
    public function quote(ShipmentRequest $request): Collection;
}

Then write a UpsRateProvider and a FedExRateProvider that translate your ShipmentRequest into each carrier's payload and map the response into a common RateQuote object (carrier, service name, price, currency, estimated delivery, raw reference ID). A third carrier later becomes one new class instead of a rewrite.

Step 3: Handle authentication tokens properly#

OAuth access tokens are short-lived. Request one, cache it in Laravel's cache until shortly before expiry, and reuse it for every call. Requesting a new token on each rate request wastes time and can trigger rate limits.

🛠 Engineering Service

Need specialized help with API Development & Integrations?

Design and integrate reliable APIs connecting your application with third-party platforms, business systems, payment providers, and external data sources.

Discuss Architecture →About this service

php

Copy

$token = Cache::remember('fedex.token', $ttlSeconds - 60, function () {
    return $this->requestNewToken();
});

Wrap the call so that a 401 response clears the cached token and retries once. Keep client IDs and secrets in environment variables, never in the repository.

Step 4: Use Laravel's HTTP client with timeouts and retries#

The HTTP client makes timeouts and retries a one-liner, and it is where reliability starts:

php

Copy

$response = Http::withToken($token)
    ->timeout(8)
    ->retry(2, 200, throw: false)
    ->post($url, $payload);

Choose timeouts that suit the user experience. A checkout page cannot wait 30 seconds. If the carrier does not answer in time, show the other carrier's rates or a fallback, rather than failing the whole page.

Call both carriers in parallel using Http::pool() so the user waits for the slowest one, not the sum of both.

Step 5: Normalise and validate the response#

Carriers return different structures, units and service codes. Map them carefully:

Convert currencies and rounding in one place.
Translate service codes into names your users understand.
Reject responses with missing prices instead of showing zero.
Log the raw request and response identifiers so you can debug disputes.

Validate input before you call anyone. Missing postcodes, impossible weights and bad dimensions are the most common causes of carrier errors. Show the user a plain message and let them correct it.

Step 6: Cache sensibly#

Identical requests (same package, same route) within a short window can reuse results. A cache key built from the normalised request and a short TTL cuts calls and speeds up the UI. Keep the TTL short, since rates can change with fuel surcharges and service levels, and check each carrier's terms. My notes on Redis caching architecture in Laravel cover key design and invalidation.

Step 7: Plan for failure#

Carrier APIs go down and return odd errors. Decide up front what the user sees:

One carrier fails: show the other's rates, with a note if relevant.
Both fail: allow the quote to be saved as "pending" and processed by a queued job, or let staff quote manually.
Address problems: surface the carrier's message in plain language.

Also respect carrier rate limits. If many users hit your quote form at once, you may need to queue requests or throttle them. My article on API rate limiting architecture covers the incoming side of the problem, and the same ideas of back-off and limits apply when you are the client.

ℹ️Note

Always store the quote you showed the customer. If the price changes by the time they accept it, you need the original to resolve the dispute.

Step 8: Test without hitting the carrier#

Use Http::fake() to return recorded sample responses in your test suite so tests are fast and deterministic. Keep a handful of real recorded payloads for edge cases: oversized packages, remote areas, multi-package shipments. Add a few sandbox tests you run manually before each release.

Shipping rates vs full shipping#

Rates are the easiest part. Creating labels, tracking shipments, handling customs documents for international orders and managing returns all add separate integrations. Decide on scope early so a "show me rates" project does not quietly become a logistics platform. For an overview of how integration projects are scoped and what influences their cost, read API integration cost and timeline, and for general design rules see third-party API integration best practices.

Frequently asked questions#

Should I use a shipping aggregator instead of direct carrier APIs?#

An aggregator gives you many carriers through one integration and may include labels and tracking. The trade-off is fees and less control. Direct APIs make sense when you use one or two carriers and want negotiated rates and full control.

Do I need Livewire or a frontend framework?#

No. The integration is backend work. Livewire is convenient for live quote forms, but a standard form or a JavaScript client works equally well.

How accurate are the rates?#

Accuracy depends on the data you send and the account credentials used. Wrong dimensions or addresses produce wrong prices, and surcharges may appear later. Validate input and store the original quote.

How long does an integration like this take?#

A single carrier's rate lookup is usually days of work. Two carriers with a clean abstraction, error handling and tests is more. Labels and tracking add more again.

Key takeaways#

Wrap each carrier behind a common interface and return one normalised quote format.
Cache OAuth tokens, set timeouts, retry sensibly and call carriers in parallel.
Decide what happens when a carrier fails before you launch.
Store every quote shown to a customer, and test with faked responses.

If you need rates or full shipping integrated into your application, book a call or get in touch.

Originally published at aqibjavaid.site.

RAG vs Fine-Tuning for a Business Chatbot: Which to Choose

Aqib Javaid — Mon, 02 Nov 2026 14:12:55 +0000

When a business decides it wants an AI chatbot that "knows our company," the next question is usually technical: should we fine-tune a model on our data, or use retrieval-augmented generation (RAG)? The two are often described as competitors. They solve different problems, and for most business chatbots the answer is clear once you ask the right questions. This is the framework I use when advising on AI integration projects.

The short answer: use RAG for knowledge, use fine-tuning for behaviour. If your goal is for the bot to answer questions about your products, policies or documents correctly, start with RAG.

What each approach actually does#

RAG: look it up, then answer#

In retrieval-augmented generation, your documents are split into chunks and turned into embeddings that are stored in a vector index. When a user asks a question, the system finds the most relevant chunks, adds them to the prompt and asks the model to answer using only that context. The model's weights are not changed.

Fine-tuning: change the model#

Fine-tuning continues training a model on examples you provide. It changes how the model writes or behaves: tone, format, handling of a specific task. It is not a reliable way to teach it a large body of changing facts, and a fine-tuned model can still produce confident wrong answers about those facts.

The questions that decide it#

How often does your knowledge change?#

Prices, policies, documentation and product details change. With RAG, you update a document and the bot knows within minutes of re-indexing. With fine-tuning, you must prepare new training data and run training again. If your information changes monthly or faster, RAG is the practical choice.

Do answers need to be traceable?#

For support, compliance or anything where "where did that come from?" matters, RAG lets you show the source passages and link to them. A fine-tuned model cannot cite what it learned, because that knowledge is spread across its weights.

Who needs to control what the bot says?#

With RAG, you can restrict the bot to a defined set of documents, add topic rules and handle "I don't know" cleanly. On the Henceforward AI chatbot and knowledge base, I built an admin suite for brand persona, topic restrictions and AI guardrails around a RAG pipeline that ingests web pages, documents and visual assets. Business owners needed control without involving a developer each time the content changed, which is a RAG strength.

What are you trying to change: facts or style?#

Goal	Better fit
Answer questions from company documents	RAG
Keep answers current as content changes	RAG
Cite sources to the user	RAG
Match a specific writing tone or output format	Fine-tuning (or careful prompting)
Perform a narrow classification or extraction task at scale	Fine-tuning
Reduce prompt size for a repeated task	Fine-tuning

What can you afford to maintain?#

RAG has ongoing work: ingestion pipelines, chunking, an index, evaluation. Fine-tuning has its own: dataset curation, training runs, evaluation and re-training when the base model changes. Neither is free, but RAG's costs are usually easier to predict for knowledge-heavy bots. For budgeting guidance, see AI chatbot development cost.

🛠 Engineering Service

Need specialized help with AI Integration & AI-Powered Applications?

Integrate AI into existing products or build AI-powered applications that automate workflows, analyze data, generate content, and improve business operations.

Discuss Architecture →About this service

Why RAG is the default for business knowledge#

Freshness. Update the source, not the model.
Control. You decide what the model can see.
Auditability. You can log which passages produced each answer.
Lower risk of hallucination when the prompt requires answers to come from the supplied context. It reduces, but does not eliminate, wrong answers.
Model portability. Your knowledge base is yours. You can swap the language model later without retraining.

Where RAG goes wrong#

RAG is not magic. Most "the bot gave a wrong answer" reports I debug trace back to retrieval, not the model: poor chunking, missing documents, ambiguous queries, or no instruction on what to do when nothing relevant is found. I cover the diagnosis steps in fixing RAG chatbot wrong answers. The index choice also matters at larger scale, which I compare in pgvector HNSW vs IVFFlat.

💡Tip

Before you tune anything, build a small set of real questions with known good answers. It is the cheapest way to tell whether a change helped or hurt.

When fine-tuning makes sense#

Fine-tuning earns its place when you have a narrow, repeatable task and a clean set of examples, such as extracting fields in a fixed format, classifying tickets into your categories, or writing in a very specific voice at volume. Even then, try careful prompting and a few examples in the prompt first. Fine-tuning adds a training pipeline you have to own.

The combined approach#

Many mature systems use both: a fine-tuned or well-prompted model for tone and structure, with RAG supplying the facts. If you are starting out, build RAG first. It gets you to useful faster and tells you where fine-tuning might add value.

For general background on the technique, the original paper is Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, and Anthropic's documentation on embeddings explains how retrieval fits into an application.

A practical way to start#

Collect the 20 to 50 questions your users actually ask.
Gather the documents that contain the answers, and note gaps.
Build a basic RAG pipeline with source citations.
Test it against your question list and record failures.
Add guardrails: scope limits, refusal behaviour and handoff to a human.
Only consider fine-tuning if the remaining failures are about behaviour, not knowledge.

This is how production features are built. I talk about the habits that separate demos from reliable systems in production-grade AI features. On SafetySpace, the AI sits inside configurable safety workflows where reliable access to information matters, which is a similar kind of problem.

Frequently asked questions#

Can a fine-tuned model replace a knowledge base?#

Not reliably. It may reproduce some facts but cannot guarantee accuracy or point to a source, and it goes stale as your information changes.

Is RAG more expensive than fine-tuning?#

It depends on volume. RAG adds retrieval and larger prompts per request. Fine-tuning adds training and evaluation costs up front. For most business chatbots, RAG is cheaper to launch and easier to keep current.

Does RAG stop hallucinations?#

It reduces them by grounding answers in your documents, but it does not remove them. You still need clear "I don't know" behaviour and testing.

Do I need a vector database?#

Not necessarily. For many projects, Postgres with the pgvector extension is enough, and it keeps your stack simple.

Key takeaways#

RAG is for knowledge; fine-tuning is for behaviour.
Choose RAG when information changes, answers must be sourced or content owners need control.
Most wrong answers come from retrieval, so test against real questions.
Start with RAG, and add fine-tuning only for a clearly defined behavioural gap.

If you are planning a chatbot and want to choose the right architecture, book a call or contact me.

Originally published at aqibjavaid.site.

GoHighLevel Stripe Integration: Charge Leads Automatically

Aqib Javaid — Mon, 02 Nov 2026 14:12:46 +0000

GoHighLevel is excellent for managing leads, pipelines and follow-up. Billing is where agencies hit its limits. If you sell leads and want to charge each client when a qualified lead is delivered, a flat subscription does not fit, and charging by hand does not scale. This guide explains how a GoHighLevel Stripe integration for pay-per-lead billing works, based on a workflow I built for a lead-generation business. Custom work like this sits within my API development and integrations service.

The core idea: let the client save a payment method once without paying anything, then charge it automatically whenever an event in GoHighLevel says a lead has been delivered. Everything between those two moments needs to be safe, idempotent and visible to both systems.

The problem with the built-in options#

Native payment links and invoices assume the amount is known up front. Pay-per-lead billing breaks that assumption in three ways:

The amount depends on how many qualified leads are delivered.
Charges happen later, when the client is not on the page.
Failures matter: a declined card means a lead was delivered and not paid for.

So you need a flow that separates "authorise the card" from "take the money", and a link between payment results and the CRM.

The architecture in one picture#

The client receives a secure link and enters card details on a page that uses Stripe.js, so card numbers never touch your server.
A SetupIntent saves the card against a Stripe customer, with no charge.
When a lead is marked as delivered in GoHighLevel, a trigger calls your integration.
Your service creates an off-session PaymentIntent for the saved card.
Stripe sends webhooks for success or failure, and your service updates GoHighLevel so the pipeline reflects reality.

This is the pattern behind the Stripe lead billing workflow I built for a GoHighLevel client: a secure flow that saves payment methods without an immediate charge, charges them automatically when qualified leads are delivered, and uses webhook-driven status synchronisation for successful and failed payments.

Step 1: Save the card with a SetupIntent#

A SetupIntent is Stripe's way to collect a payment method for future use. You create a Stripe customer, create a SetupIntent for that customer, and confirm it on the client side with Stripe.js. Once confirmed, the payment method is attached to the customer.

Things that matter here:

Ask for the right usage (off_session) so the card can be charged when the client is absent.
Handle authentication (3D Secure) at setup time, so later charges are less likely to be interrupted.
Store the Stripe customer ID and payment method ID against the CRM contact, as custom fields or in your own database.

Stripe documents this flow in its guide to saving payment details.

Step 2: Trigger charges from GoHighLevel#

GoHighLevel can call an external URL when something happens, for example when an opportunity moves to a "Lead delivered" stage. Use that trigger to send a request to your own endpoint with the contact ID and the amount or lead count. Options include a webhook action in a workflow or an automation tool such as Zapier if you prefer to keep logic outside custom code.

🛠 Engineering Service

Need specialized help with API Development & Integrations?

Design and integrate reliable APIs connecting your application with third-party platforms, business systems, payment providers, and external data sources.

Discuss Architecture →About this service

Do not let the CRM decide the amount blindly. Your endpoint should:

Verify the request really came from your workflow (a shared secret or signature).
Look up the contact's saved Stripe customer and payment method.
Calculate the amount on the server from trusted data.
Create the PaymentIntent with off_session: true and confirm: true.

Step 3: Make charges idempotent#

Automations retry. Workflows fire twice. Networks time out. If your endpoint can be called twice for the same lead, you must never charge twice.

Use an idempotency key derived from the lead or opportunity ID when creating the PaymentIntent. Stripe will return the original result for repeated requests with the same key. I wrote about the same idea for APIs in general in idempotency keys in Laravel APIs, and the principle applies to any stack.

📌Important

Record each charge attempt in your own database before calling Stripe. If the call or response is lost, you still have a record to reconcile.

Step 4: Use webhooks as the source of truth#

A synchronous response from Stripe tells you what happened right now. Webhooks tell you what is true. Some payments finish later, some need further action and some fail after initially looking fine.

Subscribe to events such as payment_intent.succeeded and payment_intent.payment_failed, then:

Verify the signature on every webhook using Stripe's signing secret.
De-duplicate events by event ID, because Stripe may deliver the same one more than once.
Update GoHighLevel through its API: move the opportunity, set a "Paid" or "Payment failed" tag, or write a custom field.

I have written a full walkthrough of safe webhook handling in Stripe webhooks: verify, dedupe, retry. The principles are not specific to Laravel, and Stripe's own webhook documentation covers signature verification in several languages.

Step 5: Plan for failed payments#

Failures are not an edge case in pay-per-lead billing. Decide up front:

What happens when a card is declined? Notify the client, pause new lead delivery or both.
How is a retry handled? Offer a link to update the card, then re-attempt the failed charge.
Who sees it? Your team should get an alert, and the CRM record should show the state, so nobody has to open Stripe to find out.
What about disputes and refunds? Make sure refunds update the CRM status too.

Make the payment state visible inside GoHighLevel. A pipeline that shows "Delivered, paid" or "Delivered, payment failed" is what makes the integration useful for the people who work in it daily.

What it costs to build#

A basic version, with one Stripe account, one card-saving page, one trigger and two webhook events, is a small project. It grows with more pricing rules (tiers, discounts, credits), multi-account or multi-currency needs, invoicing and reporting. For general guidance on estimating this kind of work, see API integration cost and timeline.

When not to build this#

If you charge a fixed monthly fee, Stripe Billing subscriptions are simpler and need no custom charge logic.
If volume is a handful of clients, manual invoicing may be fine until it hurts.
If you cannot hold customer card data under your compliance comfort level, keep everything with Stripe-hosted components and never store card details yourself.

Frequently asked questions#

Does GoHighLevel connect to Stripe natively?#

It has a native Stripe connection for its own payment features, such as invoices and products. Charging on a custom trigger like "lead delivered" usually needs extra logic through workflows or custom code.

Is it safe to charge a saved card without the customer present?#

Yes, if the customer authorised future charges when saving the card and you follow Stripe's off-session flow. Be clear in your terms about what will be charged and when.

What if a charge needs authentication?#

Off-session payments can fail if the bank demands authentication. Handle the resulting error by sending the customer a link to complete it.

Can I do this with Zapier instead of code?#

For simple flows, yes. For anything involving idempotency, signature checks and reconciliation, custom code is more reliable.

Key takeaways#

Separate saving the card (SetupIntent) from charging it (off-session PaymentIntent).
Make the charge endpoint idempotent and calculate amounts on the server.
Treat Stripe webhooks as the source of truth and sync results back to GoHighLevel.
Design the failed-payment path before launch, not after the first decline.

If you need a billing workflow like this connected to your CRM, book a call or contact me.

Originally published at aqibjavaid.site.

Laravel Production Deployment Checklist: 25 Things to Check

Aqib Javaid — Mon, 02 Nov 2026 14:12:17 +0000

Most Laravel launch problems are not exotic. They are a missed environment variable, a queue worker that was never started, a debug page left switched on, or a migration that locked a table. This Laravel production deployment checklist is the list I run through before and after a go-live. It works whether you deploy with a managed tool, a container platform or your own server. If you want help doing it, my cloud and DevOps deployment service covers exactly this kind of work.

Use it as a working document: copy it into your repository and tick items off per release.

Before you deploy: environment and configuration#

APP_ENV=production and APP_DEBUG=false. Debug mode can leak stack traces, environment values and queries to anyone who triggers an error.
A unique APP_KEY generated for production and stored outside the repository. Never reuse the development key.
Secrets live in the environment, not in committed files. Rotate anything that was ever pushed to a repository.
APP_URL is correct, including the scheme, so generated links and signed URLs work.
Cache the configuration. Run php artisan config:cache, route:cache, view:cache and event:cache as part of the deploy. After config:cache, only call env() inside config files, because it returns null elsewhere.
Optimise the autoloader: composer install --no-dev --optimize-autoloader on the server or in your build.

The Laravel docs describe each of these in the official deployment guide.

Security checks#

HTTPS everywhere, with HTTP redirected, and Secure and HttpOnly cookie flags set.
Only the public directory is web-reachable. Your .env, storage and vendor folders must never be served.
Trusted proxies configured if you sit behind a load balancer or CDN, otherwise client IPs and HTTPS detection break.
Rate limiting on login and API routes. I cover design choices in API rate limiting architecture.
Dependencies audited: run composer audit and update anything with a known vulnerability.
Admin areas protected with strong authentication, and ideally restricted by role, network or both.

⚠️Warning

If .env was ever reachable over HTTP, treat every secret in it as compromised and rotate it.

Database and migrations#

Back up before you migrate, and confirm you can restore. A backup you have never restored is a hope.
Run migrations with --force in production, as part of the deploy script, not by hand.
Check migrations for locking. Adding an index or altering a large table can block writes. Use the safe patterns: add nullable columns first, backfill in batches, then add constraints.
Make migrations backward compatible with the code that is currently running, so a rolling deploy does not break mid-flight. The expand-then-contract approach covers it.
Database credentials use a least-privilege user, not root.

Queues, scheduler and background work#

Run a process supervisor (Supervisor or systemd) for queue workers so they restart after a crash or deploy.
Restart workers on each deploy with php artisan queue:restart, otherwise they keep running old code.
Add the scheduler cron entry: * * * * * php /path/artisan schedule:run. Missing this is a classic launch bug.
Set job timeouts and retry limits, and watch the failed jobs table. For heavier workloads I use Redis and Horizon, which give visibility into throughput and failures.

On the Violerts NYC platform, the stack includes Redis, Laravel Horizon and asynchronous processing. Any system built that way depends on supervised workers that restart cleanly on deploy, which is why I treat this section of the checklist as non-negotiable.

🛠 Engineering Service

Need specialized help with Cloud, DevOps & Deployment?

Set up and improve production infrastructure for web applications, including VPS environments, Docker, CI/CD, web servers, migrations, and reliable deployments.

Discuss Architecture →About this service

Performance and caching#

Use a real cache and session driver such as Redis in production, not file on a multi-server setup.
Run OPcache with sensible settings, and clear or reset it on deploy.
Serve assets through a CDN or at least with long-lived cache headers and hashed filenames.

Deploy process, monitoring and rollback#

Make deploys repeatable. A script or pipeline should do the same steps each time: pull, install, build, migrate, cache, restart. Doing it by hand invites mistakes. See zero-downtime deployments in Laravel for the release-directory approach with atomic switching.

Beyond the numbered list, these matter just as much:

Error tracking such as Sentry, so exceptions reach you before customers do.
Uptime and health checks on a route that also tests the database and cache.
Structured logs sent somewhere you can search. See observability for Laravel.
A rollback plan. Know which release to go back to and whether the database changes can be reversed. If a migration cannot be undone, plan a forward fix.
Disk and memory alerts. Full disks and log files are a common silent failure.

A simple deploy sequence#

Here is a minimal pattern that covers the essentials:

bash

Copy

git pull origin main
composer install --no-dev --optimize-autoloader --no-interaction
npm ci && npm run build
php artisan down --retry=30   # skip if you do atomic releases
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache
php artisan queue:restart
php artisan up

This is a starting point. With zero-downtime tooling, you build into a new release directory and switch a symlink instead of using maintenance mode.

Post-deploy smoke test#

Right after a release, check:

Home page, login and one key transaction work.
A queued job runs to completion.
A scheduled command appears in the logs.
No new errors are showing in your tracker.
Emails send, using a real test address.

On the Henceforward WordPress migration, moving to a new infrastructure on Scaleway with Laravel Forge meant that the checks around server configuration, security and production optimisation were as important as the application itself. The same discipline applies to a Laravel app: the environment is part of the product.

If you are still choosing where to host, read my comparison of Laravel hosting options and cost.

Frequently asked questions#

Should I use `php artisan down` for every deploy?#

Only if you cannot do atomic releases. Maintenance mode shows users an error page, so for busy sites a symlink-based zero-downtime release is better.

Why does `config:cache` break my app?#

Because env() returns null outside config files once the config is cached. Read environment values in config files and use config() everywhere else.

How often should I back up?#

At a frequency matching how much data you can afford to lose. Before every migration, and on a schedule for everything else, with periodic restore tests.

Do I need Kubernetes?#

Usually not. Many Laravel apps run well on a single well-configured server or a managed platform. Pick complexity when the load demands it.

Key takeaways#

Debug off, secrets safe, config cached, HTTPS on: the basics prevent most launch incidents.
Back up before migrating, and write migrations that are safe for running code.
Supervise queue workers, restart them on deploy, and add the scheduler cron.
Automate the deploy, monitor errors, and know your rollback before you ship.

If you would like a second pair of eyes on a launch, book a call or get in touch.

Originally published at aqibjavaid.site.

Web Scraping vs Official API: Which Should You Use?

Aqib Javaid — Mon, 02 Nov 2026 14:12:08 +0000

When a business needs data that lives on someone else's website, the first instinct is often "let's scrape it." Sometimes that is right. Often there is an API, export or data feed that gives you the same information with far less risk and far less upkeep. This article gives you a practical way to choose between web scraping vs an official API, based on what I check before I recommend either one to a client. If scraping turns out to be the answer, my web scraping and data extraction service covers how I build it.

The short version: use the API when one exists and covers what you need; scrape when it does not, and build it as if it will break.

The six questions that decide it#

1. Does an API exist, and does it cover the fields you need?#

Start here, because it takes ten minutes. Look for developer documentation, a public data portal, an export button or a partner programme. Check the specific fields you need, not just whether an API exists. Many APIs expose a subset of what the website shows. If the API covers your fields, the decision is usually already made.

2. What does the provider allow?#

Terms of service, licences and rate limits tell you what the owner permits. An API usually comes with explicit permission. Scraping may be restricted by the site's terms, and the data itself may carry licence or privacy obligations. I go through the legal side in is web scraping legal for business. This is not legal advice, and you should get it for anything sensitive.

3. How stable does it need to be?#

APIs are contracts. They are versioned, documented and usually changed with notice. Websites are not contracts. A redesign can break a scraper overnight with no warning. If a process depends on the data arriving every day, stability points strongly toward the API.

4. What will it cost to run, not just to build?#

Compare the full cost over a year:

Cost item	Official API	Scraping
Build effort	Usually lower, structured responses	Higher, parsing and edge cases
Fees	May charge per request or by plan	Usually free to fetch, but infrastructure is yours
Maintenance	Low, follow version notices	Ongoing, fixes when pages change
Infrastructure	Light	Heavier if headless browsers or proxies are needed
Monitoring	Basic error checks	Needs validation and alerts for silent breakage

An API with a monthly fee can still be cheaper than a free scraper once you count maintenance time.

5. How fresh and how complete must the data be?#

APIs often give real-time or near-real-time data and clean identifiers. Scraped pages may lag, paginate oddly or hide records behind filters. If you need complete history or reliable IDs to match records, an API is easier to trust.

🛠 Engineering Service

Need specialized help with Web Scraping & Data Extraction?

Architect resilient, high-volume automated scrapers and data pipelines that bypass anti-bot protections, extract structured public data, and deliver clean, validated feeds to your database.

Discuss Architecture →About this service

6. What happens if access is cut?#

APIs can be withdrawn or repriced. Scrapers can be blocked. Either way, have a fallback plan. For anything critical, I design the integration so that the data source can be swapped without rewriting the rest of the system.

What the API route looks like in practice#

Integrating a real API is still real engineering. On the EXPRECO logistics quote system, I integrated UPS and FedEx APIs into a Laravel and Livewire application to calculate real-time shipping rates from package details and destination. That is exactly the kind of data you would never want to scrape from a carrier's website: it is dynamic, account-specific and dependent on rules you cannot see. The official APIs were the only sensible route.

The work in an API integration is mostly in the edges: authentication, rate limits, error handling, retries and mapping the provider's model to yours. I list the practices I rely on in third-party API integration best practices.

When scraping is the right answer#

Scraping earns its place when:

No API exists for data that is legitimately public.
The API is incomplete, missing fields that the public page shows.
The API is priced out of reach for your use, and the public data is allowed to be collected.
You are collecting from many different sources that each lack a consistent API, such as local government portals.

That last case is common. On the Violerts NYC compliance platform, data comes from multiple municipal sources with different formats, and the ingestion layer needed to handle that variety. I wrote about the engineering that makes this work in a resilient scraping system for government data sources.

If you do scrape, assume it will break and design for it: validation of every record, alerts when output shape changes, retries, and isolation between sources. Cost estimates for a custom scraper depend heavily on how much of that resilience you need.

A hybrid approach often wins#

You are not forced to pick one. Common patterns:

API first, scraper as gap-filler for fields the API omits.
Scraper as a prototype while you apply for API access, then switch.
Official bulk export plus a light scraper for the freshest records.

Using several sources also gives you a way to cross-check data, which helps quality.

Practical steps before you commission anything#

Search for developer docs, data portals and export options for the target.
List the exact fields you need and check each against the API.
Read the terms of service and any licence for the data.
Estimate the 12-month cost for each route, including maintenance.
Decide how you will detect and handle a source going away.

You can check the target site's crawling rules via its robots.txt file. Google explains how robots.txt works, and the format is a convention, not a legal permission, so treat it as one input and not the whole answer.

Frequently asked questions#

Is scraping cheaper than using an API?#

Not necessarily. Scraping is free to fetch but expensive to maintain. Once you add monitoring and fixes, a paid API is often cheaper over a year.

Can a website block my scraper?#

Yes, and sites often do. That is one more reason to prefer an API when you depend on the data.

Is using an undocumented internal endpoint the same as an API?#

No. It may return clean JSON, which helps, but it is not a supported contract and can change without notice. Treat it as scraping for risk purposes.

What should I ask a developer before they start?#

Ask which route they recommend and why, how failures will be detected, and who maintains it afterwards.

Key takeaways#

Check for an official API or data feed first; it takes minutes and can save months.
Compare 12-month cost, not just build cost.
Scrape only legitimate public data, and design as if the source will change.
A hybrid of API plus scraper is often the most robust option.

If you are unsure which route fits your data need, book a call and I will look at the sources with you, or send me the details.

Originally published at aqibjavaid.site.

How Much Does a Custom Web Scraper Cost to Build?

Aqib Javaid — Mon, 02 Nov 2026 14:11:38 +0000

"How much does a custom web scraper cost?" is one of the most common questions I get, and the only honest first answer is: it depends on five things that you can mostly list before you talk to a developer. A scraper that pulls one public page into a spreadsheet is a few hours of work. A system that collects data from a dozen sources every day, fixes itself when a site changes and delivers clean records to your database is a small product.

This guide explains what drives custom web scraper development cost, so you can scope the job properly, compare quotes fairly and avoid paying for the wrong thing. I will not quote prices I cannot back up, and if you want a scoped estimate for your own sources, that is what my web scraping and data extraction service starts with. I will show you where the effort goes, because the effort is what you are paying for.

The five cost drivers#

1. How many sources and how different they are#

Each website is its own small project. Ten pages on one site share most of the work. Ten sites mean ten sets of selectors, ten sets of edge cases and ten things that can break. A useful rule: cost scales with the number of distinct sources far more than with the number of records.

2. How the data is delivered#

A plain HTML page that returns the data in the response is the cheapest case. Sites that build everything in the browser with JavaScript need a headless browser such as Playwright, which is slower, heavier and more fragile. Sometimes the site calls a JSON endpoint behind the scenes, and using that endpoint is both cheaper and more reliable than parsing pages. Part of any good scoping exercise is simply looking at the network traffic to find the cheapest honest way to get the data.

3. Defences and access rules#

Login walls, rate limits, CAPTCHAs and bot detection all add work, and some should add caution. Before building anything I check the site's terms and what the data actually is. I covered the legal side in is web scraping legal for business. If an official API or data feed exists, it is often the better choice, because it is stable and explicitly allowed.

4. Volume and frequency#

Fetching 500 pages once a week is trivial. Fetching 500,000 pages daily needs queues, concurrency control, retries, proxies where permitted, storage and monitoring. Frequency matters too: a daily job needs to finish reliably before the next one starts.

5. What happens after the scrape#

Raw HTML is not a deliverable. The real work is often cleaning, de-duplicating, matching records to your existing data, and detecting what changed. If you want to know when something changes rather than just receiving a dump, see my notes on change detection for scraped data. A pipeline with validation and alerts costs more than a script, and it is the thing that keeps the data trustworthy.

Three typical scopes#

Scope	What it looks like	Where the effort goes
One-off extraction	A single site, run once or occasionally, output as CSV	Finding the right data source, cleaning output
Recurring feed	A few sources, scheduled runs, data loaded into your database	Scheduling, retries, de-duplication, basic monitoring
Data product	Many sources, change tracking, alerts, an admin view, an API	Architecture, resilience, ongoing maintenance

These are categories, not price points. A developer who gives you a number without asking which of the three you need has not understood the job.

🛠 Engineering Service

Need specialized help with Web Scraping & Data Extraction?

Architect resilient, high-volume automated scrapers and data pipelines that bypass anti-bot protections, extract structured public data, and deliver clean, validated feeds to your database.

Discuss Architecture →About this service

Reliability is the expensive part#

Anyone can get a scraper to work once. What you pay a senior engineer for is making it keep working. Sites change markup, move endpoints and throttle clients. A production scraper needs:

retries with back-off, so a temporary failure does not lose data;
validation, so a changed page produces an alert instead of a column of empty values;
logging that shows which source failed and why;
isolation, so one broken source does not stop the others.

On the Violerts NYC compliance platform, I worked on multi-agency data ingestion with asynchronous scraping and real-time alerts on a Laravel backend. In that kind of system the scraping itself is only one layer. Most of the design effort goes into what surrounds it: queues, error handling and making failures visible. I wrote about the same problem in building a resilient scraping system for government data sources.

ℹ️Note

If a vendor promises a "set and forget" scraper, treat that as a warning. Websites change, so any scraper that matters needs someone responsible for it.

What to budget after launch#

Ongoing cost is the number people forget. Plan for:

Maintenance time when a source changes. The more sources, the more frequent this is.
Infrastructure: servers or containers, storage, and proxy or browser services if they are needed and permitted.
Monitoring: someone, or something, has to look at the alerts.

A reasonable approach is to treat the first build and the first few months of upkeep as one budget. For a general view of how to think about running costs, see what to budget for software maintenance.

How to get a fair quote#

Send a prospective developer a short brief with:

The list of source URLs, and which fields you need from each.
How often you need fresh data, and how fast it must arrive.
Where the data should end up (spreadsheet, database, API, dashboard).
What you will do if a source disappears or blocks access.
Whether you have checked that you are allowed to collect it.

With that, you can ask for a fixed-scope first phase, usually one or two sources end to end, then expand. It shows you the real behaviour of the sources before you commit to the whole project.

When not to build a scraper#

An official API, export or data feed exists. Use it.
The data is licensed and scraping would breach the licence. Buy access instead.
You need it once, from a small number of pages. Copying manually or using a no-code tool may be cheaper.
The source is personal data and you have no lawful basis to collect it. Do not scrape it.

Check Google's own guidance on robots.txt to understand how sites signal their crawling rules, and read the target site's terms before you plan anything.

Frequently asked questions#

Is a cheap scraper from a freelance marketplace a good idea?#

It can be for a one-off. For anything recurring, the cost is in reliability and maintenance, not the first working version. Ask how failures will be detected.

Should I use a scraping API service instead?#

Sometimes. Managed services handle proxies and browsers for you, but you still pay per request and still need parsing, validation and storage. Whether it is cheaper depends on your volume.

How long does a recurring scraper take to build?#

A single-source recurring feed can often be done in days. A multi-source data product takes weeks, mostly spent on resilience and data quality.

Who owns the code?#

You should. Ask for the source code, deployment notes and documentation as part of the engagement.

Key takeaways#

Cost follows the number of distinct sources, the delivery method, defences, volume and the post-scrape pipeline.
Reliability and monitoring are what you are really paying for.
Budget for maintenance as part of the project, not as an afterthought.
Check legality and look for an official API before building anything.

If you have a list of sources and want a scoped first phase, book a call or contact me. You can also read more about my web scraping and data extraction service.

Originally published at aqibjavaid.site.

Legacy PHP Application Modernization Cost: What to Expect

Aqib Javaid — Mon, 02 Nov 2026 14:11:28 +0000

If you own a PHP application that has been running for years, you have probably been quoted a number for "modernizing" it and wondered what is inside that number. The honest answer is that legacy PHP application modernization cost depends far more on how the system is built than on how big it is. Two applications with the same number of screens can differ by a factor of three or four in effort.

This article explains what actually moves the price, how I size a modernization before anyone commits budget, and how to phase the work so you are never betting everything on a single estimate. I am not going to give you a single magic figure, because any number without an audit behind it is a guess.

What "modernization" actually means#

People use the word for very different jobs, and the price follows the job:

Version upgrade: moving to a supported PHP version and a current framework release, with the existing structure kept.
Refactor in place: adding tests, extracting business logic from templates, and cleaning up the data layer without changing what users see.
Strangler-style migration: replacing the application piece by piece behind the same URLs, usually onto Laravel, while the old code keeps running.
Full rewrite: building a new system and cutting over.

Most buyers want the outcome of a rewrite at the price of an upgrade. The useful question is which of these four your business problem actually needs. If the pain is that the server runs an unsupported PHP version, you do not need a rewrite. If the pain is that every change breaks something else, an upgrade alone will not fix it. This is the kind of question my legacy application modernization service starts with. I cover that decision in more depth in rewrite vs refactor for a legacy application.

The five factors that drive cost#

1. Test coverage (or the lack of it)#

This is the biggest single driver. An application with a decent automated test suite can be upgraded and refactored safely, because the tests tell you what broke. An application with none means every change needs manual verification, and manual verification is slow and expensive. Often the first piece of paid work should be building characterization tests around the riskiest flows, such as checkout, billing or anything that moves money.

2. How logic is organised#

Business rules buried in templates, in SQL strings, or in a 4,000-line include file are expensive to move. Code that already has clear boundaries (even if the style is dated) costs much less. When I audit a system I look for where the rules live, not how pretty the code is.

3. The database#

Schemas that have grown without constraints, with duplicated data and unclear ownership, create most of the nasty surprises. Migrating code is predictable. Migrating data you do not fully understand is not. Reviewing the schema early is the cheapest risk reduction available.

4. Dependencies and integrations#

Old Composer packages that were abandoned years ago, payment gateways on retired API versions, and hand-rolled integrations all need attention. Each external system is a small project of its own.

5. Downtime tolerance#

If the business can accept a maintenance window, cutover is simple. If it cannot, you need parallel running, feature flags or a strangler approach, and that adds engineering time.

🛠 Engineering Service

Need specialized help with Legacy Application Modernization?

Modernize aging PHP and Laravel applications without disrupting existing business operations, improving architecture, performance, security, and maintainability.

Discuss Architecture →About this service

How I size a modernization before quoting it#

A reliable estimate comes from an audit, not from a sales call. On the freight-forwarding platform audit, I was brought in to review a nearly finished Core PHP and MySQL system before further development. The work was understanding first: auditing operational workflows, reviewing the database structure, assessing frontend maintainability, mapping dependencies and evaluating configuration and environment governance, then assessing the path towards a future Laravel migration. The point of that phase was to replace assumptions with a written map.

A good audit typically produces:

An inventory of modules, routes and external integrations.
A risk list ranked by business impact, not by code ugliness.
A proposed phase plan with a rough effort band for each phase.
A clear list of what is out of scope.

Ask for this before you accept a fixed quote. If a vendor quotes a firm price without seeing the code, either the price includes a large safety margin or the scope will change later.

Phase the work so the budget stays honest#

Instead of one big project, split the engagement into stages with a decision point after each:

Phase	Typical focus	What you get
0. Audit	Read-only review of code, database, hosting	Written map, risks, phased estimate
1. Stabilise	PHP version, security patches, backups, monitoring	A system that is safe to keep running
2. Safety net	Tests around critical flows, CI pipeline	Confidence to change things
3. Modernise	Framework upgrade or incremental migration	Maintainable core
4. Improve	New features on the new foundation	Business value

You can stop after any phase and still have something useful. That is the main protection against a modernization that runs over budget and delivers nothing until the end.

💡Tip

If a quote jumps straight to phase 3 or 4 without phases 0 to 2, ask what the plan is for verifying that behaviour did not change.

Where budgets usually go wrong#

Treating the audit as optional. Skipping it moves the discovery cost into the build, where it is more expensive.
Changing scope mid-flight. Adding features during a migration doubles the testing burden.
Underestimating data work. Cleaning and migrating data is often a quarter or more of the effort and rarely appears in first estimates.
No owner on the business side. Decisions about which legacy behaviours to keep need someone who can answer quickly.
Forgetting the run cost. A modernized system still needs hosting, monitoring and maintenance. I wrote about that in what to budget for software maintenance.

When modernization is the wrong answer#

Sometimes the right call is to leave the system alone. If the application is stable, low-risk, rarely changed and on a supported PHP version, spending money to rewrite it creates risk without business benefit. Put the budget into backups, monitoring and security patching instead. Modernize when the code is blocking something you care about: shipping features, passing a security review, hiring developers, or integrating with newer systems.

Also check the version situation first. The PHP supported versions page shows which releases still get security fixes, and the Laravel release notes show the support window for each framework version. If you are far behind, an upgrade path such as the one in my Laravel upgrade checklist is often cheaper than people expect, because it is mostly mechanical. Tools like Rector automate a good share of the syntax changes.

Frequently asked questions#

How long does a legacy PHP modernization take?#

It depends on the route. A version upgrade with good tests can take weeks. A staged migration of a business-critical system usually takes months, because the old and new code run side by side. An audit will give you a realistic band.

Can the site stay online during modernization?#

Yes, if the work is planned for it. The strangler pattern, described well on Martin Fowler's site, replaces functionality gradually so users never see a cutover day.

Is Laravel the right target?#

Often, but not always. Laravel suits most business applications because of its conventions, queue system and ecosystem. The right target is whatever your team can maintain. I walk through one real move from Core PHP in migrating a legacy Core PHP platform to Laravel.

Should I rewrite instead?#

Only if the existing system cannot be understood or safely changed and the business logic is small enough to re-specify. Rewrites hide risk until late in the project.

Key takeaways#

Cost is driven by test coverage, code organisation, data quality, integrations and downtime tolerance, not by page count.
Pay for an audit first. It converts guesses into a phased estimate.
Phase the work so you can stop at any stage with something usable.
Do not modernize stable, low-risk systems for the sake of it.

If you want a sized, phased plan for your own application, you can book a call or send the details through the contact page. That is exactly how an engagement with me begins.

Originally published at aqibjavaid.site.

Why Your RAG Chatbot Gives Wrong Answers (and How to Fix It)

Aqib Javaid — Thu, 22 Oct 2026 08:46:52 +0000

You built a chatbot on your own documents, and it still answers with confident nonsense. Customers get wrong prices, invented policies or a polite "I don't know" when the answer is on your website. This is the most common complaint I hear about RAG chatbot wrong answers, and the good news is that most of the time the model is not the problem. The retrieval and the rules around it are.

I build and tune these systems as part of AI integration and AI-powered applications work. This guide walks through why a retrieval-augmented chatbot gives bad answers and the fixes I try, in the order I try them.

First, understand how a RAG chatbot answers

RAG stands for retrieval-augmented generation. When a user asks a question, the system:

Searches your content for the passages most related to the question
Passes those passages to the language model along with the question
Asks the model to answer using that material

That means a wrong answer can come from three places: the right passage was never found, the passage was found but was poor or incomplete, or the model ignored or went beyond the material it was given. Fixing the wrong layer wastes weeks, so diagnose first.

Step 1: Find out which layer is failing

Take 20 to 30 real questions that the bot got wrong. For each one, log what was retrieved and look at it yourself.

Right answer not in the retrieved passages: a retrieval problem.
Right answer present, but the bot answered wrongly: a prompt or generation problem.
Right answer not in your content at all: a content problem. No technique fixes missing information.

This simple audit usually shows that one layer causes most of the failures. Everything below maps to one of these three layers.

Fixing retrieval problems

Chunk by meaning, not by character count

Splitting documents into fixed-size pieces often cuts a policy in half or separates a heading from its answer. Split on headings, paragraphs and list boundaries, keep a little overlap, and store the page title and section name with each chunk so the passage carries its own context.

Clean the source content

Navigation menus, cookie banners, repeated footers and duplicated pages pollute search results. Strip boilerplate before indexing and remove outdated pages, so the bot doesn't find an old price list that outranks the new one.

Combine keyword and semantic search

Semantic search finds related meaning, but it can miss exact terms such as product codes, names and error messages. Combining it with keyword search (hybrid search) and merging the results catches both kinds of question. If you store vectors in PostgreSQL, the pgvector extension works alongside normal full-text search, and my comparison of HNSW and IVFFlat indexes covers the index choice.

Retrieve more, then rerank

Fetch a wider set of candidates, then use a reranking step to pick the few most relevant passages for the model. This often improves answer quality without changing anything else.

Rewrite follow-up questions

Users ask things like "what about the cheaper one?" A search for that phrase finds nothing useful. Before searching, rewrite follow-ups into standalone questions using the conversation so far.

Fixing prompt and generation problems

Tell the model to stay inside the material

Instruct the model to answer only from the supplied passages and to say so when they don't contain the answer. Anthropic's guidance on minimizing hallucinations describes techniques such as allowing the model to say it doesn't know and asking it to ground claims in quotes from the source.

Require citations

Make the bot show which page or document each answer came from. Citations let users verify, and they let you see at a glance when an answer is not supported by a source.

Use a "no good match" threshold

If the best retrieved passage is only weakly related, don't force an answer. Return a fallback such as offering to connect the user with a person. A bot that says "I'm not sure" at the right moment is more trusted than one that always answers.

Set topic limits and a persona

Define what the bot may and may not discuss, and how it should speak. On the Henceforward platform I built, the admin suite included controls for brand persona, topic restrictions and AI guardrails, so non-developers could adjust behaviour without a deploy. See the Henceforward RAG chatbot case study for how that was structured.

Fixing content problems

If the answer isn't in your content, no setting will conjure it. Look at the questions the bot can't answer and treat them as a to-do list for your knowledge base:

Add pages for questions customers ask repeatedly
Make pricing, policies and hours explicit and dated
Remove contradictory versions of the same information
Put the answer near the question it belongs to

Many "AI problems" turn out to be documentation problems.

Build a small evaluation set

The single most useful habit is a fixed list of test questions with the answers you expect. Run it after every change to chunking, search or prompts, and compare results. Without it, you fix one question and silently break three others.

A good starter set:

30 to 50 real customer questions, with the expected answer or source page
A handful of questions the bot should refuse or hand off
A few tricky cases: ambiguous wording, outdated information, follow-up questions

Re-run it whenever you change anything, and add every new failure you find.

Watch the bot in production

Log each question, the passages retrieved, the answer and any user feedback. Review a sample every week. Thumbs-down ratings and "I don't know" responses point you straight to content gaps and retrieval failures. My article on making AI features production-ready covers the logging, cost controls and failure handling that keep a bot trustworthy after launch.

A realistic order of work

If you have limited time, this is the order I would follow, because each step is cheap and builds on the last:

Build the test question set and record the current score
Clean and re-chunk the content, then re-run the test set
Add hybrid search and reranking, then re-run
Tighten the prompt, add citations and a no-match fallback, then re-run
Fill content gaps found in the failed questions
Start the weekly production review

Changing one thing at a time, and measuring after each change, is what separates steady improvement from guesswork. It also gives you evidence to show stakeholders that answer quality is actually improving.

When it's still wrong: check the basics

Is the content actually indexed, or did ingestion fail silently?
Are you searching the right version or language of the content?
Is the context window being filled with too many weak passages?
Did a prompt change accidentally loosen the rules?

If you are planning a chatbot from scratch, my guide to AI chatbot development cost explains what drives the budget, and building an AI chatbot with Laravel and OpenAI shows one implementation.

Key takeaways

Diagnose first: was the answer not retrieved, poorly retrieved or mishandled by the model?
Better chunking, clean content, hybrid search and reranking fix most retrieval failures.
Ground the model in the sources, require citations and allow "I don't know".
Missing content is a content problem, not an AI problem.
A small test set and weekly log reviews keep quality from slipping.

If your chatbot is giving answers you can't trust, book a call and I will review how it retrieves and answers, and tell you what to fix first.

Originally published at aqibjavaid.site.

DEV Community: Aqib Javaid

Marketplace Website Development Cost: What to Budget

What makes a marketplace more expensive than a normal website?

How much does a marketplace cost at different scopes?

Where does the money actually go?

Payments and payouts

Multi-language and localisation

Messaging and notifications

Admin and moderation

Build custom, use a SaaS platform, or start with a plugin?

How can you reduce marketplace development cost without cutting corners?

When should you not build a custom marketplace?

Frequently asked questions

How long does it take to build a marketplace?

What are the ongoing costs after launch?

Can I build the marketplace in phases?

Do I need a developer or an agency?

Key takeaways

SaaS MVP Development Cost: What to Budget Before You Build

What an MVP is (and is not)#

The building blocks of a SaaS budget#

Features that quietly inflate the cost#

Multi-tenancy#

Billing complexity#

Need specialized help with SaaS Development?

Integrations#

Real-time features#

Custom admin and analytics#

Mobile apps#

How to scope the first version#

Cost drivers outside the code#

How to compare quotes#

When not to build custom software yet#

Frequently asked questions#

How long does it take to build a SaaS MVP?#

Should I use Laravel or Next.js for a SaaS MVP?#

Do I need multi-tenancy from day one?#

What should I keep out of the MVP?#

Key takeaways#

Laravel N+1 Query Problem: How to Find and Fix It

What the problem looks like#

How to find N+1 queries#

Use Laravel's built-in guard#

Use a debugging tool#

Count queries in a test#

Need specialized help with Database Optimization & Backend Performance?

The fixes#

Eager loading with with()#

Counts and aggregates with withCount()#

Conditional eager loading#

Default eager loads: use sparingly#

Where N+1 hides#

Eager loading is not always the answer#

A real-world pattern#

A simple routine for existing apps#

Frequently asked questions#

Does Laravel fix N+1 automatically?#

Will eager loading always be faster?#

Is N+1 still a problem with a fast database?#

How many queries per page is too many?#

Key takeaways#

How to Migrate WordPress to Next.js Without Losing SEO

Principle: keep everything Google already knows#

Step 1: Take a full inventory before touching code#

Step 2: Decide the URL strategy#

Step 3: Choose how content is managed#

Step 4: Recreate on-page SEO exactly#

Need specialized help with React & Next.js Development?

Step 5: Render pages so crawlers can read them#

Step 6: Build redirects, sitemap and robots#

Step 7: Check performance and Core Web Vitals#

Step 8: Test on staging, thoroughly#

Step 9: Launch with care#

Step 10: Monitor for 8 to 12 weeks#

When not to migrate#

Frequently asked questions#

Will I lose rankings when I migrate?#

Can I keep using the WordPress editor?#

How long does a migration take?#

Do I need to keep my old URLs?#

Eager loading with `with()`#

Counts and aggregates with `withCount()`#

Should I use `php artisan down` for every deploy?#