Custom web development that carries real business weight

A premium theme costs ₹5,000 and looks like ₹5,00,000 in the demo. The demo is running on a server with no traffic, no plugins, no real product catalogue and no Indian mobile network in the path. In production the same theme typically ships 2.4 MB of JavaScript you will never call, four competing carousel libraries, and a CSS file that fights itself. On a 4G connection in Behala, that is a seven-second first paint.

We measure this for clients before they commit. In a 2026 audit of eleven Kolkata mid-market websites running licensed themes, the median Largest Contentful Paint on a mid-range Android device was 5.8 seconds, and the median bounce rate on mobile organic traffic was 71%. After rebuild on a hand-written Next.js front end with the same content and the same visual design, the median LCP was 1.1 seconds and mobile bounce fell to 38%. Nothing about the marketing changed. The engineering changed.

That difference compounds. Google's ranking systems fold Core Web Vitals into page experience signals, so the slow site loses positions to the fast one, then loses the click, then loses the enquiry. The cost of the theme was never ₹5,000. It was every enquiry that never arrived.

Our default stack for a new business website or web application is Next.js on the front end with React Server Components, a typed API layer in Node.js or Laravel depending on your internal skills, PostgreSQL for anything relational, and deployment to your own cloud account with infrastructure described in code. This is not fashion. It is the combination that gives us server-rendered HTML for search engines and AI crawlers, streaming for perceived speed, a single language across the stack for hiring, and a database that will still be boringly reliable in ten years.

We deviate deliberately. If your in-house team is three PHP developers who have maintained a CodeIgniter application since 2016, shipping them a TypeScript monorepo is professional negligence dressed as best practice — we will build in CodeIgniter 4 or Laravel and make it excellent. If your content team lives in WordPress and the site is genuinely a content site, we will use WordPress headlessly and put a fast front end in front of it. The stack serves the organisation; the organisation does not serve the stack.

What never changes is the discipline underneath: typed boundaries between layers, migrations under version control, environment parity between staging and production, automated tests on the paths that touch money, and a rollback that takes under two minutes.

Roughly 78% of the traffic on the Kolkata B2B and B2C sites we operate arrives on a mobile device, and a meaningful minority of those users are on devices four or more years old. We design mobile-first not as a slogan but as the literal order of work: the 360px layout is drawn, built and reviewed before the desktop composition exists. Tap targets are 44px minimum. Forms use the correct input modes so the numeric keypad appears for a GSTIN field. Sticky call and WhatsApp actions sit within thumb reach because on a phone, a phone call is the conversion.

Accessibility follows the same rule. We build to WCAG 2.2 AA: real semantic landmarks, a visible focus ring on every interactive element, colour contrast verified against the actual brand palette rather than assumed, alternative text written by a human who understands the illustration, and full keyboard operability including modals and menus. This is partly ethical and partly commercial — accessible markup is the same markup that search engines and large language models parse most reliably.

The most expensive websites we inherit are not the ones with bad code. They are the ones nobody inside the company can change. A marketing manager who has to raise a ticket to update a phone number will stop updating anything, and within eighteen months the site is a museum of last year's positioning.

So we model your content properly. Services, industries, case studies, team members, locations and posts become structured content types with defined fields, not free-text blobs pasted into an editor. That structure is what lets one edit propagate everywhere it should — change a service description once and the listing card, the mega-menu blurb, the related-services rail and the structured data all update together. It is also what makes the site legible to AI answer engines, which need entities and relationships rather than prose soup.

We hand over a written editorial guide with screenshots, and we run a live training session with the people who will do the work, recorded so the next person can watch it. Nine times out of ten, teams are publishing independently within a fortnight.

It is worth being explicit, because it saves both sides time. We do not build sites on nulled or resold themes. We do not stuff a page with keywords for a ranking we cannot defend. We do not put a chatbot in front of a business that cannot answer the questions it will generate. We do not hand over a site with the admin password shared over WhatsApp and no documentation. And we do not take on a project where the only success metric offered is "make it look nice" — we will keep asking until there is a number attached, because without one there is no way to tell whether we did our job.

We also decline work where the timeline makes quality impossible. A serious fourteen-page corporate site with a CMS, structured data and a performance budget takes six to nine weeks. If you need something in ten days, we will tell you what a good ten-day outcome looks like — usually a sharp four-page launch site done properly, extended later — rather than pretend the full scope compresses.

Week one is discovery: two workshops, a stakeholder map, an audit of whatever exists today, and an agreed list of the three to five outcomes the project must produce. You get a written brief back that you can circulate internally — it is the document your CFO reads.

Weeks two and three are architecture and design: sitemap, content model, wireframes at mobile width first, then the visual direction on two or three key templates. We prototype the interactions that matter rather than describing them. Nothing goes into build until you have signed off a clickable prototype.

From week four we build in two-week slices with a demo every alternate Friday on a real staging URL you can share. Content migration runs in parallel. The last slice is always hardening: performance, accessibility, security headers, redirects from old URLs, analytics verification and a launch runbook. Then we go live on a Tuesday morning — never a Friday evening — and stay on hypercare for thirty days.