DEV Community: Aqib Javaid

Multi-Tenant SaaS: Shared Database or One Per Tenant?

Aqib Javaid — Sat, 17 Oct 2026 05:32:20 +0000

If you are building a SaaS product for more than one customer, you will have to answer one early question: how do you separate each customer's data? The choice between a shared database and a database per tenant shapes security, cost, performance and how painful your first enterprise customer will be.

I make this decision with founders as part of SaaS development work. This guide explains the three common models, when each fits, and the mistakes that are expensive to fix later.

What "multi-tenant" means

A tenant is one customer account, usually a company with its own users and data. A multi-tenant system serves many tenants from one codebase and one deployment. The alternative, running a separate copy of the whole app per customer, is single-tenant, and it gets hard to maintain quickly.

Multi-tenant design answers two questions:

Isolation: how do you make sure tenant A can never see tenant B's data?
Operations: how do you migrate, back up, scale and support many tenants without the work growing with every new customer?

The three data models

1. Shared database, shared schema

All tenants live in the same tables. Each row has a tenant_id column, and every query filters by it.

Strengths

Cheapest to run and simplest to start
One migration updates everyone
Easy to report across tenants

Weaknesses

One missed filter leaks data between customers
A very large tenant can slow everyone down ("noisy neighbour")
Restoring a single tenant from a backup is awkward

2. Shared database, separate schema per tenant

Tenants share a database server, but each gets its own schema, such as separate sets of tables.

Strengths

Stronger separation than a tenant column
Per-tenant backup and restore is easier

Weaknesses

Migrations must run once per tenant, which gets slow with many tenants
Tooling and connection handling are more complex

3. Separate database per tenant

Each tenant has its own database.

Strengths

Strongest isolation, which helps with security reviews and regulated customers
A tenant's data can be moved, backed up or deleted on its own
Heavy tenants don't affect the others' queries

Weaknesses

Highest operational cost and complexity
Migrations and monitoring multiply with each tenant
Cross-tenant reporting needs extra work

Microsoft's architecture guidance on tenancy models describes the same trade-off between isolation, cost and operational effort, and is worth reading alongside this.

How to choose: five questions

1. Who are your customers? Many small customers point toward a shared database. A few large or regulated customers who ask about data isolation point toward separate databases.

2. What are the compliance expectations? If customers need contractual guarantees about data separation, or data residency in specific regions, a separate database makes those promises easier to keep.

3. How uneven will tenants be? If one tenant could be a hundred times bigger than the average, plan for isolating heavy tenants early.

4. How big is the team? Every extra database is something to monitor, migrate and back up. A small team should choose the simplest model that meets the requirements.

5. How will you grow? Many products start shared and move their largest customers to dedicated databases later. A design that allows this is more valuable than a perfect choice on day one.

My default for early-stage SaaS

For most early products I start with a shared database and a tenant_id on every tenant-owned table, and I build the safeguards in from day one. This keeps cost and complexity low while the product finds its market, and it does not close the door on moving large customers out later.

The key is that "shared" must not mean "careless". The safeguards I add:

A global scope or middleware that applies the tenant filter automatically, so developers can't forget it
Database-level protection where the database supports it. PostgreSQL's row-level security can enforce tenant filtering even if application code has a bug.
Tenant-aware tests that fail if a query returns another tenant's rows
Composite unique keys that include the tenant, so two customers can use the same email or slug
Tenant context in logs and jobs, so background work never runs without knowing whose data it touches

If you use Laravel, packages such as Tenancy for Laravel support both single-database and multi-database approaches, which helps you start simple without being locked in.

Common mistakes

Forgetting background jobs. Queued jobs, scheduled tasks and webhooks run outside a web request, so the tenant context can be missing. Pass the tenant explicitly, as I describe in my guide to Laravel queue architecture.

Leaking through shared resources. Caches, search indexes and file storage need tenant-aware keys and paths, not only database rows. See secure multi-tenant file storage in Laravel.

Global unique constraints. Uniqueness rules that ignore the tenant make customers collide with each other.

No plan for super-admin access. Support staff need to view tenant data, and that access should be controlled and logged. My article on audit logging for SaaS compliance covers this.

Choosing separate databases too early. It feels safer but multiplies operations for a product that may only have a handful of customers.

Cross-tenant reporting as an afterthought. Analytics across tenants are easy in a shared schema and hard with many databases.

A real-world example

On Imperial Votes, a multi-tenant competition platform I built on Next.js and Prisma, organizers run their own competitions with branding tools, role-based permissions and dashboards, while super-admin controls sit above them. That mix of customers acting independently under one platform is exactly where the tenancy decision matters. The Imperial Votes case study shows how the product grew, and the matching write-up on building a multi-tenant voting SaaS goes deeper.

What to decide before you write code

Before the first migration, write down answers to these:

What is a tenant in our product (a company, a team, a workspace)?
Which tables belong to a tenant, and which are global?
How is the tenant identified on each request: subdomain, path or login?
How will background jobs and webhooks know the tenant?
What would force us to move a customer to a dedicated database?
How do support staff access tenant data safely?

Answering these costs an afternoon. Changing the model after launch costs months.

Moving a large tenant to its own database later

If you design for it, moving one customer out of the shared database is a manageable project rather than a rewrite. The usual steps:

Create the new database with the same schema and run the same migrations.
Copy the tenant's rows across, using the tenant_id to select exactly what belongs to them.
Verify counts and key records, and keep the old data until the checks pass.
Switch the tenant's connection so requests resolve to the new database.
Remove the tenant's rows from the shared database once you are confident.

This only works if every tenant-owned table carries the tenant identifier, files and caches are tenant-scoped, and your application resolves the database connection from the tenant. Those are the same safeguards that keep the shared model safe, which is why I add them from the start.

Key takeaways

Multi-tenancy is mostly about isolation and operational cost.
Shared database with a tenant column is the cheapest start. Separate databases give the strongest isolation.
Add safeguards such as global scopes, row-level security and tenant-aware tests so shared never means careless.
Plan for jobs, caches, files and support access, not only database tables.
Design so you can move large tenants out later.

If you are planning a SaaS product and want the architecture settled before you build, book a call and we can map the tenancy model to your customers and budget.

Originally published at aqibjavaid.site.

Software Maintenance Cost: What to Budget Each Year

Aqib Javaid — Fri, 16 Oct 2026 13:39:58 +0000

Most people budget carefully for the build and then forget the bill that never stops: software maintenance cost. A web app, SaaS product or internal system is not a one-off purchase. It needs hosting, security patches, dependency upgrades, backups, monitoring and fixes for the problems real users find. If nobody pays for that work, the system quietly decays until it becomes the legacy application you were trying to avoid.

I look after production systems as part of my cloud, DevOps and deployment work, so this guide covers what maintenance actually includes, what drives the cost, and how to budget for it without guessing.

What software maintenance actually covers

"Maintenance" is a bucket for four different kinds of work. Knowing which is which makes the budget conversation much easier.

Corrective: fixing bugs found in production.
Preventive: security patches, framework and library upgrades, and clean-up that stops problems before they appear.
Adaptive: changing the system because the world changed, such as a new PHP version, a payment provider update or a browser change.
Perfective: small improvements and requests that make the product better but are not a new project.

New features are usually a separate budget. The trap is letting small feature requests quietly consume the maintenance hours that keep the system safe.

The recurring costs people forget

Beyond developer time, a live system has running costs:

Hosting and infrastructure: servers, databases, storage and bandwidth. My comparison of Laravel hosting options and cost shows how widely this varies.
Third-party services: email, SMS, payments, search, error tracking and AI APIs, often billed by usage.
Domain, SSL and licences for paid plugins or tools.
Backups and disaster recovery, including actually testing a restore.
Monitoring and alerting, so you hear about problems before customers do.
Security work: patching, access reviews and responding to vulnerability notices.

These costs are easy to estimate once you have a list. The surprise usually comes from usage-based services that grow with your traffic.

What drives maintenance cost up or down

I will not quote a percentage that pretends to fit every system. These factors decide where yours lands:

Age and technology. Systems on unsupported frameworks cost more to keep safe. This is the main link to rewriting or refactoring a legacy application.
Test coverage. Tested code is cheaper to upgrade because you can see what broke.
Number of integrations. Every third-party API is something that can change or fail.
Traffic and data volume. More load means more tuning and more infrastructure.
Quality of documentation. Missing knowledge makes every task slower.
Deployment process. Manual releases cost time and cause errors. A clean pipeline, as in my guide to zero-downtime deployments, lowers the cost of every future change.
Required uptime. A system that must always be available needs monitoring and on-call, which costs more.

Three ways to pay for maintenance

1. Retainer. A fixed monthly amount that covers a set number of hours or a defined scope. It suits systems with steady needs and gives you predictable budgeting and fast response.

2. Time and materials. You pay for hours as they are used. It is flexible for quiet systems, but costs are unpredictable and urgent issues compete with other clients' work.

3. Fixed-scope packages. Specific tasks, such as a framework upgrade or security audit, for a fixed price. These are good for planned one-off work on top of a baseline.

Many businesses use a small retainer for monitoring and urgent fixes, plus fixed-scope projects for bigger upgrades.

How to estimate your own maintenance budget

Use this simple worksheet:

List every running cost: hosting, services, domains, licences. Check last month's invoices for each.
Estimate routine hours: security patches, dependency updates, backup checks and monitoring review, per month.
Add a bug-fix allowance based on how often production issues have appeared so far.
Add planned upgrade work for the year, such as a major framework or PHP version.
Add a contingency for the unexpected, and treat it as real money.
Separate new features into their own budget so they do not eat maintenance time.

If the system is brand new and has no history, expect the early months to need more attention while real usage reveals problems. A short audit gives you a better starting point than a guess.

Why support dates decide your upgrade calendar

Two clocks set most of your planned maintenance: the language and the framework.

