DEV Community: Yukesh Rajbanshi

Why We Built Niguro: Engineering Nepal's First Search Engine & Internet Portal 🌿

Yukesh Rajbanshi — Tue, 18 Aug 2026 05:30:46 +0000

Hey DEV Community! 👋

I’m the founder of Niguro (niguro.com), and today marks one of the biggest milestones of my tech journey: we officially launched Nepal’s first native search engine and digital portal.

Building a search engine in an era dominated by trillion-dollar global tech giants sounds crazy. But when you look closely at localized web ecosystems—especially in emerging tech hubs like Nepal—the gap in quality, relevance, and speed for local queries becomes glaringly obvious.

Here is the story of why we built Niguro, the technical challenges of engineering a localized web engine, and how we structured our architecture to deliver sub-second response times.

🎯 The Problem: Why Big Tech Fails Local Context
Global search engines are built for macro-scale indexing. However, for a user in Kathmandu searching for local emergency services, real-time commodity prices (like gold or fuel), or niche regional business listings, global crawlers face three core problems:

Relevance Dilution: Local sites and independent media get buried under high-DA (Domain Authority) global scraper sites.

Payload Bloat: Heavily bloated frontends consume precious bandwidth on mobile networks.

Lack of Integrated Utility: Users are forced to hop across 5 different bookmarked tabs just to check local weather, daily news feeds, community discussions, and commercial directories.

We set out to build Niguro (named after the wild fern native to Nepal’s hills) to act as a fast, clean, and unified gateway to the local web.

🏗️ Technical Architecture & System Overview
Niguro isn't just a basic index page—it's an ecosystem built on three major pillars: Search, Community, and Real-Time Utilities.

Hybrid Search Engine & Query Processing Our core engine uses a distributed crawling and indexing pipeline tuned specifically for domestic domain namespaces (.com.np, regional servers, and local news hubs).

Parser & Boilerplate Removal: We use high-throughput parsing in Rust and Node services to strip out ad script noise and extract rich metadata (canonical URLs, OpenGraph tags, semantic headers).

Targeted Inverted Indexing: Queries hitting /search/result?q={search_term} query our indexed store with custom scoring algorithms that weight local domain freshness over generic domain authority.

AI Assistance: We integrated Bhotu AI directly into the search bar UI to give users instant natural-language summaries alongside traditional web links.

Micro-Frontend & UI Performance We designed the Niguro frontend to feel instantaneous:

Minimalist Shell: A lightweight client footprint that renders the core search bar, quick navigation compass, and dark/light theme options in milliseconds.

Low-Latency Edge Widgets: Widgets for real-time weather (e.g., live regional temperature), gold/silver rates, and fuel prices are cached aggressively at the edge layer to prevent backend load spikes during traffic rushes.

Community & Real-Time Aggregation To move beyond static search, we built Niguro Communities—a space where verified users can post, curate, and discuss news, tech, and local topics directly within the engine.

How I Made Sajha (and why I think Nepal needed it)

Yukesh Rajbanshi — Thu, 09 Jul 2026 01:22:19 +0000

The itch that started it

I kept ending up in the same spot: something would happen — a hot take, a weird news story, a trending debate — and I'd have nowhere that felt right to talk about it. Group chats die fast. Twitter/X feels like shouting into a stadium. Facebook feels like your relatives are watching. Reddit is great, but it's not built for us specifically — the way we talk, the things we care about, the language we switch in and out of.

So I did what a lot of us do when something doesn't exist yet: I got annoyed enough to build it myself.

That's Sajha. Sajha means "shared" or "common" — and that's really the whole pitch. One shared front page. Everyone's takes. No filters, no performing.

What I was trying to build

Not another feed. Feeds are for scrolling past things. I wanted threads — actual conversations, with actual disagreement, that don't die after four replies.

The core mechanic I kept coming back to was voting, but I didn't want a boring upvote/downvote. I wanted something that matched how we already talk. So: Flame it if a take is fire, Cool it if it needs to sit down. Same mechanic Reddit popularized, different language — ours.

The build

Stack-wise, I kept it deliberately boring where it didn't matter and careful where it did:

WordPress as the core CMS/backend — not the trendiest choice for a "forum" product, but it's fast to iterate on, has a mature plugin ecosystem for auth/comments/moderation tooling, and meant I wasn't reinventing account systems and page management from scratch.
A custom theme built around communities, threads, and the flame/cool voting system — this is where most of the actual product work went. Vote counts, community subscriptions, trending logic, all custom.
Kept the frontend fast and minimal — no bloated JS, no dark patterns, no infinite auto-refresh feed designed to trap you.

The hardest part wasn't the code. It was deciding what not to build in v1. I cut a notification system, a full DM/messaging feature, and karma/reputation scoring — all things that seemed core but weren't actually needed to test the real question: will people show up and talk?

What I learned building alone

Ship the mechanic, not the polish. Flame/Cool needed to work and feel good before anything else mattered. Everything else was secondary.
Naming things matters more than I expected. Calling it "Flame it / Cool it" instead of "upvote/downvote" changed how the whole product felt — it stopped feeling like a Reddit clone and started feeling like its own thing.
Writing your own Terms of Service, Privacy Policy, and Community Guidelines is genuinely a lot of work that nobody warns you about before you launch a community platform. Legal/trust groundwork ate more time than I expected.

