DEV Community: Aniruddha Pramanick

Why Custom PHP Still Beats Page Builders for Indian Business Websites

Aniruddha Pramanick — Sat, 04 Jul 2026 09:47:33 +0000

Overview

The Indian SMB market is flooded with ₹999 website offers built on WordPress themes, Wix, or Squarespace. For a business owner evaluating options, the templated route looks attractive — it is fast, it is cheap, and the preview looks professional enough. But after building over 150 custom websites for businesses across Kolkata, Howrah, and pan-India, the exposed limitations of page builders versus custom PHP development are not theoretical — they are measurable, repeatable, and financially significant for the business owner.

This article breaks down the technical and business-level differences with specific data points, not opinions.

The Core Architectural Difference

A page builder (WordPress + Elementor, Wix, Squarespace, Webflow) operates on a generalized abstraction layer. The platform must accommodate every possible use case — a photographer portfolio, a restaurant menu, an e-commerce store, a SaaS dashboard — so every page load carries the overhead of that generalization. Unused CSS modules, JavaScript libraries for features you never activated, database queries for plugins you installed but do not use on that page.

Custom PHP (with MySQL, or PostgreSQL, or any relational database) operates on a purpose-built architecture. Every line of code exists because your application requires it. No unused dependencies. No abstraction tax.

The performance implications are direct. A typical WordPress + Elementor site loads 2.5–5 MB per page, makes 60–120 HTTP requests, runs 50–200 database queries per page load, has a Time to First Byte of 600–1500ms on shared hosting, and an LCP of 3.5–8.0 seconds on mobile. An optimized custom PHP site doing the same job loads 0.4–1.2 MB, makes 15–30 HTTP requests, runs 5–20 database queries, achieves TTFB of 100–300ms, and an LCP of 1.0–2.5 seconds on mobile.

These are not cherry-picked numbers. Run any default WordPress theme with 5 popular plugins through Google PageSpeed Insights on mobile, and you will consistently see performance scores between 30–55. A clean custom PHP page with the same content will score 75–95.

Google Core Web Vitals — LCP, CLS, INP — are confirmed ranking signals since 2021. A business website that loads in 1.8 seconds has a measurable ranking advantage over one that loads in 5.5 seconds, assuming equivalent content quality and backlink profiles.

Where Page Builders Actually Fail Indian Businesses

Payment Gateway Integration Complexity

Indian payment gateways (Razorpay, Paytm Business, CCAvenue, PhonePe Business) require server-side callback handling, hash verification, webhook processing, and refund management. WordPress plugins for these gateways exist, but they frequently break during gateway API updates, introduce security vulnerabilities through plugin conflicts, and offer limited customization of the checkout flow.

With custom PHP, the integration is direct — you write the callback handler, you control the hash verification, you manage the webhook endpoint. When Razorpay updates their API from v1 to v2, you update one file. You do not wait for a plugin developer in another timezone to release a compatibility patch.

Admin Panel Customization

A business owner managing a service-based company in Kolkata does not need WordPress 47-menu admin interface. They need a field to update their phone number, an image uploader for portfolio items, a text editor for service descriptions, and a toggle to show or hide homepage sections.

Custom PHP lets you build exactly this — a 5-screen admin panel that does precisely what the business needs, nothing more. The learning curve drops from weeks to minutes.

At Infinite Option, every client website ships with a purpose-built admin panel. The client can update content, upload images with alt text, manage SEO fields, and reorder sections — without touching code or navigating a bloated CMS interface.

Security Surface Area

WordPress powers 43% of the web, which makes it the single largest attack target for automated exploits. Every installed plugin is an additional attack vector. The average WordPress site has 20–30 plugins, each maintained by a different developer with different security practices and update cadences.

Custom PHP reduces the attack surface to your own code. No third-party plugin backdoors. No xmlrpc.php brute force vectors. No publicly known directory structures that automated scanners can fingerprint.

This does not mean custom PHP is inherently secure — poorly written PHP is worse than well-maintained WordPress. But for a competent development team, the security posture of a custom application is controllable in a way that a plugin-dependent CMS is not.