Language versions each get a limited support window, after which they stop receiving security fixes. PHP publishes these dates on its supported versions page.
Framework versions follow their own policy. Laravel documents which releases still receive bug and security fixes in its release notes and support policy.

Put both sets of dates in a calendar and plan an upgrade before a version runs out of support, not after. Doing one planned upgrade a year is far cheaper and less risky than jumping across several versions at once, which is the situation I describe in my Laravel upgrade checklist.

A good maintenance plan therefore includes a yearly "version review": check what you run, check the support dates, and decide what gets upgraded next. It takes a few hours and avoids an emergency later.

What happens when you skip maintenance

Skipping maintenance does not save money. It moves the cost to later and makes it larger:

Known security holes stay open
Upgrades pile up until they become a risky big-bang project
Small bugs turn into outages
Only one person understands the system
Hosting and dependencies freeze because nobody dares touch them

On the Henceforward WordPress project, the work combined website development with migrating infrastructure to Scaleway with Laravel Forge, strengthening security and optimising the production environment. That kind of foundation is what makes ongoing care cheaper. You can read the Henceforward case study for the details.

A simple way to report maintenance value

Maintenance feels invisible when nothing breaks, which makes it easy to cut. Ask for a short monthly note covering four things: what was patched or upgraded, which incidents occurred and how fast they were resolved, how backups and monitoring performed, and what is planned next. A one-page summary turns "nothing happened" into evidence that the system is being looked after, and it gives you the data to adjust the plan when needs change.

Questions to ask before you agree a maintenance plan

What exactly is included, and what counts as a new feature?
What is the response time for an urgent production issue?
Who monitors the system, and how will I be alerted?
How are backups tested?
What happens to the plan if the system grows?
Can I see a report of what was done each month?

A clear answer to these is a better signal than the lowest price. My thoughts on why experience beats low-cost outsourcing apply here too.

Key takeaways

Maintenance is four kinds of work: fixing, preventing, adapting and improving.
Running costs go beyond developer time: hosting, services, backups, monitoring and security.
Age, tests, integrations and deployment process drive the price more than size alone.
Choose a retainer for steady needs, fixed-scope packages for planned upgrades.
Skipping maintenance makes problems larger and more expensive later.

If you want a clear maintenance budget for a system you already run, book a call and I will review it and tell you what it really needs.

Originally published at aqibjavaid.site.

Rewrite or Refactor a Legacy Application? How to Decide

Aqib Javaid — Thu, 15 Oct 2026 13:27:16 +0000

Every business with an ageing application eventually faces the same question: do we rewrite or refactor the legacy application? Get it wrong and you either burn a year rebuilding something that already worked, or you pour money into patching a system that cannot be saved.

I handle this decision as part of legacy application modernization work, and the honest answer is almost never "rewrite everything" or "leave it alone". This guide gives you a practical way to decide, the questions I ask, and the middle path that usually wins.

What "legacy" actually means

Old code is not automatically legacy code. An application is legacy when it is hard to change safely. Typical signs:

Nobody dares to deploy on a Friday, or at all
Only one person understands how it works
The framework or language version no longer gets security updates
Simple changes take weeks because everything is tangled together
There are no tests, so every change is a gamble
Hosting and dependencies are frozen because upgrading might break things

If the app is old but stable, tested and easy to change, it is not your problem. If it is new but a mess, it might be.

The three options, in plain terms

Refactor in place. Improve the existing code step by step without changing what the system does: add tests, clean up the worst areas, upgrade dependencies.
Rewrite from scratch. Build a new system and switch over when it is ready.
Modernise incrementally. Replace the system piece by piece while the old one keeps running. This is often called the strangler pattern, described well in Martin Fowler's write-up of the Strangler Fig approach.

Most teams think they have two choices. The third is what usually works.

Why big-bang rewrites fail so often

A full rewrite looks attractive: clean code, modern tools, no baggage. The problem is that the old system contains years of quiet business knowledge: edge cases, workarounds, rules nobody wrote down. Joel Spolsky made this argument in his classic essay Things You Should Never Do, Part I, and it still holds up.

In practice, rewrites go wrong for predictable reasons:

The old system keeps changing while you build the new one, so you are chasing a moving target.
You ship nothing for months, so the business pays but sees no value.
Hidden behaviour is lost because nobody remembers why it worked that way.
Scope grows, because a rewrite invites "while we're at it" features.

That does not mean never rewrite. It means be sure you must, and limit the blast radius.

A decision framework you can use this week

Score your system on these questions. I use them in audits.

1. Can the system still do its job? If it works and the business is not blocked, you have time to move carefully. If it is failing daily, you may need to stabilise first.

2. Is the technology end-of-life? An unsupported framework or language version is a security and hiring risk. That pushes you toward upgrading or replacing, not ignoring.

3. Is the data model sound? A good database under a messy application is a great position. A broken data model is a much bigger problem than ugly code.

4. Can you test it? If you can add tests around key flows, refactoring becomes safe. If the code cannot be tested at all, that is a strong signal to replace parts of it.

5. How tangled are the pieces? Systems with clear boundaries can be replaced one module at a time. A single ball of mud is harder.

6. What does the business need next? If the next year's roadmap is mostly new features, spend effort where those features land, not on parts nobody touches.

7. Who knows the system? If that knowledge is walking out the door, document and test first, whatever you choose.

When refactoring is the right call

Choose refactoring when:

The framework is still supported or has a clear upgrade path
The data model is sound
The pain is concentrated in a few areas
You can put tests around the critical flows

I often start with exactly this: map the dependencies, add tests around the riskiest workflows, fix the worst hotspots, and upgrade in steps. My Laravel upgrade checklist walks through that approach for older Laravel apps.

When a rewrite is justified

A rewrite makes sense when:

The platform is end-of-life with no sensible upgrade path
The architecture fundamentally cannot support what the business needs
The system is small enough to rebuild in a short, fixed window
The code is so untestable that incremental change is not possible

Even then, I prefer to rebuild in slices, with the old system running beside the new one.

The incremental path most businesses should take

The approach I recommend most often has five steps:

Audit first. Understand the workflows, the database, the dependencies and the risks before deciding anything.
Stabilise. Fix security gaps, add monitoring and backups, and make deployments repeatable.
Add tests around the flows that matter most.
Replace one slice at a time. Pick a self-contained module, rebuild it in the new stack and route traffic to it.
Retire the old parts once the new ones have proven themselves.

Each step delivers something the business can see, and each one can be paused or reversed.

What drives the cost either way

I will not quote a number without seeing the system, but these factors move cost and timeline the most:

Size and complexity of the application, especially the number of distinct workflows
Test coverage, because untested code costs more to change safely
Data migration, since moving and validating years of records is often the riskiest step
Integrations with payment, shipping, CRM and other third-party services
How much downtime the business can tolerate during the switch
Documentation and access, because missing knowledge slows everything down

An audit before the main work is usually the cheapest way to turn these unknowns into a plan you can budget.

A real-world example

On the PPCWA freight-forwarding audit, I was brought in to audit and stabilise a nearly completed Core PHP and MySQL platform. The work focused on understanding the existing system first: workflows, database structure, frontend maintainability, dependencies and configuration. I also assessed the architectural path toward a future Laravel migration. The point was to decide with evidence instead of opinion. I describe a related migration in migrating a legacy Core PHP platform to Laravel and a Laravel-specific version in Laravel 5 migration strategy.

Questions to ask any developer or agency

If someone recommends a rewrite, ask:

What did you find in the existing system that cannot be improved?
How will we keep the business running during the work?
Which parts will go live first, and when?
How will you protect the data and the undocumented business rules?
What is the plan if the project overruns?

A good partner answers with specifics. A weak one answers with enthusiasm for new technology.

Key takeaways

"Legacy" means hard to change safely, not just old.
Big-bang rewrites fail because they lose hidden business knowledge and deliver late.
Audit first, then choose refactor, rewrite or incremental replacement with evidence.
Incremental modernisation is usually the lowest-risk option.
A sound data model and testable flows tilt the decision toward refactoring.

If you are weighing this decision for your own application, book a call and I will tell you which path I would take and why.

Originally published at aqibjavaid.site.

MLS and IDX Integration: A Guide for Real Estate Platforms

Aqib Javaid — Wed, 14 Oct 2026 05:47:46 +0000

If you are building a property search site, a broker portal or a real estate app, you will hit the same wall quickly: the listings you want live in a Multiple Listing Service (MLS), and getting them out is a data-integration project with business rules, not a simple API call. This guide explains how MLS and IDX integration works, what usually goes wrong, and how I approach it as part of real estate data platform development.

I am an engineer, not a lawyer or a licensed broker. MLS rules differ by region and by board, so treat this as an engineering view and confirm the licensing details with the MLS you plan to work with.

MLS vs IDX: what each one actually is

These two terms get mixed up constantly.

MLS (Multiple Listing Service) is the database where brokers share listings. Access is controlled by the MLS and its rules.
IDX (Internet Data Exchange) is the policy framework that lets participating brokers display other brokers' listings on their own websites. It governs display, not unlimited use.
Data feeds are the technical way the data reaches you. Today that is usually an API, and the older approach was a protocol called RETS.

That last point matters for planning. IDX permission to show listings does not automatically mean you may store them forever, resell them, run analytics on them or train models on them. Each MLS sets its own rules for what a feed can be used for.

Who can get access to the data

You normally need a relationship with the MLS before any code is written:

A broker or agent who is a participant, or a technology vendor sponsored by one
A signed data licence or feed agreement that lists what you may display and store
Approval of your site or app before real listings go live

This is the first business decision. If you are a software company building for brokers, the broker usually holds the licence and you work on their behalf. Ask early who signs what, because it can take longer than the build.

How the data reaches you: RETS vs the RESO Web API

The industry's current standard is the RESO Web API, a RESTful interface built on web standards and OData. RESO's own FAQ describes the older RETS protocol as deprecated and unsupported, and some MLSs are still mid-transition.

