Web Development

Fast, responsive websites built to perform.

What you are actually buying

Web development here means a public site people can finish on a phone, plus the boring parts that keep it true after we leave — hosting you can restore, a way to publish, and URLs that still make sense in a year. It does not mean a logged-in operations tool wearing a marketing theme. If staff will live in the thing all day, that job sits under .NET development, even when it opens in a browser. Mixing the two in one “website” quote is how the pretty pages ship and the desk still runs on WhatsApp.

We work from Chengannur with firms across Kerala and the rest of India that sell a real service from a real place. The visitor is often on a mid-range Android, on mobile data, deciding whether to call, message, or leave. Your site has about eight seconds to look like the business they already found on Maps or in a forwarded chat. That is the job. A slider, a stock photo of a handshake, and a form that asks for a company PIN code they do not have is not the job.

Website or web application — pick before you pick a theme

If anonymous visitors are the main users, you are in website territory. If signed-in people with different permissions are the main users, you are in application territory. A brochure with services, a blog, and a contact path is a website. A dealer dashboard, a job board, a client portal, a booking back-office — those are applications that happen to use a browser. The longer test is on website versus web application. Read it before anyone opens a theme demo.

You can need both. Most dealer networks and multi-branch firms do. They can share a brand, a header, and a design system. They still need two definitions of done, two hosting stories, and often two codebases that talk through an API. Pricing them as one “SEO website” is how you fund a rewrite six months later.

Ask this	Website	Web application
Who uses it every day?	Visitors who have not signed in	Staff, dealers, or customers with a login
What does “done” look like?	They called, messaged, or booked	They finished a job without a spreadsheet beside it
Must Google find it?	Yes, on the money pages	Usually no, behind the login
Failure mode	Nobody finds you	The unofficial Excel stays

When WordPress is enough

WordPress is enough when the work is publishing. Services, locations, a blog, a contact form, perhaps a simple store. Someone on your side will add a page without a developer. The plugins you need already exist and you will not invent a workflow the CMS was never meant to hold. A five-to-twelve-page business site in that shape is often three to six weeks including content cleanup, mobile layout, and a handover — not a weekend theme install that leaves the H1 inside a slider.

It is still enough when you outgrow the first theme, as long as the job is still publishing. A second location page, a second language later, a blog you will actually write — those are website problems. They do not become application problems because a vendor prefers a framework. The user’s job decides the bucket. The plugin list decides whether WordPress is still cheap inside that bucket.

WooCommerce is still mostly a website, with a checkout that must not fail. If checkout is the product — deposits, branch-wise stock, dealer prices — say that in the brief. A catalogue of thirty items with UPI and a phone number for the rest is a different estimate from a store that must match Tally item codes every night.

When WordPress stops being cheap

It stops being cheap when two staff must edit the same record without overwriting each other, when you need roles that are not “admin or not”, when last year’s orders must load without the page dying, or when the real process lives in a spreadsheet the theme cannot see. A members plugin and a hope is how those projects fail. At that point you are briefing software, and the honest move is to say so and price a first slice, not to stack another plugin.

It also stops being cheap when the install is already a museum of page builders, unused themes, and a chat widget that steals the first tap. Rescue is possible. Rescue is not “migrate to a new stack because we like it”. Rescue is: which URLs already get impressions, which forms actually convert, which plugins can leave, and whether the leftover job is still publishing. If it is not, do not put a new theme on an application problem.

Custom when the public site is still a website

Custom HTML on ASP.NET Core — the shape of this site — is still a website when the users are anonymous and the job is to explain, rank, and convert. We left WordPress here because the content model and the SEO work needed ownership of the HTML, not because a public page suddenly became an operations tool. The line is the user’s job, not the framework. If a vendor sells you a rewrite because they prefer React on the homepage, ask what the visitor will do that they cannot do now.

Custom is the honest answer when you need URLs you control, a content model that is not a pile of blocks, and a publish path that will not fight you every Monday. It is slower to add a page than a CMS. That is a real cost. Pay it only if the CMS is already the problem, or if the site and a small admin belong together and you refuse to run two hosts for five pages.

Phone-first, Kerala, and the WhatsApp enquiry

Most of your useful traffic will not arrive on a laptop in an air-conditioned office. It arrives on a phone, often after a Maps listing, a forwarded status, or a relative who said “just message them”. The first screen must show what you do, where you are, and how to reach a human — call, WhatsApp, or a form that is shorter than the chat they would have sent anyway. A floating chat bubble that covers the number is not a feature. It is a tax on the tap you already earned.

Hours must be true this Saturday. The map must not send people to last year’s rented floor. If you have more than one place, each place needs a page with its own address, phone, and a sentence a person in that town would recognise. Do not hide the Kochi number on a Thrissur page and hope. Do not use one “Contact” blob for four branches. People bounce when the page feels like it was written in another city.

WhatsApp is how a lot of Indian SMEs already close. The site’s job is to make that message easy and specific — a pre-filled line with the page they were on, not a blank chat and a hope they type the right product. If you also need staff to log those chats into a board, that is a later application slice. Do not force the first website to be a CRM.

Pages a first business site should actually have

A home that states the offer in one sentence a stranger could repeat. One page per service you would take money for this quarter — not a grid of twelve icons you cannot staff. A real about page with a place and a person, not a mission paragraph. Contact with a map, hours, and the number that rings. If you have proof you can show without inventing metrics — photos of the work, a licence, a location — put it where a sceptical visitor looks, not in a carousel they will never swipe.

Skip the fake counter that ticks up to “500 happy clients”. Skip the stock testimonial with no surname. Skip the blog you will not write. An empty blog is a dead URL that tells Google you start things. If you will write, write answers people already search — hours, process, what happens after they call — and keep the dates honest.