Where it's at now

Sajha is live at sajha.xyz. It's early — communities are just forming, threads are just starting — which honestly is the fun part. Every platform that ended up mattering had a moment where it was just a handful of people posting into the void, hoping someone would answer.

Why I'm posting this here

I'm not trying to make this a big launch post. I just wanted to talk through the actual build with people who'd get it — the tradeoffs, the stack choices, the "why did I cut that feature" decisions.

If you're into community platforms, forum mechanics, or just want to see what a solo-built Reddit-style platform looks like from the inside — I'd genuinely love feedback. And if you've got a hot take that's been sitting in your drafts with nowhere to go — that's exactly what Sajha's for. Come say it.

sajha.xyz — say it, don't stay quiet.

Will AI IDEs Like Cursor and Trae Replace WordPress Developers? After Building Entire Themes and Plugins, I Think the Answer Is Complicated

Yukesh Rajbanshi — Fri, 19 Jun 2026 16:42:06 +0000

A year ago, if someone told me I could build a fully custom WordPress theme and custom plugins in days instead of weeks, I would have been skeptical.

Today, after building complete WordPress projects using AI IDEs such as Cursor (and experimenting with tools like Trae AI), I can confidently say:

Building custom WordPress themes has become dramatically easier.

Not because WordPress itself became easier.

Because AI has changed the development workflow.

The Traditional WordPress Development Process

A typical custom theme project often required:

Planning templates
Creating page layouts
Building custom post types
Writing archive templates
Creating custom search pages
Implementing AJAX functionality
Debugging PHP issues
Reading WordPress documentation constantly

Even experienced developers could spend days implementing relatively simple features.

Enter AI IDEs

When using Cursor or Trae AI, the workflow changes completely.

Instead of searching for:

"How do I create a custom taxonomy archive template?"

You simply ask:

"Create a WordPress custom taxonomy archive for movies with pagination, SEO-friendly URLs, and schema markup."

Within seconds, you get a working starting point.

The same applies to:

Custom post types
Theme options
Widgets
AJAX handlers
Search functionality
REST API integrations
Admin panels
Plugin development

The amount of boilerplate code AI can generate is honestly impressive.

My Experience Building a Large WordPress Project

Recently I built a fairly large WordPress project almost entirely with the help of Cursor.

The project includes:

Custom theme architecture
Multiple content types
Search functionality
Dynamic pages
Portal-style features
Various integrations
Custom plugins and extensions

Many features that would traditionally take hours were created in minutes.

Not because AI magically solved everything.

But because it handled repetitive coding tasks while I focused on architecture and testing.

Custom Plugins Are Surprisingly Easy Now

One thing that shocked me was plugin development.

A few years ago, building a plugin required:

Understanding hooks
Actions
Filters
Settings APIs
Admin interfaces
Security practices

Now AI can generate a complete plugin structure almost instantly.

For example:

Create a WordPress plugin that tracks post views, stores data efficiently, adds an admin dashboard, and exposes a REST API endpoint.

You instantly get:

Plugin headers
Activation hooks
Database creation
Admin menus
API routes
Security checks

Of course, you still need to review everything carefully.

But the starting point appears almost immediately.

Does This Mean WordPress Developers Are Finished?

I don't think so.

But I do think the role is changing.

The value is no longer:

"I know how to write a WordPress loop."

AI already knows that.

The value is becoming:

Architecture decisions
Security reviews
Performance optimization
Scalability planning
UX decisions
Debugging complex issues
Understanding business requirements

The developer who knows how to use AI effectively may become significantly more productive than the developer who refuses to use it.

The Real Risk: False Confidence

AI can generate code very quickly.

The problem is that generated code often:

Works initially
Looks professional
Passes basic testing

But may contain:

Security vulnerabilities
Inefficient database queries
Poor architecture
Duplicate functionality
Technical debt

This is where experience still matters.

You need to understand why the code works, not just whether it works.

What AI Has Changed For Me

Before AI:

More time writing code
More time searching documentation
More time debugging boilerplate

After AI:

More time planning
More time reviewing
More time testing
Less time typing

The bottleneck is no longer writing code.

The bottleneck is making good decisions.

Could Someone Build an Entire WordPress Business Using AI?

Honestly?

Probably yes.

A motivated person with:

Basic PHP knowledge
WordPress fundamentals
Good prompting skills
Patience for testing

can build surprisingly advanced themes and plugins today.

Projects that once required a team can sometimes be prototyped by a single developer using AI assistance.

My Take

I don't think Cursor, Trae AI, Copilot, or future AI IDEs will eliminate WordPress developers.

I do think they will eliminate a lot of repetitive WordPress development work.

The developers who learn how to collaborate with AI will likely outperform those who treat AI as a threat rather than a tool.

The biggest question isn't:

Will AI replace WordPress developers?

The bigger question is:

Will WordPress developers who use AI replace WordPress developers who don't?

Do you think AI will reduce demand for WordPress developers?