What that means for your project:

Ask which feed the MLS offers before you estimate. A RETS-only MLS and a Web API MLS are very different builds.
With the Web API you query with filters and page through results, and you can ask for only what changed since your last sync using OData query options.
Many MLSs publish field names using the RESO Data Dictionary, which makes the data far easier to normalise across sources than older custom schemas.

Some teams skip direct MLS integration and use an aggregator or vendor that already normalises several MLSs. That trades flexibility and cost for speed. For a single-market product, going direct is often fine. For many markets, an aggregator can save months.

The architecture I use

Whatever the source, I keep the same shape:

Ingest. A scheduled job pulls new and changed listings. Always sync incrementally using a modified-timestamp field, with a periodic full reconcile to catch anything missed.
Store raw. Keep the original payload so you can re-process if your mapping changes.
Normalise. Map the source fields to your own schema (price, status, beds, baths, address, media, agent, timestamps). This is where most bugs live.
Index for search. Put searchable data in a database or search engine tuned for filters like price, location and property type.
Serve. Your site or API reads from your own store, never directly from the MLS on each page view.
Monitor. Alert on failed syncs, sudden drops in listing counts and stale data.

I covered the general pattern for keeping data pipelines healthy in scraped data change detection. The same thinking applies: detect what changed, and know when a feed has quietly stopped.

The hard parts nobody warns you about

Status changes and removals. A listing that goes pending, sold or withdrawn must disappear or change on your site promptly. Many MLS rules require this, and stale "active" listings annoy users fast. Plan for deletes, not just new rows.

Photos and media. Images are large and numerous. You often need to cache, resize and serve them yourself, within the MLS's media rules, and handle photos that are added, reordered or removed.

Field quirks. The same concept appears in different shapes across MLSs: free-text fields, custom picklists, inconsistent address formats. Budget time for a mapping layer you can adjust without a redeploy.

Rate limits and quotas. Feeds throttle. Page carefully, back off on errors and never fetch everything on every run.

Display rules. Required disclaimers, attribution, brokerage names and "last updated" notices are commonly part of the agreement. Build them into the templates from the start.

Compliance as a feature. Treat the rules as requirements, not paperwork. An audit finding can cost more than the integration.

Cost and timeline expectations

I won't quote numbers that depend on your MLS, but these factors move cost and time the most:

Number of MLSs. Each one has its own agreement, quirks and mapping work.
Feed type. Web API is simpler than RETS, and a vendor aggregator can be simpler still.
Scope. Search only, or also saved searches, alerts, lead capture and an agent portal.
Media handling and how much you cache.
Compliance review time on the MLS side.

The pattern I see is that the technical build is the smaller part. Approvals and rules take the calendar time, so start the licensing conversation first.

A checklist before you commit to a build

Before you sign a statement of work, get answers to these:

Which MLS or MLSs do we need, and who holds the licence?
Is the feed a RESO Web API, a legacy RETS service or a vendor aggregator?
What may we display, store and cache, and for how long?
How quickly must sold, pending and withdrawn listings be removed?
Which disclaimers and attribution must appear on every listing page?
What are the rate limits, and is there a sandbox or test feed?
Who monitors the sync after launch, and what alerts exist?
Do we need only search, or also alerts, saved searches and lead capture?

If more than two of these are unanswered, the estimate is a guess.

A real-world parallel from my work

On the Violerts PropTech platform, my work involved multi-agency data ingestion for NYC property compliance, plus asynchronous scraping and real-time alerts. Different data sources, but the same engineering problems: messy upstream formats, changing data, and users who need accurate information quickly. See the Violerts case study for how that platform is structured, and my notes on third-party API integration best practices for the general lessons.

Key takeaways

MLS is the data source, IDX is the display permission, and the feed (usually the RESO Web API) is the transport.
Sort out licensing and feed type before estimating.
Sync incrementally, store raw data, normalise to your own schema and serve from your own store.
Plan for removals, photos, field quirks and display rules from day one.
Approvals usually take longer than the code.

If you are planning a property platform and want the data layer scoped properly, book a call and we can walk through your MLS, your feed and your timeline.

Originally published at aqibjavaid.site.

Is Web Scraping Legal? A Practical Guide for Businesses

Aqib Javaid — Tue, 13 Oct 2026 05:16:58 +0000

If you are asking is web scraping legal for business, the short answer is: collecting publicly available data is often lawful, but "often" is doing a lot of work in that sentence. The risk depends on what you collect, how you collect it, which terms you have agreed to, and what you do with the data afterwards.

I build scrapers and data pipelines for a living (see my web scraping and data extraction service), so this is the practical version I walk clients through before a project starts. I am an engineer, not a lawyer, and nothing here is legal advice. Treat it as a map of the questions to ask your own counsel.

The short answer: it depends on five things

Scraping is not one legal question. It is five, and each can sink a project on its own:

Is the data public, or behind a login? Public pages carry far less risk than anything you can only reach by signing in.
Is it personal data? Names, emails, phone numbers and profiles trigger privacy law almost everywhere.
What do the site's terms say, and did you agree to them? Accepting terms by creating an account is very different from visiting a public page.
Is the content protected by copyright or database rights? Facts are treated differently from creative text, images and structured databases.
How hard are you hitting the server? Scraping that degrades a site can create its own problems, however public the data is.

If you can answer all five, you can usually tell whether a project is low, medium or high risk.

Public data versus data behind a login

In the United States, the main anti-hacking law people cite is the Computer Fraud and Abuse Act (CFAA). In Van Buren v. United States (2021), the Supreme Court read its "exceeds authorized access" language narrowly, and later decisions, including the Ninth Circuit's hiQ v. LinkedIn, leaned toward the view that scraping pages anyone can open is unlikely to count as "unauthorized access".

That does not make public scraping a free-for-all. The hiQ dispute ended in a settlement, and courts have kept looking at other claims such as breach of contract and interference with the site's systems.

My working rule for clients is simple: public pages, no login, no circumventing technical blocks is the lowest-risk category. The moment a scraper logs in, uses someone else's credentials, or defeats an access control, the risk jumps, because you are now acting under an account and its terms.

Terms of service and contracts

Terms of service are where many scraping disputes are really fought. A site's terms may forbid automated access, and a contract claim does not need a hacking law at all.

Recent case law shows how fact-specific this is. In Meta v. Bright Data, a federal court in California found in early 2024 that Meta's terms governed a user's "use" of its products, and that scraping public pages while logged out was not that kind of use. Legal commentary on the decision is clear that this does not establish that all logged-off scraping is allowed. It turned on Meta's specific wording.

The practical lesson:

Never scrape while logged in to a service whose terms forbid it. By logging in you agreed to those terms.
Read the terms of every source before you build, and keep a dated copy.
If a source matters to the business, ask for permission or an API. It is often cheaper than a dispute.

Personal data: GDPR, CCPA and similar laws

This is the area where I see businesses underestimate risk the most. Data being public does not make it free to use. Under the EU's GDPR, personal data stays personal data even when it is published on a website. You still need a lawful basis, you must tell people how their data is used, and you must respect their rights. California's CCPA and several other US state laws add their own rules.

Practical ways to reduce the exposure:

Don't collect personal data you don't need. If you only need prices, don't store seller names.
Separate personal fields from the rest of the dataset, or drop them at ingestion.
Document why you collect each field and how long you keep it.
Be extra careful with sensitive categories and with scraping social profiles to build contact lists.

If your use case is lead generation from personal profiles, speak to a privacy lawyer before the first request goes out.

Copyright and database rights

Facts, such as a price, a date or a record number, are generally not protected by copyright in the US. Creative expression is: article text, photos, reviews and descriptions. In the EU and UK, a separate database right can protect a substantial investment in collecting a database.

So scraping product prices to analyse the market is a very different thing from copying a competitor's product descriptions and photos onto your own site, or from feeding a publisher's full articles into a product you sell.

A simple filter: extract and use facts, don't republish creative content.

robots.txt and rate limiting

robots.txt is the convention sites use to say which paths automated tools should avoid. The format is documented in RFC 9309. On its own it is a voluntary standard, not a law, but ignoring it looks bad if a dispute starts, and it is a good signal of what the site owner expects.

I treat it as a rule of the project:

Respect robots.txt and crawl-delay hints unless there is a clear reason not to, agreed with the client.
Identify your scraper honestly where that is practical.
Rate-limit so you never slow the site down for real users.
Back off automatically when you get errors or 429 responses.

Hammering a server is the fastest way to turn a grey area into a complaint.

Real-world example: public municipal data

On the Violerts platform, which consolidates fragmented NYC municipal property data into one compliance tool, the work involved multi-agency data ingestion and asynchronous scraping. Public government sources are about as low-risk as scraping gets, because the data is published for public use. Even so, the engineering question was never just "can we fetch it?" It was how to collect the data reliably and politely, and how to keep the pipeline healthy when sources change, which I cover in scraped data change detection.

You can read the full Violerts case study for how that system is structured. The same discipline applies in my write-up on building a resilient scraper for government data sources.

A practical checklist before you scrape

Before any scraping project starts, I ask the client to answer these questions:

What exact fields do we need, and why?
Is the source public with no login required?
Do the terms of service forbid automated access? Have we kept a copy?
Does the dataset include personal data? If yes, what is the lawful basis?
Is there an official API, data feed or licence we could use instead?
Are we respecting robots.txt and limiting request rates?
How will we store, secure and delete the data?
Who reviews the legal position, and when?

If question 5 has a yes, use the API. It is more stable, and it removes most of the legal grey area.

When to get a lawyer involved

Bring in a lawyer when any of these are true:

You plan to scrape behind a login or through an account
The dataset includes personal data about EU, UK or California residents
You will resell or republish the data as your product
The source is a direct competitor or has already sent a cease-and-desist
Your business depends on one source staying available