• Home: offer, place, next step above the fold on a phone.
• Service pages: who it is for, what you do, what you will not do, how to start.
• Location pages only if the address and the staff are real.
• Contact: tap-to-call, WhatsApp, a form with four fields or fewer.
• Privacy and a simple thank-you — not a second marketing page.

SEO and Core Web Vitals as part of the build

Search is not a retainer PDF you buy after launch. It is titles, headings, and URLs that match the words a buyer in Kerala actually types, plus pages that appear quickly on a phone. The money URLs — services, contact, the article that already has impressions — should be in the “good” field bucket on mobile, or you should know why not. The metric language is in Core Web Vitals explained. Use that page. Do not start a vitals project to avoid writing the service pages.

Field data in Search Console beats a Lighthouse 100 on office fibre. Fix the poor URL that already gets impressions. Size images. Set width and height so the heading does not jump. Keep chat widgets and tag managers off the first paint. Host close to users. Then wait. Shipping a fix on Monday and “optimising” again on Wednesday because the chart has not moved is how retainers eat a quarter.

SEO also means not painting yourself into a corner. One H1. A title that can change without a developer if you are on a CMS. Canonicals that match what you submit. Do not put the same service copy on four URLs and hope. Do not launch on a temporary domain and “move SEO later” unless you already understand what you will break.

What a first slice looks like

A first website slice is not a redesign of every page you have ever imagined. It is the smallest set of URLs that can take an enquiry without you in the room. For most SMEs that is home, two or three services, contact, and a thank-you — built so a person on a phone can call or message in under a minute. Content you already have, cleaned. Photos you actually own. A form that lands in an inbox someone reads.

If you also need a logged-in tool, that is a second slice with its own sentence: “dispatch notes are created here instead of WhatsApp.” That sentence is an MVP, not a brochure. Do not hide it inside the website estimate. Write both on the same brief so nobody “simplifies” them into one number.

Discovery for a site is short when the job is publishing: a day to see the current URLs, the Search Console property if you have one, the number that should ring, and who will publish after handover. Discovery for an application is longer and should be paid. If a vendor skips both and sends a theme, you have a theme, not a plan.

Time bands you can plan around

A focused business site — existing copy, a handful of pages, no store — is usually three to six weeks including review rounds and handover. A WordPress rescue with plugin cleanup and Core Web Vitals on the money URLs is often four to eight weeks, depending on how much of the old install is load-bearing. A custom public site with a real content model and a small admin is longer, commonly six to twelve weeks. A store that must match item codes or branch stock is not a “plus two weeks on the brochure”; it is its own phase.

Ranges move when content is late, when nobody can decide the phone number that should appear, or when a second brand appears in week three. They also move when you add “just a client login” after the first invoice. That login is software. Price it that way. The shape of a serious software quote — written scope, assumptions, what happens when the list grows — is on how much custom software costs. We will not invent a rupee total here that will be wrong for your connector.

Handover — source, hosting, and Monday publish

Handover is part of the product. You get the source or the CMS access, the hosting account in your name or a clear transfer path, DNS notes, and a one-page “how we publish”. Backups you can restore, not a promise that the host “probably has them”. If we used a repo, you get the repo. If we used WordPress, you get admin that is not shared with a freelancer who left last year.

A week of support after go-live is normal. A year of unpaid redesigns is not. If you want a retainer, say what it is for: content help, a monthly plugin pass, or a named hour for small changes. “Keep it looking fresh” is not a scope. “One service page and image compression when you send copy” is a scope.

Who publishes after we leave must have a name. If that person cannot spare an hour a month, do not buy a CMS you will never open. A custom site with a request to us for new pages may be cheaper than a WordPress you are afraid to touch. Honesty about that hour is worth more than a page-builder demo.

Hosting that matches the job

A marketing site can live on simple hosting with backups and a CDN. An application needs a database you can restore, identity that is not a shared password, and a person who knows how to roll back a release. Calling both “the website” is how the application ends up on cheap shared hosting that cannot take a backup. We will say which you are buying. If you only need publishing, stay in this service. If you need both, we still estimate two jobs even when they share a hostname.

Do not put the only copy of the site on one person’s laptop. Do not use the same password for admin, FTP, and the inbox that receives enquiries. Those sentences sound fussy until the person leaves. Write them into the handover while everyone is still in the room.

What we will not do

We will not promise page-one rankings as part of a build. We will not stuff keywords into a paragraph until it stops being English. We will not ship a slider that hides the only sentence a visitor needed. We will not call a staff portal a website to win a cheaper comparison. We will not invent case-study percentages or client names. We will not keep a chat widget that ruins INP because a template included it.

We will also not start from a blank moodboard when you already have a site that ranks for something. Show us Search Console, the URLs that convert, and the complaint you hear on the phone — “the number was wrong”, “it took forever”, “I could not find Kochi”. That is the brief. A redesign that ignores those three lines is decoration.

How to brief us without a strategy slide

Write who the daily visitor is, the one job they must finish, the number or WhatsApp that should receive them, and whether anyone must sign in. List the pages you will actually staff. Attach the current site and, if you have it, a screenshot of Search Console on mobile. Name the person who will publish after handover. If you also want a portal, put it on a second paragraph with its own sentence of done. That is enough to say “website”, “application”, or “two builds”.

If you want the public pages to feel like a product, not a theme, bring us into UI and UX before anyone picks a slider. If you are ready to start from a real brief, contact us with those sentences. We would rather lose a week at the briefing than spend your quarter encoding the wrong job.