Hosting Cost Efficiency

A WordPress site with WooCommerce, a page builder, caching plugin, security plugin, and backup plugin requires minimum 2GB RAM to run without timeout errors. That is a ₹1,500–₹3,000/month VPS in the Indian hosting market.

An equivalent custom PHP site — same features, same traffic — runs on 512MB–1GB RAM because it is not loading 200MB of WordPress core + plugin overhead into memory on every request. Hosting cost: ₹500–₹1,000/month.

Over 3 years, the hosting cost difference alone is ₹36,000–₹72,000. That often exceeds the initial savings from choosing a ₹5,000 WordPress template over a ₹18,000 custom build.

When Page Builders ARE the Right Choice

Custom PHP is not universally superior. Page builders win in specific scenarios.

For content-heavy blogs where the primary use case is publishing 50+ articles per month with categories, tags, RSS feeds, and author management, WordPress content management architecture is purpose-built for this. Rebuilding it in custom PHP is reinventing the wheel.

For rapid prototyping where you need a landing page live in 48 hours to test a business idea, a page builder is the correct tool. Speed-to-market outweighs architectural purity.

For solopreneurs with zero budget where the total spend is ₹2,000 including domain and hosting for the first year, a free WordPress theme on shared hosting is the only viable option. Custom development has a minimum cost floor that exceeds this.

For e-commerce with 500+ SKUs, Shopify or WooCommerce inventory management, variant handling, and shipping calculation ecosystems are mature and tested. Building equivalent functionality from scratch in PHP requires 200–400 development hours.

The Decision Framework

The question is not which technology is better — it is which technology matches your business requirements, budget, and growth trajectory.

Choose a page builder if your budget is under ₹10,000, your timeline is under 1 week, you publish 50+ pages regularly, you need no custom functionality, "good enough" performance is acceptable, you are comfortable with platform dependency, and you plan to manage updates yourself.

Choose custom PHP if your budget is ₹15,000+, your timeline allows 2–6 weeks, you have under 30 pages with rare updates, you need custom functionality like CRM or booking systems or portals, you require Core Web Vitals compliance, you want full code ownership, and you prefer developer-managed maintenance.

For most Indian SMBs — service businesses, manufacturers, consultancies, clinics, educational institutions — the requirement is 8–15 pages, an admin panel for basic content updates, a contact form, Google Maps integration, and fast mobile performance. This use case is precisely where custom PHP delivers the best cost-to-value ratio.

Technical Implementation Notes

For developers considering the custom PHP route, the modern stack does not mean writing raw mysqli_query() calls:

php// Modern PHP routing with Slim Framework
$app->get('/services/{slug}', function ($request, $response, $args) {
$service = Service::findBySlug($args['slug']);
return $this->get('view')->render($response, 'service.php', [
'service' => $service,
'meta' => $service->getSeoMeta()
]);
});

For routing, use a micro-framework like Slim or Flight PHP with 50KB overhead versus Laravel's 30MB vendor directory. PHP itself works as a template engine with layout includes — no Blade or Twig dependency needed for simple sites. Use PDO with prepared statements for database access, providing parameterized queries by default. Minify CSS and JS at build time without webpack for sites with just 3 CSS files and 2 JS files. Implement file-based page caching for simple sites and Redis for higher-traffic applications. Deploy with git pull and composer install without complex CI/CD pipelines.

The goal is appropriate technology — not minimal technology and not maximal technology.

Conclusion

The Indian web development market is polarizing into two extremes: ₹999 template websites and ₹5,00,000+ enterprise applications. The middle ground — ₹15,000–₹50,000 custom-built business websites that are fast, secure, maintainable, and owned by the client — is underserved and represents the highest-value segment for both developers and business owners.

At Infinite Option Web Solutions, this middle ground is our core focus. Every website we build is custom PHP with a dedicated admin panel, optimized for Google Core Web Vitals, and delivered with full source code ownership. After 150+ projects across industries — from healthcare to real estate to e-commerce — the pattern is consistent: businesses that invest in purpose-built websites outperform their template-using competitors in search rankings, page speed, and lead conversion.