For everything else, a clear written policy and a well-built scraper that behaves politely will take you most of the way.

Key takeaways

Scraping public, non-personal data without logging in is usually the lowest-risk category, but "usually" is not "always".
Terms of service, privacy law and copyright are where businesses get into trouble, not the act of fetching a page.
Respect robots.txt, rate-limit, and never defeat access controls.
Collect only what you need, and drop personal data you don't.
Prefer an official API or licence when one exists.

If you want a scraping or data-extraction project scoped sensibly, with the compliance questions answered up front, book a call and we can go through your use case.

Originally published at aqibjavaid.site.

Build vs Buy an Event Booking System: How to Decide

Aqib Javaid — Mon, 12 Oct 2026 10:08:45 +0000

You run events, classes, tours or appointments, and people need a way to book and pay. Do you sign up for an existing tool, or pay someone to build a custom event booking system? The honest answer is "buy first, build when the tool starts getting in your way", but the details decide whether that's right for you.

Choosing wrong in either direction is expensive. Build too early and you spend months on features an existing tool already had. Buy too long and you end up patching around a platform that doesn't fit your business, paying fees on every booking and unable to change the parts that matter.

This guide gives you a way to decide. It covers what off-the-shelf tools do well, the signs that you've outgrown them, what a custom build involves, and a middle path that often beats both. It comes from my event and booking platform development work.

What ready-made booking tools do well

Existing tools such as ticketing platforms like Eventbrite, scheduling tools like Calendly, and booking plugins for WordPress cover the common cases quickly. Their strengths are real:

Speed. You can be taking bookings the same day.
Low upfront cost. You pay monthly or per ticket instead of paying for development.
Maintenance is someone else's job. Security updates, payment compliance and bug fixes are handled for you.
Familiar to customers. Many buyers already trust the checkout.

If your needs are standard (one organiser, simple tickets or time slots, ordinary payments), buying is almost always the right call. Don't build what you can rent.

Signs you've outgrown an off-the-shelf tool

Watch for these. One of them is an annoyance. Three or four is a pattern.

Fees eat your margin. Per-ticket or per-booking fees add up as volume grows, and they apply to money you could keep.
Your workflow doesn't fit. You need approval steps, custom pricing, packages, deposits, multi-day bookings or resource limits the tool can't model.
You run a marketplace. Several organisers or vendors, each with their own listings, payouts and messages, is a different product from a single-organiser tool.
You need your own brand and flow. The checkout, emails and pages must look and behave like your business, not the vendor's.
Integration is awkward. Your CRM, accounting, calendar or inventory can't connect cleanly, so staff copy data by hand.
You need multiple languages or regions. Different currencies, languages and local rules are hard to bolt on.
You own the data question. You need reporting, exports or data ownership the platform won't give you.

What a custom booking system really involves

A booking system looks like a calendar and a pay button. The complexity sits behind them:

Availability logic. Capacity, time zones, overlapping bookings, cut-off times and cancellations.
Payments. Deposits, refunds, split payouts and failure handling. If you take money for other organisers, a service like Stripe Connect is designed for marketplace payouts.
Notifications. Confirmations, reminders and messages that arrive reliably.
Admin tools. Staff need to create events, manage bookings, handle exceptions and see reports.
Content and SEO. Event pages that load fast and can be found on search engines.
Real-time updates. Live availability and messaging so two people don't book the last seat.

On the Planuojam event marketplace, the work involved rescuing a failing event platform by architecting a headless marketplace supporting five languages, real-time messaging and Stripe payments. It also included a custom AWS Translate-powered engine in Strapi 5 to automate nested content localisation while preserving SEO integrity. That list is a good illustration of how quickly "event booking" grows once you add languages, messaging and payments.

The middle path: buy the core, build the edges

You don't have to choose all or nothing. A common and sensible approach is:

Keep a proven tool for the parts that are the same for everyone, such as payment processing.
Build custom pieces only where your business is different, such as your pricing rules, your booking flow or your dashboard.
Connect the two through APIs, so you can replace either side later.

This keeps the upfront cost down and avoids a full rebuild. The same approach applies to other platforms, as I discussed in the Shopify versus custom ecommerce comparison. If you go this way, plan the integrations carefully. The API integration cost guide explains what drives the price.

How to compare the real cost

Don't compare the monthly fee with the build price. Compare total cost over three years.

Cost	Buy	Build
Upfront	Low	Higher (development)
Monthly or per booking	Subscription plus per-ticket fees	Hosting and payment processing fees
Changes and new features	Limited by the vendor	Paid development, but you decide
Maintenance	Included	Ongoing, small but real
Risk	Price rises, feature changes, vendor lock-in	Scope creep, build quality

Add up your expected bookings per year and multiply by the platform's per-booking fee. That number, over three years, is the figure to set against a build quote. For general budgeting of a custom product, the custom web app MVP cost guide gives realistic tiers.

When not to build

Skip a custom build when:

You haven't yet proven that people will book. Validate with a simple tool first.
Your needs fit a standard tool with a little configuration.
You can't commit to maintaining it after launch.
You'd be rebuilding features that make up 90% of what the tool already does well.

A simple way to decide

Can a ready-made tool run your events or bookings today with no workarounds? Buy it.
Are fees or workarounds already costing you real money each month? Cost out a build or a hybrid.
Is your model a marketplace, or does it need multiple languages, special pricing or deep integrations? Lean toward building.
Unsure? Start with a tool, track what you work around, and revisit in three to six months.

Frequently asked questions

How much does a custom event booking system cost?

It depends on the scope: roles, payment model, languages and integrations. A simple booking flow is far cheaper than a multi-vendor marketplace. Get a scoped estimate from the features you need, not a flat number.

Can I start with a tool and move to a custom system later?

Yes, and it's often the smartest path. Keep your customer and booking data exportable, and move over when you've learned what you actually need.

Is a WordPress booking plugin enough?

For a single organiser with simple needs, often yes. When you need marketplace features, complex rules or high volume, plugins start to strain.

What is the biggest hidden cost of building?

Maintenance and change. A booking system is never finished, because rules, payments and integrations keep moving. Budget for ongoing work.

Key takeaways

Buy first. Build when fees, workflow limits or a marketplace model make the tool a poor fit.
Compare total cost over three years, including per-booking fees.
A hybrid, buying the standard parts and building the differences, often wins.
A booking system is more than a calendar: availability, payments, notifications and admin tools carry the complexity.

If you're weighing a booking platform and want a senior engineer to give you an honest build-or-buy recommendation, book a free call and we'll go through your case together.

Originally published at aqibjavaid.site.

Custom API Integration Cost and Timeline: What to Expect

Aqib Javaid — Sun, 11 Oct 2026 05:01:45 +0000

"How much will it cost to connect our system to theirs?" is the question I hear most before an integration project, and it's the hardest one to answer from a one-line description. A custom API integration cost can be a few days of work or several months, and both can be described with the same sentence: "we need to connect X to Y".

The reason is that the API call is the easy part. What takes time is everything around it: how the data maps between two systems that describe the same thing differently, what happens when a request fails, how you know a payment really went through, and who gets alerted at 2 a.m. when it doesn't.

This guide breaks down what drives the cost and the timeline, gives typical effort ranges by complexity, and shows what to ask a developer before you agree on a price. It draws on the kind of integration work I do through my API development and integrations service.

[!NOTE]
The hour ranges below are typical planning figures from my experience, not a quote. Your price is the hours multiplied by the hourly or project rate of whoever builds it, and rates vary widely by region and seniority.

What you are actually paying for

An integration has more layers than "call the API". When I scope one, I look at these:

Authentication. API keys are quick. OAuth, token refresh and per-customer connections take longer.
Data mapping. Field names, formats, units and required fields almost never match between two systems.
Business rules. Which records sync, in which direction, and what wins when both sides change.
Error handling and retries. Timeouts, rate limits and temporary failures need a plan, not a hope.
Webhooks and status sync. Many services tell you about events after the fact, and those messages must be verified and processed safely.
Testing and monitoring. Sandbox accounts, edge cases, logging, and alerts when something breaks.
Documentation and handover. Someone has to be able to maintain it after the builder leaves.

Cheap quotes usually cover the first two layers and skip the rest. Those skipped layers are where integrations fail six months later, which I wrote about in the guide to third-party API integration best practices.

Typical effort by complexity

Type of integration	Typical effort	Typical calendar time	Example
Simple, one-way	15 to 30 hours	About 1 week	Push new form submissions into a CRM or spreadsheet
Standard, two-way with events	20 to 60 hours	1 to 3 weeks	Payments plus webhooks, or a CRM sync with status updates
Complex, several systems	60 to 150+ hours	4 to 10+ weeks	Multiple carriers, ERP data, approval rules and reporting

Treat the ranges as starting points. The same integration can fall at either end depending on four things: how good the third party's documentation is, whether a sandbox exists, how messy your existing data is, and how strict your reliability needs are.

To turn hours into money, multiply by the rate. As a simple illustration, a standard 40-hour integration at a $50 hourly rate would be about $2,000, and at $100 an hour about $4,000. Your actual rate will differ, and a fixed-price quote should still tell you which of the seven layers above it covers.

What pushes the cost up

Poor or outdated documentation. Reverse-engineering behaviour costs hours.
Rate limits and quotas. You need queues, batching and back-off logic instead of a simple loop.
Many third parties at once. On the multi-carrier SIM activation platform, activations had to be routed across a dozen-plus carrier and MVNO backends, which meant per-carrier logic, asynchronous processing with retries and live progress for the user. Each extra system adds mapping and testing, not just one more endpoint.
Money involved. Payment flows demand idempotency, verified webhooks and careful reconciliation. A duplicate charge costs far more than the extra hours of safety work.
Real-time requirements. Live rates and instant status are harder than nightly syncs. On EXPRECO, the platform integrated UPS and FedEx APIs to calculate real-time shipping rates from package details and destination.
Dirty source data. If your records contain duplicates and gaps, cleaning them can cost as much as the integration. The CRM migration cleanup case shows how that plays out.

