Loading
Next.js · React · Headless CMS
A marketing site and a web application are two different builds with two different failure modes. We do both, and we decide which one you are actually asking for before quoting either.
The problem
A marketing site is read by strangers on unreliable connections who will leave if the first screen is slow. It is judged on how quickly text appears, how well it is understood by a crawler, and whether it can be edited by a marketer without a developer. Almost none of its complexity is behind a login.
A web application is used repeatedly by the same people who are signed in, who care about how fast the third click is rather than the first, and who will forgive a two-second initial load in exchange for a list view that filters instantly. Its complexity is authorisation, state and data, and search engines are irrelevant to most of it.
Confusing the two is the most common and most expensive mistake in this category. A dashboard framework used to build a brochure site produces a page that renders nothing until a large JavaScript bundle has downloaded and executed, which is precisely the page a search engine and a rural 4G connection both handle worst. The reverse error, a static-site generator asked to hold an authenticated multi-role application, produces a build pipeline that takes twenty minutes and a workaround for every interactive feature.
So the first question is not which framework. It is which of these two things you are building, and for the many projects that are genuinely both, where the boundary between them sits and how the two halves share a design system without sharing a deployment.
What is included
7 areas of work. Most engagements start with one or two and widen once the first release is in use.
Server components by default, client JavaScript only where an interaction genuinely needs it, and typed data access. Static generation where content allows, incremental revalidation where it changes, and server rendering where the page is personalised. The rendering strategy is chosen per route.
Sanity, Payload, Strapi or Contentful modelled around what your editors actually publish. Preview builds, structured content types, reusable blocks and validation rules, so marketing can ship a landing page on a Tuesday without a developer or a deploy.
Largest Contentful Paint on the heading rather than a hero image, no layout shift from late-loading fonts or ads, and interaction latency kept low by not shipping the JavaScript in the first place. Measured on a mid-range Android over a throttled connection, which is the device that matters in India.
WCAG 2.2 AA as the working target: landmark structure, one h1, logical heading order, 44px touch targets, visible focus rings, forms with real labels and error messages that name the field. Tested with a keyboard and a screen reader, not only with an automated scanner.
Per-page titles and descriptions from a typed factory rather than a pattern string, canonical URLs, a generated sitemap, structured data from the same data the page renders, and clean internal linking. The architecture is a prerequisite for ranking, not a substitute for content.
Storefronts on top of Shopify, Medusa or a custom commerce API, with the catalogue rendered statically and cart and checkout kept dynamic. Product pages that stay fast with two thousand SKUs and a facet filter that does not reload the world on every click.
Deployment on Vercel, Netlify or your own cloud, preview URLs on every pull request, and analytics configured with events that answer a business question. Handover includes editor training and written notes, so the site does not silently become our property.
How we work
We agree the content model before the visual design, because a design signed off against fake headings falls apart the first time a real product name runs to three lines. Editors get named content types with defined fields, so the site cannot be broken by pasting a heading into the wrong slot.
Performance budgets are set at the start and checked in CI, not measured after launch when fixing them means undoing decisions. A page that exceeds its JavaScript budget fails the build. Images are processed at build time into modern formats with explicit dimensions, and fonts are subset and self-hosted so there is no third-party request on the critical path.
Accessibility is a build-time constraint too. Semantic markup, real headings, visible focus, keyboard paths through every interactive component, and colour contrast checked against the actual tokens. Doing it while the components are being written costs very little. Retrofitting it after launch costs a rebuild of the component library.
In practice
We agree the content model before the visual design, because a design signed off against fake headings falls apart the first time a real product name runs to three lines. Editors get named content types with defined fields, so the site cannot be broken by pasting a heading into the wrong slot.
Where it comes up
Stack
We pick from a stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
WordPress is a reasonable answer for a content-heavy site with a small team and no unusual requirements, and we will say so rather than talking you into a larger project. It becomes the wrong answer when the site needs authenticated areas, custom data relationships, or performance that survives a plugin stack. The deciding question is usually how many plugins the current site depends on and how many of them are load-bearing.
It can, and the damage is almost always caused by the same three things: broken URL mapping, lost page content, and a slower site. We map every existing URL to its new destination before launch, keep the content that earns traffic rather than rewriting it for freshness, and hold the new build to a performance budget. Some short-term movement while search engines re-crawl is normal; a permanent drop is a migration that was done carelessly.
The practical target is Largest Contentful Paint under 2.5 seconds and Interaction to Next Paint under 200 milliseconds on a mid-range Android over a 4G connection, measured on field data rather than a lab score. A Lighthouse number from a desktop with a fast connection is a useful development signal and a poor measure of what your visitors experience.
Yes. If there is a Figma file we will build to it, and we will raise the places where it will not survive real content, unusual viewport widths or a keyboard user before we start rather than after. If the design does not exist yet, our UI/UX team can produce it, or we can work from a design system you already own.
If you want us to. A maintenance arrangement typically covers dependency and security updates, uptime monitoring, a monthly performance check and a block of hours for content and feature changes. The alternative is a clean handover with documentation and training, which is a legitimate choice and one we support properly rather than reluctantly.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether web development is even the right place to spend the budget.
What happens next
