Short answer, if that is all you need: I build marketing sites, web applications and internal tools using Next.js, React, Node.js and TypeScript. The two things I optimise for that most builds neglect are mobile performance under real Nepali network conditions and crawlable server-rendered HTML. You own the repository, the domain and the hosting from day one.

The problem with most business sites here

I audit a lot of existing sites before rebuilding them, and the failure patterns repeat. A site is built as a client-side rendered application, so the HTML a crawler receives contains almost nothing and the page is effectively invisible to anything that does not execute JavaScript. Or it is a heavily themed content management system carrying a dozen plugins, four of which load their own copy of a JavaScript library, and it takes eight seconds to become usable on a phone.

This is not hypothetical. When I surveyed competitor sites in this market, one prominent Nepali developer portfolio served nine words of server-rendered HTML; everything else was assembled in the browser. The site looks fine to a human and is close to invisible to a crawler that does not run scripts, which now includes several of the AI crawlers feeding answer engines.

The second pattern is worse in business terms: the agency owns the code, the hosting and sometimes the domain. Leaving means starting over. That is a commercial arrangement dressed up as a technical one.

What I build

Marketing websites

Statically generated or server-rendered pages, real HTML in the response, structured data built in, sitemaps generated at build time, and a content structure that maps to how buyers search. Typically deployed to a global edge network so the first byte arrives quickly regardless of where the visitor is.

Web applications

Dashboards, portals, booking systems, admin tools and SaaS products on the MERN stack or Next.js with a Postgres or MongoDB backend. Authentication, role-based access, background jobs, payments and an audit trail where the domain requires one. The architecture patterns I use in production are documented in my Next.js production architecture write-up.

Internal tools

The unglamorous but high-return category: the thing your operations team currently does in a shared spreadsheet, turned into something with validation, permissions and history. Often pairs naturally with workflow automation.

Rebuilds and rescues

Taking an existing site that is slow, unmaintainable or invisible to search and either fixing it in place or rebuilding it without losing the search equity it already has. Preserving URLs and redirect chains correctly during a migration is the part that goes wrong most often, and it is the part I am most careful about.

How I build

  • Server-rendered or static by default. JavaScript enhances the page; it should not be required to see the content.
  • Performance budgeted, not hoped for. Measured under throttled mobile conditions, because that is the visitor you actually have.
  • Self-hosted fonts and pinned dependencies. Fewer third-party origins means fewer connections, fewer failure modes and better privacy.
  • Accessibility taken seriously. Keyboard navigation, focus management, real heading order and sufficient contrast. It overlaps almost entirely with good SEO anyway.
  • Automated checks in the pipeline. Builds fail on broken links, missing assets, malformed structured data or a regression in the published URL set. My own CI/CD approach is written up here.
  • Documented handover. Repository access, environment variables, deployment process and a written runbook.

Ownership, stated plainly

The repository is yours from the first commit. The domain is registered in your name. Hosting is under your account and billed to you directly, which is almost always cheaper than being resold it. When the project ends you have everything you need to continue with anyone else. I think this should be unremarkable, and in this market it is not.

How engagements work

A short discovery conversation about what the site needs to accomplish commercially, not what pages it should have. Then a written scope with fixed deliverables and a clear definition of done, so neither of us is guessing. Build happens in visible increments on a staging URL you can check at any point.

I take a small number of projects at a time and I do the work myself. There is no junior handoff after the sales call.

On budget, I would rather point you to sourced market data than post an invented number. Published Nepali price ranges and what each tier realistically buys are collected in this cost breakdown. Tell me your budget and I will tell you honestly what is achievable within it, including when the answer is that it is not enough.

Common questions

WordPress or custom?

If non-technical staff must publish content frequently, a properly configured CMS usually wins. If it is mostly fixed marketing pages or a real application, custom is faster, cheaper to host and easier to secure. I will talk you out of a custom build when it is not justified.

How long does a project take?

A focused marketing site is typically a few weeks; an application depends entirely on scope. The scope document sets dates, and if something is going to slip you hear it early rather than on the deadline.

Can you work with our existing developer or agency?

Yes, and often that is the cheaper option. Sometimes the right recommendation is a targeted fix rather than a rebuild.

Will it be optimised for search?

Structurally, yes. Deeper ongoing search work is a separate engagement, covered under SEO consulting.

See SEO consulting for search visibility, GEO and AEO for citation inside AI answers, and AI automation for the systems behind the site. Full list of services.

Tell me what the site needs to do

Not what pages you want, but what the site needs to achieve commercially. I will reply with an honest view of the right approach, including when a rebuild is not the answer.

Get in touch Read the blog