What keeps the cost down

Choose an API with good docs, a sandbox and official SDKs.
Decide the data rules before development starts: what syncs, which way, and which side wins.
Start with one flow end to end, then add more. A thin working slice beats a half-built everything.
Ask for retries, logging and alerts in the scope. They're cheaper to add now than after the first outage.
Use proven building blocks. For payments, Stripe's own guidance on webhooks and idempotent requests describes the safety patterns your developer should follow.

A real example: payments synced with a CRM

On the Stripe lead billing project, the workflow let lead-generation clients save a payment method without an immediate charge, then automatically charged it when qualified leads were delivered. The payment lifecycle was connected to GoHighLevel, with webhook-driven status synchronisation for successful and failed payments.

On paper that sounds like "Stripe plus a CRM". The parts that need care are the ones around the call: saving payment methods safely, reacting to success and failure events, and keeping both systems in agreement. That's why I scope by layers rather than by endpoint count. If you want the technical side of making retries safe, the idempotency keys article and the webhook delivery guide go into detail.

Questions to ask before you agree on a price

Which of the seven layers does this quote cover, and which does it leave out?
How are failures handled, and who is told when one happens?
Is there a sandbox, and will the integration be tested against it?
What happens when the third party changes or retires its API?
Will I get documentation and the code, so I'm not locked in?
What's the ongoing cost? Integrations need small amounts of maintenance each year.

When a ready-made connector is the better choice

Not every integration needs to be custom. If a no-code tool or a vendor's built-in connector already does what you need, use it. Custom work earns its cost when you need special business rules, reliable handling of money or high volume, or when no connector exists. For a related build-or-buy view on a bigger scale, see the custom CRM cost guide.

Frequently asked questions

How long does an API integration take?

A simple one-way integration can take about a week. A standard two-way integration usually takes one to three weeks, and multi-system work can take a couple of months. The documentation and your data quality are the biggest variables.

Why is a custom API integration so expensive?

The API call is cheap. The cost is in mapping, error handling, security, testing and monitoring, which keep the integration working after launch.

Do I pay for maintenance after launch?

Usually a little. Third parties change their APIs, keys expire and edge cases appear. Budget for light maintenance, and ask what is included.

Can I get a fixed price?

Yes, if the scope is clear. Provide the systems, the data rules and the failure handling you expect, and a good developer can price it. Vague scope leads to vague prices.

Key takeaways

The cost of an integration is in the layers around the API call, not the call itself.
Typical planning ranges are about 15 to 30 hours for simple, 20 to 60 for standard and 60 to 150+ for complex integrations.
Documentation quality, rate limits, data quality and money flows are the biggest cost drivers.
Ask what a quote covers: errors, retries, monitoring and handover all matter.

If you're planning an integration and want a clear, layered estimate from a senior engineer, book a free call and we'll scope it together.

Originally published at aqibjavaid.site.

React Native vs Flutter for a Startup MVP: How to Choose

Aqib Javaid — Sat, 10 Oct 2026 07:50:00 +0000

You want a mobile app on both iPhone and Android, and your budget says you can't build two separate native apps. So the question lands on your desk: React Native vs Flutter for an MVP. Developers will argue about it endlessly, and most of that argument won't help you decide.

Both can ship a good first version of your product. Both let one team build for iOS and Android from a single codebase. The difference that matters to a founder is rarely the technology itself. It's who you can hire, what you already own, and what your app needs to do on the phone.

This guide gives you a decision you can defend. I'll explain what each framework is in plain terms, where each one genuinely wins, and how I'd choose for a startup MVP. It comes from my mobile app development work with both frameworks.

What React Native and Flutter actually are

Both are cross-platform frameworks: you write the app once and ship it to iOS and Android. They get there in different ways.

React Native is built on JavaScript or TypeScript and React. Your screens are described in React components and rendered as real native interface elements on each platform.
Flutter is built by Google on the Dart language. It draws every pixel itself with its own rendering engine, so the app looks the same on every device.

That one difference explains most of what follows. React Native feels more like the platform it runs on. Flutter feels more like a single, consistent design system that you control completely.

The decision that matters most: your team

For an MVP, the best framework is usually the one your team can already use well.

If your web team writes React and TypeScript, React Native lets them reuse skills, tools and sometimes code such as validation, API clients and business logic. The user interface code is not shared one-for-one with the web, but the thinking is.
If you are hiring from scratch, JavaScript and TypeScript developers are easier to find than Dart developers in most markets. A bigger pool usually means shorter hiring and easier replacements.
If you have, or can hire, a developer who is strong in Flutter, don't switch frameworks just to follow a trend. A skilled Flutter developer will ship faster than a mediocre React Native one.

This is the same logic I used when comparing backends in the Laravel vs Node.js guide: the hiring pool and the team's current strength often outweigh small technical differences.

Where React Native tends to win

You already have React developers or a React web app. The learning curve is small.
You want the app to look and behave like each platform. Because it uses native components, system behaviour such as scrolling, text input and accessibility follows the platform's own rules.
You need a large ecosystem. There is a wide range of libraries, and most services publish a JavaScript SDK first. For a faster start, the React Native documentation points new projects to a framework such as Expo, which handles a lot of setup for you.
Over-the-air updates matter. The JavaScript layer can often be updated without a full store release, within the store rules.

Where Flutter tends to win

You want a highly custom, branded interface. Because Flutter draws everything itself, animations and unusual layouts look identical on every device.
You want predictable behaviour across devices. There are fewer surprises between Android versions and phone models.
You need one codebase for more than phones. Flutter also targets web and desktop, although its web support suits app-like products better than content sites that depend on search.
Complex, animation-heavy screens are the product. Maps, live tracking and custom dashboards are comfortable territory.

What I've built: a Flutter example

On the ION DASH logistics platform, I worked with Flutter customer and driver apps connected to a Laravel backend API. The platform covers custom quotes, automated dispatch, background GPS tracking, delivery confirmation, proof of delivery, Stripe PaymentIntents, Firebase Cloud Messaging and Google Maps navigation.

That project shows a point that matters more than the framework: most of the risk in a mobile product lives in the backend and the integrations around it, such as payments, push notifications, maps and background location. The app screens are the visible part. The hard part is making the whole system behave reliably when a driver's phone loses signal. Whichever framework you pick, plan the API and the integrations first.

What affects the cost of a mobile MVP

Framework choice rarely changes the budget as much as these do:

The number of screens and user roles. A customer app and a driver app are two products, not one.
Integrations. Payments, maps, push notifications, login providers and third-party APIs each add work and testing.
Background features. Location tracking, offline mode and background sync are more complex than ordinary screens.
Store requirements. Apple and Google review processes, privacy declarations and testing on real devices take time.
The backend. Most apps need an API, an admin panel and a database before the first screen is useful.

For general MVP budgeting, I covered realistic price tiers in the custom web app MVP cost guide, and the early technical decisions that save money later are in the SaaS planning checklist.

When neither is the right answer

Cross-platform isn't always correct. Consider going native, or skipping the app, when:

Your product depends on deep, cutting-edge platform features, such as advanced camera, augmented reality or heavy hardware integration.
You only need one platform to prove the idea.
A responsive web app or a progressive web app would test your idea faster and cheaper. Many MVPs don't need the app stores at all yet.

Starting with a web product and adding the mobile app after you've confirmed demand is a perfectly good strategy.

A simple way to decide

Answer these in order and stop at the first clear result:

Do you already have a team with strong skills in one of them? Use that one.
Is your web product built in React, and do you want to share thinking and tools? React Native.
Is a custom, animated, identical-everywhere interface central to the product? Flutter.
Do you need to hire quickly in a market where JavaScript developers are much easier to find? React Native.
Still unclear? Build the single riskiest screen in both for a day and compare. A small spike is cheaper than the wrong choice.

Frequently asked questions

Is React Native or Flutter better for a startup MVP?

Neither is better in general. React Native often wins on hiring and web skill reuse, and Flutter often wins on custom visuals and consistency. Pick based on your team and your product.

Is Flutter faster than React Native?

Both are fast enough for the vast majority of MVPs. Performance rarely decides the choice. Heavy animation and complex lists need care in either framework.

Can I switch frameworks later?

Moving between them means rewriting the app screens, although your backend and API stay the same. That's one more reason to keep business logic in the API rather than in the app.

How long does a cross-platform MVP take?

It depends on the scope: roles, integrations and background features. A focused first version with a small set of features is realistic in weeks, not days, and the backend usually takes as much effort as the screens.

Key takeaways

Both frameworks can ship a good MVP, so decide on team, hiring and product needs.
React Native suits React teams and platform-native behaviour. Flutter suits custom, consistent interfaces.
The backend and integrations carry most of the risk and cost, so plan them first.
A web app or PWA is sometimes the better first step.

If you're planning a mobile MVP and want a senior engineer to help you choose and scope it, book a free call and we'll work through it together.

Originally published at aqibjavaid.site.

Laravel Hosting Compared: Forge, AWS and DigitalOcean Cost

Aqib Javaid — Fri, 09 Oct 2026 07:40:25 +0000

Choosing where to host a Laravel app feels like a technical decision, but it's mostly a business one. Pick too small and the app falls over on your best sales day. Pick too big or too clever and you pay for capacity and complexity you don't use, every month, for years. This guide compares the main Laravel hosting options and their cost so you can pick one with your eyes open.

I'm not going to crown a winner, because there isn't one. The right answer depends on your traffic, your team and how much server work you want to own. What I can do, drawing on my cloud and DevOps deployment work, is show how each option works, what it really costs beyond the headline price, and which kind of project each one suits.

[!NOTE]
Prices below are rough, based on the providers' public pricing pages as I last checked them, and they change. Always confirm on the provider's own page before you budget.