The technology choice is not about ideology. It is about matching the tool to the job — and for most Indian business websites, custom PHP is still the right tool.

Built by Infinite Option Web Solutions — Custom website design and development company in Kolkata

Local SEO for Indian SMBs in 2026: the GBP + Local Business schema setup I ship on every client site

Aniruddha Pramanick — Mon, 27 Apr 2026 04:49:11 +0000

I run a small web dev agency in Kolkata. Most of our clients are Indian SMBs — boutique stores, clinics, coaching centres, B2B traders. After 150+ websites, I've noticed one consistent pattern:

Founders care a lot about how the homepage looks. They care almost nothing about whether Google knows where they are.

Then a few weeks after launch I get the same WhatsApp message: "Bhai, search me toh aa hi nahi raha." (Brother, it's not even appearing in search.)

The site is fine. The problem is that nothing on it — and nothing about it — tells Google's local stack what this business actually is, where it operates, or that it's the same entity as the Google Business Profile sitting on Maps.

This post is the technical checklist I now run on every client site to close that gap.

The two-system problem

There are two systems Indian SMBs need to keep in sync:

Google Business Profile (GBP) — the Maps listing, address, hours, photos, reviews. This is what shows up in the local 3-pack and on Google Maps.
The website — where Google's organic crawler reads structured data, sitemap, internal links, and schema.

Local rankings improve when these two systems agree. Most of the suppression I see in client Search Console reports is because they don't.

Part 1: the GBP side (the 5-minute version)

I'll keep this short — the founder-facing setup details are out of scope for a dev post. But before you ship anything for a new SMB client, confirm these:

Profile is claimed and verified. Unverified profiles get almost no Maps visibility. In India, postcard verification still dominates; video verification is now common too. Allow 5–14 days.
Primary category is the most specific accurate option. Not "Business" — "Beauty Salon", "Ayurvedic Clinic", "Web Designer", whatever fits exactly.
NAP is locked. Name, Address, Phone. Decide the canonical version with the client and write it down. This is the string you'll hardcode everywhere.
Hours, photos, description are filled in. Empty sections suppress rankings.

Once that's done, the website work begins.

Part 2: LocalBusiness JSON-LD on every client site

This is the single highest-leverage piece of code I add to Indian SMB sites. Drop it in the <head> of your homepage:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Infinite Option",
  "image": "https://infiniteoption.com/logo.png",
  "@id": "https://infiniteoption.com/#localbusiness",
  "url": "https://infiniteoption.com",
  "telephone": "+91-90516-21062",
  "priceRange": "₹₹",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "G2/A, 94 Shibpur Road, Mandirtala",
    "addressLocality": "Howrah",
    "addressRegion": "WB",
    "postalCode": "711102",
    "addressCountry": "IN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 22.5747,
    "longitude": 88.3197
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
    "opens": "10:00",
    "closes": "19:00"
  }],
  "sameAs": [
    "https://www.facebook.com/infiniteoption",
    "https://www.instagram.com/infiniteoption",
    "https://g.page/infiniteoption"
  ]
}
</script>

A few specifics that matter for India:

"addressCountry": "IN" — set this explicitly. Some boilerplate templates default to "US" and nobody notices for months.
"telephone" in +91 format with hyphens. It must match the GBP exactly, character for character.
"sameAs" should include the actual g.page/... link from the GBP. This is the explicit machine-readable connection between the two systems Google's algorithm needs to see.

For multi-location businesses, use @type: "Organization" at the root with multiple subOrganization entries — one LocalBusiness per location, each with its own @id.

Always validate with the Schema Markup Validator (validator.schema.org) before pushing live. A broken schema is worse than no schema.

NAP consistency at the code level

The mistake I made on early projects was hardcoding the address in three places — the footer, the contact page, the schema — and letting them drift. Six months later the footer said "Mandirtala, Howrah" and the schema said just "Mandirtala". That's a NAP mismatch, and it quietly suppresses local rankings.

Fix: one source of truth in config, rendered everywhere.

For a PHP/MySQL stack (most of my client sites):