The main ways to host a Laravel app

There are really five categories:

Shared hosting. Cheapest, but limited. Many plans can't run queue workers or give you SSH, which a serious Laravel app needs.
A VPS you manage yourself. A virtual server from DigitalOcean, Hetzner or similar. Cheap and flexible, but you own security, updates and backups.
A VPS managed through a tool. Laravel Forge provisions and manages servers that you rent from a provider. You pay Forge a subscription plus the provider for the server.
A managed Laravel platform. Laravel Cloud runs your app for you, with a base plan plus usage-based charges.
AWS with real infrastructure. EC2, load balancers, managed databases and queues, or serverless through Laravel Vapor. Powerful, and the most work to run well.

What each option costs in practice

The monthly price on the homepage is rarely the full bill. Here is what to look at for each one.

Option	Typical starting cost	What you pay extra for	You still own
Shared hosting	Very low	Little	Almost nothing, but limits are tight
DigitalOcean droplet	From a few dollars a month for the smallest sizes, roughly $12 to $24 for a size that suits a small production app	Backups, managed database, load balancer	Server security, updates, deployments
Forge on a VPS	Forge subscription (from roughly $12 a month) plus the server	The server, database and backups	Server choices, monitoring, scaling
Laravel Cloud	A base plan from roughly $5 a month plus usage	Compute, database and bandwidth as you use them	Mostly the application itself
AWS (EC2, RDS, etc.)	Low for a single small instance, grows quickly with a load balancer, managed database and queues	Nearly every component	Architecture, security, cost control

These are ballpark figures taken from DigitalOcean's droplet pricing, the Forge and Laravel Cloud pricing pages and AWS Lightsail pricing, and they will have moved by the time you read this.

The number that surprises most founders isn't the server. It's the hidden extras: backups (often a percentage of the server price), a managed database, a staging environment, monitoring, and an hour of an engineer's time every time something needs attention. A cheap server that costs your team a day a month in maintenance isn't cheap.

Which one fits which project

A small app or an MVP

Start simple. A single small VPS managed with Forge, or a small Laravel Cloud plan, is usually enough. You get deployments, SSL, a database and queue workers without building infrastructure. Don't build for ten times your current traffic.

A growing SaaS with background jobs

At this stage, the things that matter are queue workers, a separate database, scheduled jobs and zero-downtime deployments. Forge with two or three servers, or Laravel Cloud, handles this well. I covered the deployment side in the zero-downtime deployments guide and the job side in the queue architecture article.

Heavy or spiky traffic, or compliance needs

This is where AWS earns its complexity: autoscaling, managed databases, private networking and audit trails. When I worked on the Violerts compliance platform, the stack included Laravel Horizon, Redis, Nginx, Linux, AWS and CI/CD. That level of setup makes sense for a data-heavy SaaS. It would be overkill for a brochure app.

A team without a server person

If nobody on your team wants to patch servers at 2 a.m., pay for a managed platform. The monthly premium is smaller than one bad weekend.

Forge vs AWS vs DigitalOcean: the honest comparison

These three are the ones people ask about most, but they aren't direct competitors. DigitalOcean and AWS provide the servers. Forge is the tool that sets those servers up for you. You can use Forge on top of either provider, or even on a server you already rent elsewhere.

Choose DigitalOcean (with Forge) when you want predictable pricing, simple infrastructure and a clear bill. It is a sensible default for most small and mid-size Laravel apps.
Choose AWS when you need services you can't get elsewhere, such as fine-grained networking, specific compliance controls or serious autoscaling, and you have someone who can run it.
Choose Forge when you want the speed of managed deployments without giving up control of your servers.

On the Henceforward migration, the work involved moving a site onto Scaleway with Laravel Forge, along with security hardening and production tuning. It's a good example of the pattern: a managed tool on top of ordinary servers, chosen for a clean and maintainable setup rather than for scale.

How to choose without regretting it

Ask these five questions in order:

What breaks if the site is down for an hour? If the answer is "a lot", budget for redundancy and monitoring from day one.
Who will maintain it? If it's nobody, pick a managed option.
How spiky is the traffic? Steady traffic suits a fixed server. Wild spikes suit autoscaling or serverless.
Where does the data have to live? Regulation or customer contracts can fix the region and the provider.
How will you deploy and roll back? Choose hosting that makes this a button, not a ritual.

If you're already on a setup that has grown messy, the lesson from stabilising an AWS production environment applies: fix the foundations before you add more servers. That review is where I start on any hosting engagement.

When not to move your hosting

Migrating hosts is risky and rarely fixes a slow app. If your pages are slow, look at the queries and the code before you throw bigger servers at them. I walked through that in the guide to finding slow MySQL queries in Laravel. Move hosting when you've outgrown your current setup or you can't get the features you need, not because a different logo promises speed.

Frequently asked questions

How much does it cost to host a Laravel app?

A small production app can run on a single server for tens of dollars a month. Costs rise with traffic, databases, staging environments and backups. The bigger cost is usually engineering time, not the server.

Is Forge a hosting provider?

No. Forge is a server management tool. You connect your own account at a provider such as DigitalOcean or AWS, and Forge sets up and deploys to the servers you rent there.

Is Laravel Cloud better than Forge?

They suit different people. Cloud takes more of the infrastructure off your hands and charges for usage. Forge gives you more control over the servers at a flat subscription price plus the server cost.

Do I need AWS for a serious Laravel app?

Not usually. Many busy Laravel apps run well on a few well-sized servers. Choose AWS when you need what it uniquely offers.

Key takeaways

The headline server price is only part of the bill. Count backups, databases, staging and maintenance time.
DigitalOcean and AWS provide servers, Forge manages them, and Laravel Cloud is a managed platform. They aren't all the same kind of thing.
Start small and simple, and move up when traffic or compliance requires it.
Fix performance in the code and database before you spend more on servers.

If you're deciding where to host a Laravel app, or you suspect you're overpaying for your current setup, book a free call and I'll help you choose.

Originally published at aqibjavaid.site.

Why WooCommerce Admin Is Slow and How to Fix It

Aqib Javaid — Thu, 08 Oct 2026 13:56:45 +0000

Your WooCommerce store looks fine to customers, but the admin has become painful. The Orders screen takes ten seconds to load, saving a product hangs, and the dashboard spins every time you open it. If you've been searching for a WooCommerce slow admin fix, the good news is that the admin is usually slow for a small number of identifiable reasons, and most of them are fixable without rebuilding the store.

A slow admin also costs money in ways that are easy to miss. Staff process orders more slowly, product updates get postponed, and a server that struggles with the back office is often one busy sale away from struggling with the front end too.

This guide is the order I work in in my WordPress and WooCommerce development work when I'm asked to speed up a store: find what is slow, fix the database and background tasks, then look at hosting. It is written for store owners who want to understand what a developer will check, and for developers who want a checklist.

Why is the WooCommerce admin slow?

The storefront and the admin behave very differently. Visitors mostly get cached pages, so the store can feel quick even when the server is struggling. The admin is never cached. Every click runs PHP and database queries in full, so any weakness shows up there first.

The usual causes, roughly in the order I find them:

Too many or heavy plugins. Each plugin can add database queries, remote API calls and scripts to every admin page.
A bloated wp_options table. Plugins store data there that loads on every request, including pages you never see.
Orders stored in the old posts tables. Large stores slow down when orders live in the general posts and post meta tables.
A backlog of background tasks. WooCommerce relies on the Action Scheduler for emails, webhooks and more. A pile of failed or pending actions makes everything heavier.
No object cache and an old PHP version. These make every database-heavy screen slower than it needs to be.
Underpowered hosting. Shared hosting with limited PHP workers and slow storage can't keep up with a growing catalogue.

Guessing at this list wastes time. Measure first.

Find the real bottleneck before changing anything

Take a full backup before you start. Then install the free Query Monitor plugin on a staging copy of the site, or on production for a short test if you have no staging.

Open the slow screen, for example WooCommerce, Orders, and look at three things in Query Monitor:

Slow queries. It lists queries by time and tells you which plugin or theme triggered each one.
Queries by component. If one plugin owns most of the query time, you have your first suspect.
HTTP API calls. Remote requests made while the page loads, for example a plugin checking a licence server, can add seconds by themselves.

Write down the load time and the biggest offenders before you change anything. You will need those numbers to prove each fix helped.

If you know how to read the MySQL side of this, the same measure-first approach I described in the guide to finding slow MySQL queries in Laravel applies here: the slowest total time matters more than any single dramatic query.

Fix 1: Turn on High-Performance Order Storage

By default, older WooCommerce stores keep orders in WordPress's general posts tables. High-Performance Order Storage (HPOS) moves orders into dedicated tables, which makes order screens and queries faster as the number of orders grows.

You enable it under WooCommerce, Settings, Advanced, Features. Before you do, check that every plugin that touches orders (payments, shipping, invoicing, subscriptions) says it supports HPOS, and run the migration on staging first. WooCommerce can keep both storage locations in sync during a transition, so you can switch back if something breaks. New stores on recent WooCommerce versions use HPOS by default.

Fix 2: Clean up `wp_options` autoload data

Every row in wp_options marked as autoload is loaded on every request. Plugins that have been removed often leave large rows behind. To see the biggest ones, run this on a backup or staging database:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY bytes DESC
LIMIT 20;

The autoload values differ between WordPress versions, which is why the query lists several. If the total autoloaded size is several megabytes, or a handful of rows dominate it, you have found a real problem. Remove rows that belong to plugins you've uninstalled, and ask the plugin vendor about the rest. Don't delete rows you can't identify.

Expired transients also pile up. You can clear them safely with WP-CLI:

wp transient delete --expired

Fix 3: Clear the Action Scheduler backlog

Go to WooCommerce, Status, Scheduled Actions. If you see thousands of pending or past-due actions, or a long list of failed ones, the scheduler is working against you. Find out what created them: a misconfigured email plugin, a webhook that keeps failing, or a sync job that runs too often.

Fix the source first. If you only delete the backlog, it will come back. Once the cause is gone, you can clear the old completed and failed actions, and WooCommerce will clean up completed ones on its own schedule.

Also check that WordPress's own cron isn't doing heavy work during page loads. On a busy store, it's common to disable the page-load trigger and run a real server cron job instead, which makes the timing predictable and removes the work from visitors' requests.

Fix 4: Cut plugin weight

Deactivate plugins one at a time on staging and reload the slow screen. When a plugin makes a big difference, ask whether you really need it, whether a lighter one does the same job, or whether a few lines of custom code replace it. This is where a developer earns their fee: replacing three heavy plugins with one small piece of code often speeds up the admin more than any server upgrade.

Watch for plugins that run on every admin page but only matter on one, such as analytics widgets, marketing dashboards and "suggestion" panels. Many have a setting to turn the dashboard widget off.

Fix 5: Add an object cache and update PHP

A persistent object cache such as Redis stores the results of repeated database lookups, so the admin doesn't repeat them on every click. It matters most on stores with many products, many orders or heavy plugins. I wrote about how to set up caching without serving stale data in the Redis caching architecture article. The invalidation rules there apply to any application, not just Laravel.

Check your PHP version at the same time. WordPress publishes the versions it recommends, and each newer PHP release is generally faster than the one before. Test plugin compatibility on staging, then upgrade.

When the hosting is the problem

If the plugins are tidy, the database is clean and the admin is still slow, look at hosting. Signs include a low PHP worker limit, slow disk, a database server shared with many other sites, or no ability to install an object cache.

When I worked on the Henceforward WordPress migration, the project covered moving the site to Scaleway with Laravel Forge, strengthening security and tuning the production environment for reliability and performance. Moving to a server you control is not always the answer, but it gives you the options (caching, PHP settings, server-level cron) that cheap shared hosting takes away. For a broader look at stabilising a production setup, see the write-up on fixing an unstable AWS production environment.

When not to keep patching

Sometimes the honest answer is that the store has outgrown WordPress. If your plugin stack is enormous, you rely on heavy custom logic, or you need real-time inventory and order flows, a custom build may cost less over three years than constant tuning. I compared those trade-offs in Shopify versus custom ecommerce. For most WooCommerce stores, though, the fixes above are enough, and tuning an existing store is exactly the kind of work I take on.

Frequently asked questions

Why is my WooCommerce admin slow but my storefront fast?

The storefront is usually served from a page cache. The admin can't be cached, so slow queries, heavy plugins and background tasks only show up there.

Will a caching plugin fix a slow WooCommerce admin?

Page caching plugins don't help the admin. An object cache can, but it won't fix a bloated options table or a plugin making slow remote calls. Find the cause first.

Is it safe to enable HPOS on a live store?

Test on staging first and confirm that every order-related plugin supports it. Keep a backup, and use the compatibility mode that syncs both storage locations while you check everything works.

How long does it take to fix a slow WooCommerce admin?

It depends on the cause. A cleanup of options, transients and scheduled actions can be done quickly. Replacing plugins or moving hosts takes longer and needs testing.

Key takeaways

The admin is slow because it can't be cached, so measure it with Query Monitor before you change anything.
The big wins are HPOS, a clean wp_options table, a cleared Action Scheduler backlog and fewer heavy plugins.
Add an object cache and a current PHP version after the basics, not instead of them.
If hosting limits you, move to a setup you can tune, and know when a store has outgrown WordPress.

If your WooCommerce admin is holding your team back and you want a senior developer to find the cause, book a free call and we can go through it together.

Originally published at aqibjavaid.site.

How to Find and Fix Slow MySQL Queries in Laravel

Aqib Javaid — Wed, 07 Oct 2026 00:02:36 +0000

A Laravel page that took 200 milliseconds in development takes three seconds in production, and nobody changed the code. That is the usual story behind a Laravel slow queries fix: the data grew, an index was never added, or one innocent-looking loop started firing hundreds of queries per request.

The good news is that slow MySQL queries are among the most fixable performance problems. You don't need a rewrite or a bigger server. You need to find the queries that actually hurt, read what MySQL says about them, and apply one of a handful of well-known fixes.

This guide is the process I follow in my database optimization and backend performance work when I'm asked to find and fix slow queries in a Laravel app: measure first, read the query plan, fix the cause, and prove the result. It is written for developers doing the work and for founders who want to know what a performance fix really involves.

Start by measuring, not guessing

The most common mistake is adding indexes or cache layers before knowing which queries are slow. Two kinds of problem hide behind "the page is slow":

One slow query. A single statement scans a big table and takes seconds.
Many fast queries. Each takes 2 milliseconds, but there are 400 of them on one page. This is the classic N+1 problem, and no index will fix it.

Laravel lets you catch both. For a quick look at one request, log every query with its time:

use Illuminate\Support\Facades\DB;

DB::listen(function ($query) {
    logger()->info($query->sql, [
        'bindings' => $query->bindings,
        'ms' => $query->time,
    ]);
});

For production, you want an alarm instead of a firehose. whenQueryingForLongerThan runs a callback when the total time spent in queries during a request passes a limit:

use Illuminate\Database\Connection;
use Illuminate\Support\Facades\DB;

DB::whenQueryingForLongerThan(500, function (Connection $connection) {
    logger()->warning('Slow request: over 500ms spent in queries', [
        'url' => request()->fullUrl(),
    ]);
});

Put either snippet in a service provider's boot method. The second one tells you which pages to look at first.

Turn on the MySQL slow query log

Laravel shows you what the application sent. MySQL's own slow query log shows what the database really spent time on, including queries from queue workers and scheduled jobs that your request-level tools never see.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = 'ON';

Those settings last until the server restarts, so add them to the MySQL configuration file once you are happy with them. On a busy server, leave log_queries_not_using_indexes off at first because it can be noisy, and set long_query_time to something like one second.

After a day of normal traffic, group the log by query shape. MySQL ships with mysqldumpslow, and Percona's pt-query-digest does the same job in more detail. You are looking for the queries with the highest total time, which is the number of runs multiplied by the average duration. A 100 ms query that runs 50,000 times a day matters more than a 4-second report that runs twice.

If you already have error tracking and metrics in place, the same signals belong there too. I covered that setup in the Laravel observability guide.

Read the query plan with EXPLAIN

Once you have a suspect, ask MySQL how it runs the query. Prefix it with EXPLAIN, or call explain() on a query builder in a recent Laravel version:

DB::table('orders')
    ->where('customer_id', 4821)
    ->where('status', 'paid')
    ->orderByDesc('created_at')
    ->limit(50)
    ->explain()
    ->dump();

Reading the EXPLAIN output takes practice, but four columns do most of the work:

Column	What to look for
`type`	`ALL` means a full table scan. `ref`, `range` and `const` mean an index is used.
`key`	The index MySQL chose. `NULL` means none.
`rows`	MySQL's estimate of rows it must examine. Compare it with the rows you actually return.
`Extra`	`Using filesort` and `Using temporary` mean extra work to sort or group the result.

If a query returns 50 rows but rows says 2,400,000, MySQL is reading the whole table to find them. That is the gap you close with an index. On MySQL 8.0.18 and later, EXPLAIN ANALYZE goes further and runs the query to show real timings next to the estimates.

Fix the five causes I see most often

1. A missing or wrong index

For the query above, the right index covers the equality filters first and the sort column last:

Schema::table('orders', function (Blueprint $table) {
    $table->index(['customer_id', 'status', 'created_at']);
});

Column order matters. Put columns you compare with = first, then the column you sort or range-filter on. An index on status alone is usually useless, because a column with a few distinct values barely narrows the search.

Don't add an index for every query. Each index slows down writes and uses disk. Add the ones your slowest, most frequent queries need, then re-run EXPLAIN to confirm MySQL uses them.

2. The N+1 problem

This loop looks harmless:

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

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

That is 51 queries for a 50-row page. Load the relationship up front, as the Laravel eager loading docs describe:

$orders = Order::with('customer:id,name')->latest()->limit(50)->get();

To stop N+1 from coming back, make Laravel complain about it in development. In a service provider:

use Illuminate\Database\Eloquent\Model;

Model::preventLazyLoading(! app()->isProduction());

Now a lazy-loaded relationship throws an exception while you are building the feature, instead of costing you a slow page in production. Many teams find this one line pays for itself within a week.

3. Selecting far more than you need

SELECT * on a wide table drags large text and JSON columns across the wire for every row, even when the page shows two fields. Select only the columns you use, and use withCount() or withSum() instead of loading a whole relationship to count it.

For jobs that walk a big table, use chunkById() instead of get(). It keeps memory flat and avoids the skipped or repeated rows that plain chunk() can produce when you update the rows you're reading.

4. Queries that can't use an index

Some queries ignore a perfectly good index:

Wrapping the column in a function: WHERE DATE(created_at) = '2026-10-01'. Use a range instead: created_at >= '2026-10-01' AND created_at < '2026-10-02'.
A leading wildcard: WHERE name LIKE '%smith'. An index can't help here. Real search needs a different tool, which I wrote about in the full-text search architecture article.
Comparing a number column to a string, which can force MySQL to convert every row.

5. Deep pagination and expensive counts

paginate() runs a COUNT(*) query on every page, and OFFSET 200000 makes MySQL read and throw away 200,000 rows before returning yours. For large tables, switch to simplePaginate() when you don't need page numbers, or cursorPaginate() for infinite scroll and APIs. Both avoid the deep offset.

Prove it worked

Never trust a fix you haven't measured. For every change:

Record the query time and the EXPLAIN output before.
Apply one change.
Re-run EXPLAIN and time the query with production-sized data. A fast query on a 500-row dev database proves nothing.
Watch the slow query log for a day to confirm the real traffic improved.