// config/business.php
return [
    'name'    => 'Infinite Option',
    'phone'   => '+91-90516-21062',
    'email'   => 'contact@infiniteoption.com',
    'address' => [
        'street'   => 'G2/A, 94 Shibpur Road, Mandirtala',
        'city'     => 'Howrah',
        'region'   => 'WB',
        'postcode' => '711102',
        'country'  => 'IN',
    ],
    'hours' => '10:00–19:00 Mon–Sat',
    'gbp'   => 'https://g.page/infiniteoption',
];

Then require this in the footer partial, the contact page template, and the JSON-LD generator. One edit updates every surface.

For WordPress, ACF Options Page does the same job. For Shopify, theme settings stored in config/settings_data.json. For Next.js, a single siteConfig.ts exported from /lib.

The principle is the same regardless of stack: the address string lives in exactly one place in the codebase.

The footer + contact page

Your footer should render the same NAP triple that's in the schema — visibly, in plain text, crawlable. Not baked into an image, not painted in by JavaScript after first paint. Static HTML.

Same for the contact page. Plus an embedded Google Map iframe pointing to the actual GBP pin. Grab the embed URL from inside the GBP dashboard itself, not by manually searching the address on Maps.

<iframe
  src="https://www.google.com/maps/embed?pb=..."
  width="100%" height="320"
  loading="lazy"
  referrerpolicy="no-referrer-when-downgrade"
  title="Our location on Google Maps">
</iframe>

This iframe is a small but real signal that the website and the GBP are the same entity.

Sitemap + Search Console

Last step every time:

Generate sitemap.xml — your CMS probably already does, but verify it includes the homepage, contact page, services, and any location pages.
Submit it via Google Search Console.
Verify domain ownership in GSC using a DNS TXT record. More reliable than the HTML file method for clients on Hostinger/GoDaddy where file uploads sometimes get clobbered by deployments.
In GSC → Settings → Associations, link the GSC property to the GBP.

That last point matters and is often skipped. Until GSC and GBP are explicitly associated, they behave like two separate islands of data — even if they describe the same business.

The shippable checklist

[ ] GBP claimed and verified
[ ] Canonical NAP locked in a config file (one source of truth)
[ ] LocalBusiness JSON-LD in homepage <head>, validated
[ ] Footer + contact page render the same NAP, crawlable plain text
[ ] Embedded map on contact page points to the actual GBP location
[ ] sitemap.xml submitted in GSC
[ ] GSC ↔ GBP associated

This is the code-side half. The other half — actually setting up and running the GBP, writing the description, collecting reviews, posting weekly updates — is non-dev work the founder has to own. Our content team wrote a fuller walkthrough of that side aimed at Indian business owners: How to Set Up and Optimize Your Google Business Profile in India in 2026. I send it to clients during onboarding so they have a single reference for the parts I can't ship for them.

If anyone has shipped a different schema pattern for Indian multi-location SMBs — especially the Organization + sub Organization setup with separate GBP profiles per branch — drop it in the comments. Always learning here.

Will AI Really Replace Web Developers in 2026? An Indian Agency Owner's Take

Aniruddha Pramanick — Sat, 18 Apr 2026 08:22:42 +0000

Originally published on [Infinite Option]
I run a web development agency in Howrah, India, and wanted to share this with the wider developer community here.

Overview

The question of whether AI will replace web developers has become one of the most urgent conversations in the tech industry in 2026. Every week a new headline declares that AI automation is eliminating jobs and making entire skill sets obsolete overnight. For developers, students considering AI careers, and business owners who rely on web development services — the anxiety is real.

But the honest answer is far more nuanced than any headline suggests. AI is transforming the future of web development — but transformation and replacement are two fundamentally different things. AI is changing what developers spend their time on, not whether developers are needed at all.

What AI Can Actually Do in Web Development Today

GitHub Copilot, developed by Microsoft and OpenAI, is the most widely used AI coding assistant in the world. It suggests code completions, generates entire functions from natural language descriptions, and has become standard in professional web development workflows.