Run index migrations carefully on a big table. Adding an index to millions of rows can lock or slow the table while it builds, so schedule it for a quiet period, and test the migration on a copy of production data first.

What I look at when the database is the bottleneck

On client work, performance problems rarely come from one place. When I audited the freight forwarding platform, reviewing the database structure was part of understanding the system before any new development. That is the same habit this guide describes: read how the data is organised before you tune individual queries.

On data-heavy products like Violerts, which pulls property data from several city agencies into one platform, the shape of the queries matters as much as the infrastructure around them. If your app is slow and you aren't sure where the time goes, that service starts with exactly this measurement step.

When not to add a cache

Caching is the tempting shortcut: wrap the slow query in Cache::remember() and move on. It works, but it hides the problem, and you inherit a new one, which is knowing when the cached data is stale. Fix the query first. Add caching only for queries that are already well-indexed and still too heavy to run on every request. The Redis caching architecture guide covers how to do that without serving wrong data.

Frequently asked questions

How do I find slow queries in Laravel?

Log query times with DB::listen, set an alarm with DB::whenQueryingForLongerThan, and turn on MySQL's slow query log. Start with the queries that have the highest total time, not just the slowest single run.

Will adding an index always make a query faster?

No. An index only helps if MySQL chooses it, and it adds cost to every write. Check with EXPLAIN before and after, and remove indexes that nothing uses.

Is Telescope good enough for finding slow queries?

Laravel Telescope is useful in development and staging because it lists the queries for each request and flags slow ones. In production it adds overhead, so most teams rely on the slow query log and an observability tool there.

When is the problem not the queries?

If query time is small and the page is still slow, look at external API calls, large responses, missing queue offloading or a saturated server. Measure before blaming the database.

Key takeaways

Measure first: find the queries with the highest total time, not the ones you suspect.
Use EXPLAIN to see whether MySQL scans the whole table or uses an index.
Most Laravel slowdowns come from five causes: missing indexes, N+1 loading, selecting too much, queries that can't use an index, and deep pagination.
Turn on preventLazyLoading in development to catch N+1 early.
Prove every fix with before and after numbers on production-sized data.

If your Laravel app is getting slower as it grows and you want a senior engineer to find the cause, book a free call and we can look at it together.

Originally published at aqibjavaid.site.

Shopify vs Custom Ecommerce: When Custom Is Worth It

Aqib Javaid — Mon, 05 Oct 2026 05:46:52 +0000

If you're launching an online store, the Shopify vs custom ecommerce question usually comes up in the first week. Shopify is quick and proven. A custom build can do exactly what you want. The wrong choice either burns money on engineering you didn't need or traps a growing business inside a platform it has outgrown.

I build both kinds of stores and integrations, so I don't need either answer to be right. In this guide I'll explain what you're really comparing, when Shopify is the smarter choice, the specific situations where custom is worth it, how to compare the real cost over three years, and a short checklist to decide.

If you already know you need something Shopify can't do, that's the core of my ecommerce development and integrations work.

What are you actually comparing?

The two options are different in kind.

Shopify is a hosted store platform. Hosting, checkout, payments, product management, themes and an app store come in one package, and you pay a monthly plan plus fees. You configure it rather than build it.
Custom ecommerce means a store built in code on a framework such as Laravel or Next.js, often with Stripe for payments and your own admin. You own the code, you pay to build it, and you pay to host and maintain it.

There's also a middle path: keep Shopify as the engine for products, checkout and orders, and build custom pieces around it, such as a custom storefront, integrations with your ERP or shipping systems, or special pricing logic.

Shopify vs custom ecommerce: side by side

Factor	Shopify	Custom ecommerce
Time to launch	Days to weeks	Months
Upfront cost	Low	High
Ongoing cost	Monthly plan, app subscriptions and transaction fees	Hosting, maintenance and developer time
Checkout control	Limited, and more flexible only on higher plans	Complete
Custom pricing and workflows	Possible through apps and workarounds	Built exactly to fit
Integrations (ERP, shipping, inventory)	Apps and APIs, within platform limits	Any system with an API
Security and PCI burden	Handled by Shopify	Yours, though a provider like Stripe carries card data
You own	Your data and content, not the platform	The code, the data and the platform

Neither column wins outright. Each row trades speed and convenience against control.

When Shopify is the better choice

For most new stores, Shopify is the right place to start. Choose it when:

you sell standard products with standard variants, shipping and discounts;
you want to launch quickly and test whether the product sells;
you don't have a developer or a big budget for custom work;
your edge is your product and marketing, not how checkout works.

A store that works on Shopify costs far less to launch and maintain than a custom one, and a lot of apps already cover common needs. Don't build custom to avoid a monthly fee when your real risk is not selling anything yet.

When custom ecommerce is worth it

Custom starts to pay off when the platform's limits cost you money or block your model. The situations I see most:

Pricing or products that don't fit a standard catalogue: B2B price lists per customer, quotes, configurable products, rental or booking-style items.
Checkout or order flow that must be unique: special approvals, multi-step orders, split shipments, custom payment flows.
Deep integration with other systems: an ERP or warehouse system as the source of truth, real-time shipping rates from carriers, or live stock from suppliers.
A marketplace: several vendors, payouts, messaging, and rules between buyers and sellers.
Fees that become material at scale: when plan fees, app subscriptions and gateway surcharges add up to a meaningful share of revenue.
Ownership and flexibility: you want the freedom to change anything without asking a platform.

Check Shopify's current pricing and its notes on checkout customization before deciding, since plans, fees and what each plan allows change over time.

The middle path: Shopify plus custom pieces

You don't have to pick one extreme. Many stores keep Shopify for what it does well and add custom pieces for what it doesn't:

a custom storefront for speed and design freedom, while Shopify handles products and checkout;
a custom app or service that syncs orders and stock with your ERP or warehouse;
custom pricing, quoting or shipping logic that runs beside the store.

This is often the cheapest way to remove the one painful limit without rebuilding everything. If you're weighing a custom front end, my comparison of Next.js and WordPress for business sites covers the same trade-offs.

How to compare the real cost over three years

Comparing the monthly bill with the build price is misleading. Compare total cost over three years instead:

Shopify 3-year cost =
    plan fees x 36
  + apps x 36
  + transaction and gateway surcharges (a share of revenue)
  + theme and workaround development

Custom 3-year cost =
    build cost
  + hosting x 36
  + maintenance (about 15-20% of build cost per year)
  + payment processor fees
  + developer time for new features

Two points matter most. First, payment processing fees apply on both sides, so compare the extra costs: Shopify's plan, app and surcharge costs against your custom build and upkeep. Second, as revenue grows, percentage-based costs grow with it, while a custom platform's costs stay mostly fixed.

As a rough ballpark, and not a quote, I'd estimate a custom store with a standard catalogue, Stripe payments and an admin area at 300 to 800 hours of work. One with B2B pricing, custom checkout rules and ERP integration is more like 800 to 2,000 hours or more. At a wide $25 to $100 an hour, that's roughly $7,500 to $80,000 for the first and $20,000 to $200,000 or more for the second. For general budgeting logic, see what it costs to build an MVP.

Examples from real projects

Three projects show where custom logic earned its place.

On the EXPRECO logistics quote system, I built a quote platform in Laravel and Livewire that integrates the UPS and FedEx APIs to calculate real-time shipping rates from package details and destinations. Live carrier rates tied to a custom workflow are the kind of requirement that pushes a store towards custom or custom-around-a-platform.

For Stripe lead billing with GoHighLevel, I built a Stripe workflow that saves payment methods without an immediate charge and charges them automatically when qualified leads are delivered, with webhook-driven status sync. A payment model like that doesn't fit a standard checkout.

Planuojam is a headless marketplace in five languages with real-time messaging and Stripe payments. Marketplaces are a classic case where a standard store platform stops fitting. For the integration side of any of these, see my notes on third-party API integration best practices.

A simple decision checklist

Answer these honestly:

Can you describe your catalogue and checkout with standard features, or do you need custom pricing and order rules?
Do you need to connect an ERP, warehouse or carrier system in real time?
Is this a marketplace with several vendors or special payment flows?
Have you proven demand yet, or are you still testing the idea?
What does the platform cost you at your expected revenue, including plans, apps and fees?

Mostly "standard" and "still testing" points to Shopify. Custom pricing, deep integrations and a marketplace model point to custom, or to Shopify with custom pieces. If it's close, start on Shopify and revisit once a specific limit is costing you real money.

When not to go custom

Custom is the wrong call if:

you haven't validated that people will buy;
your needs fit standard features and a few apps;
you can't fund both the build and ongoing maintenance;
nobody on your side can own the product after launch.

Frequently asked questions

Is custom ecommerce cheaper than Shopify?

Not at the start. A custom build costs far more upfront. Over several years it can be cheaper for large stores where percentage-based fees and app subscriptions add up, or where Shopify can't support your model at all.

How long does a custom ecommerce site take to build?

A simple custom store takes a few months with an experienced developer. Stores with custom pricing, integrations or marketplace features take longer. Launching a smaller first version shortens the timeline.

Can I move from Shopify to custom later?

Yes. Many businesses start on Shopify and move, or add custom pieces, once a specific limit is costing them. Plan the move so you keep your URLs, product data and customer accounts.

What about payments and card security on a custom store?

Use a provider such as Stripe so card data never touches your servers. That keeps your compliance burden far smaller than handling cards yourself.

Key takeaways

Shopify is a hosted platform you configure. Custom ecommerce is a store you build and own.
Start with Shopify for standard products and fast testing.
Go custom, or custom around Shopify, for unusual pricing, checkout, integrations or marketplaces.
Compare total cost over three years, not the monthly bill against the build price.
Budget 15-20% of a custom build's cost per year for upkeep.

If you're deciding between Shopify and a custom build, book a call and I'll help you pick the option that fits your store and your budget.

Originally published at aqibjavaid.site.