ChatGPT for coding has made debugging, code explanation, and rapid prototyping dramatically more accessible. Paste an error message, get a diagnosis instantly. Generate snippets in multiple languages. Explore implementation approaches without hours of documentation reading.

AI web design tools like Framer AI, Wix ADI, and Adobe Firefly can generate layout suggestions, color schemes, and complete page templates from text prompts. For simple, templated outputs, the speed is remarkable.

The future of programming is clearly one where AI tools handle more of the mechanical, repetitive layers of code. That shift is already happening and it is accelerating.

What AI Cannot Replace — And Why Human Expertise Still Wins

Human creativity in web development is the most fundamental gap. A client with a complex business problem, a unique brand identity, and specific UX requirements needs a developer who can think strategically, ask the right questions, challenge assumptions, and design solutions that no prompt can fully specify. AI in 2026 consistently struggles with the why, not the how.

AI is excellent at pattern recognition within existing data — but building something genuinely new, solving an unprecedented problem, or designing a system architecture that balances ten competing business requirements is still deeply human work. AI also cannot manage client relationships, navigate ambiguous requirements, or take accountability for delivery — all core to professional web development services.

The future isn't AI building websites autonomously. It's developers who use AI tools effectively being dramatically more productive than those who don't.

AI Taking Over Jobs — Separating Fear From Fact

Jobs actually replaced by AI in tech so far have overwhelmingly been narrow, highly repetitive roles — data labelling, basic QA, template-based content generation.

In web development specifically, AI is replacing specific tasks — not the developer's role as a whole. Most vulnerable: writing boilerplate, generating placeholder content, producing basic CSS layouts, converting design files into standard templates. These were always the least valuable parts of the work.

What AI is not replacing: complex problem-solving, architectural decision-making, client communication, quality assurance, and creative judgment. Data from 2024 and 2025 consistently shows companies using AI automation are hiring more developers, not fewer — because AI expands what's possible and creates new categories of work faster than it eliminates existing ones.

The AI Engineer — A New Career, Not a Replacement

The most significant new path for anyone considering AI careers is the emergence of the AI engineer as a distinct professional role. An AI engineer isn't a traditional developer who uses AI tools — they build, train, deploy, and maintain AI systems, integrate machine learning pipelines, and create the infrastructure that AI tools run on.

AI engineer roles are among the fastest-growing and highest-paying in tech globally and in India specifically. For web developers worried about AI making their skills irrelevant, this path is actually one of the most compelling directions available. A developer with strong web development experience who upskills into AI engineer territory — APIs, model integration, prompt engineering, ML basics — becomes one of the most valuable professionals in the market.

Web Developer Skills 2026 — What You Need to Stay Relevant

Here's what matters most right now:

Prompt engineering — knowing how to instruct Copilot, ChatGPT, and other AI tools to produce production-ready output
AI tools integration — embedding AI web design tools, ML models, and intelligent APIs into projects
System architecture and problem solving — AI handles mechanical layers; humans handle structural ones
Client and business communication — relationship management becomes more valuable as AI handles execution
Continuous learning — skills in 2028 will look different from 2026; curiosity is the moat

What This Means for Businesses Using Web Development Services

AI web design tools and GitHub Copilot make building faster, but they don't replace the judgment, strategy, and quality accountability that professional web development provides. A business using a cheap AI-generated site instead of a proper build is trading short-term savings for long-term performance gaps in speed, SEO, security, and brand credibility.

Conclusion

Will AI replace web developers entirely? No — and the evidence in 2026 makes this clearer than ever. Jobs actually replaced by AI in web development are the narrowest, most repetitive task layers — not the creative, strategic, and relationship-driven work that defines the profession.

The AI engineer is one of the most exciting new career paths precisely because it builds on web development expertise rather than replacing it. The future belongs to developers who embrace AI as a tool, businesses that invest in quality builds with intelligence baked in, and professionals who see careers in AI as an evolution of the craft they already love.

I've written the full, longer version with more data and examples on our blog — [read it here].

What's your take — are AI tools making you faster, or are you worried about the long-term direction? Would love to hear from other devs in the comments.