DEV Community: Sanjay Kumar Sah

You Should Own Your UI Components, Not Just Install Them

Sanjay Kumar Sah — Wed, 29 Jul 2026 05:00:03 +0000

One of my favorite ideas behind shadcn/ui has nothing to do with components. It's about ownership. Unlike most UI libraries, shadcn/ui doesn't ask you to install a package and hope the maintainers keep it stable forever. Instead, it generates the source code directly into your project.

Those components become yours. You can edit them. Refactor them. Delete them. There is no vendor lock-in.

When I started building create-notils, I realized this philosophy shouldn't stop at components. It should extend to the entire project.

Installing Dependencies vs. Owning Your Code

Most starter kits work like this:

npm install some-ui-library

Your application now depends on another package. Every update means waiting for a new release, and every customization risks diverging from upstream. Sometimes you end up wrapping library components just to make them fit your project. Slowly, your application becomes a thin layer around someone else's code.

There's nothing inherently wrong with this approach, but I wanted something different.

Source Code Is the API

In create-notils, the generated project belongs to you. The UI components are copied into your repository. The configuration files are yours. The project structure is yours. Nothing is hidden behind an SDK.

That means changing a button isn't a breaking change—it's just another Git commit.

One Design System, Multiple Applications

One challenge with monorepos is avoiding duplicated UI code. Instead of installing shadcn/ui inside every individual application, create-notils keeps a single, shared design system at the workspace root:

packages/
└── ui/
    ├── components/
    ├── lib/
    └── styles/

Every application imports components from the exact same package:

import { Button } from "@notils/ui/components/ui/button";

When a new component is added, every application immediately has access to it. There is one source of truth, not three slightly different copies floating around your workspace.

Updating Isn't a Package Upgrade

One thing I always found awkward about UI libraries is updating them. Usually, it looks like this:

npm update some-library

Then you read the changelog, hope nothing broke, and fix any breaking changes.

With shadcn/ui, updating is different because you're updating raw source files. In create-notils, the workflow is intentionally simple. Want to add a component?

bun ui:add dialog

Need to see what changed upstream before you pull it in?

bun ui:diff button

Ready to update?

bun ui:update button

Every change is visible as a normal Git diff. No hidden abstractions. No magic.

The Same Philosophy Beyond Components

This release made me realize something: the idea of ownership applies to much more than just UI.

Authentication should live in your repository. Configuration should live in your repository. Database schemas should live in your repository. Generated code should be fully understandable without having to read a framework's internal source code.

That's the direction I want create-notils to move toward. I don't want to build a platform that owns your application. I want to build a platform that helps you own it.

Version 0.2.0 is Live

This release introduces the foundation for that philosophy. Highlights include:

Interactive project creation: Scaffold exactly what you need.
Monorepo and standalone generation: Two outputs from one canonical source.
Shared @notils/ui package: A unified design system for your workspace.
Built-in UI commands: Add, preview, and update shadcn/ui components effortlessly.
Dedicated developer guide: Generated specifically for your new project.
Better documentation & testing: For all generated applications.

The project is still early. Authentication, database integration, and additional capabilities are coming in future releases. But the core philosophy is already taking shape: Own your code. Reduce repetitive setup. Spend your time building products instead of rebuilding infrastructure.

Opinionated by Design: Why I Chose Sensible Defaults Over Endless Configuration

Sanjay Kumar Sah — Wed, 22 Jul 2026 06:33:14 +0000

When people hear about a new project scaffolding tool, one of the first questions they ask is:

"Can I choose React Query or TanStack Query?"
"What about pnpm instead of Bun?"
"Can I use ESLint instead of Biome?"
"Can I choose Radix instead of Base UI?"
"Can I skip Tailwind?"

These are reasonable questions. In fact, I asked myself the same ones while building create-notils. My first instinct was to make everything configurable.

The more I thought about it, the more I realized I was about to build something I didn't actually want to use.

The Configuration Trap

Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library.

Eventually the CLI starts looking like this:

? Which package manager?
❯ npm
  pnpm
  yarn
  bun

? Which CSS framework?
? Which ORM?
? Which auth library?
? Which formatter?
? Which icon library?
? Which deployment target?

It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features.

I Built the Tool I Wanted to Use

One thing I've learned from building side projects is this: the first user should always be yourself.

Every project I start today uses almost exactly the same stack:

Next.js 16
React 19
Bun
Tailwind CSS v4
shadcn/ui
Base UI
Biome
TypeScript
Turborepo (when needed)

I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have.

npx create-notils my-app

A few seconds later, I'm writing features instead of answering prompts.

Opinionated Doesn't Mean Closed

There's an important distinction between opinionated and restrictive.

Some tools hide their implementation behind abstractions. Others generate code you aren't expected to touch. That isn't the direction I wanted.

Everything create-notils generates belongs to you. The UI components are source files. The configuration files are yours. The project structure is yours. If you don't like one of my decisions, you can change it immediately.

There is no vendor lock-in. The CLI gives you a starting point, not a framework you have to live inside forever.

Defaults Should Be Battle-Tested

Every opinion in create-notils comes from building real projects.

I didn't choose Bun because it was trendy; I chose it because it's the package manager and runtime I use every day. I didn't choose Biome because it's newer than ESLint; I chose it because having one fast tool for linting and formatting simplified my workflow.

The same applies to Tailwind CSS v4, shadcn/ui, Base UI, and the rest of the stack. The goal isn't to pick the newest tools. The goal is to reduce decisions that I already know the answer to.

Configuration Can Come Later

One question I get is: "What if someone doesn't want your stack?"

That's a fair point. The answer is: not every problem needs to be solved in version 0.1.

As create-notils evolves, it will become more modular. Instead of exposing every decision through dozens of prompts, I'm exploring a different direction: generate a solid foundation first, then let developers add capabilities as they need them.

Authentication
Database
Email
Storage
Payments
Monitoring

Those additions can evolve independently without turning the initial project creation into an interrogation.

Optimizing for Momentum

One of the biggest costs of starting a new project isn't writing code. It's context switching.

Every prompt interrupts momentum. Every configuration choice forces another decision before you've even written your first component. I'd rather spend those first ten minutes building a homepage than deciding which formatter to use.

That's why create-notils intentionally has very few questions. It assumes a sensible set of defaults and gets out of the way.

The Road Ahead

Being opinionated today doesn't prevent flexibility tomorrow. In fact, I think it makes future flexibility easier.

By first defining a production-ready baseline, I can later introduce optional capabilities without compromising the core experience. The foundation stays consistent. The project grows through composition instead of endless configuration.

That's the direction I want to explore next. In the next article, I'll take a closer look at how create-notils is organized internally, why the UI lives in its own package, and how that decision helps keep multiple applications consistent without duplicating components.

Try out the compiler architecture yourself by running npx create-notils my-app, or check out the source code on GitHub.

One Monorepo, Two Outputs: How I Eliminated Duplicate Starter Templates

Sanjay Kumar Sah — Mon, 20 Jul 2026 09:53:00 +0000

Part 2 of the Building create-notils series.

In my previous article, I explained why I stopped copy-pasting repositories and started building my own project scaffolding tool. However, one major architectural problem remained: I wanted create-notils to support both of these primary project structures.

A standalone Next.js application:

my-app/
├── src/
├── public/
├── package.json
└── components.json

And a Turborepo monorepo:

my-app/
├── apps/
│   └── app/
├── packages/
│   ├── ui/
│   └── config/
├── turbo.json
└── package.json

At first glance, the obvious solution is to maintain two separate templates—one for standalone and one for monorepo. Problem solved, right?

Except... it isn't.

The Hidden Cost of Multiple Templates

Every starter template starts out identical. Then one day, you fix a subtle bug in one template and forget to update the other. A week later, you upgrade Next.js in one repository before getting around to the second. A month later, you improve your UI package and find yourself manually copying files back and forth between folders.

Eventually, the templates slowly drift apart. The true cost isn't creating templates; the cost is maintaining them forever.

What Actually Changes?

When I sat down and compared the two project layouts side by side, surprisingly little was different. The actual application code, UI components, theming, and utility functions were 100% identical.

The only real differences were the structural project boundaries:

Concern	Monorepo	Standalone
UI Package	`packages/ui`	`src/components/ui`
Utilities	`@notils/ui/lib/utils`	`@/lib/utils`
Configuration	Shared workspace package	Local configuration
Package Manifests	Multiple (`package.json` files)	Single root manifest
Workspace Tooling	Present (`turbo.json`, workspaces)	Removed entirely

Everything else was effectively the exact same code. That single observation changed the entire architecture of create-notils.

A Different Approach: The Canonical Source of Truth

Instead of maintaining two templates, I decided to maintain only one. The monorepo became the canonical source of truth.

Whenever a developer chooses the monorepo option, the CLI simply clones and scaffolds it directly:

Canonical Monorepo
│
▼
Generated Monorepo

When someone chooses a standalone project, something much more interesting happens. The CLI dynamically transforms the canonical monorepo into a flattened standalone application:

Canonical Monorepo
│
▼
Flatten Transform
│
▼
Generated Standalone

Instead of storing two separate templates, I generate one directly from the other.

Thinking Like a Compiler

This shift changed how I thought about the CLI. It isn't just copying static files anymore; it is compiling a project. The monorepo acts as the source code, and the generated starter is the compiled output.

Because of this, the transformation can be cleanly broken down into deterministic, sequential steps:

Canonical Project
│
▼
1. Resolve Workspace Packages
│
▼
2. Rewrite Import Paths
│
▼
3. Move & Flatten Files
│
▼
4. Merge package.json Manifests
│
▼
5. Inline Shared Configurations
│
▼
6. Output Standalone Project

Each step in this pipeline has a single, isolated responsibility. That makes the entire process predictable, highly testable, and easy to evolve over time.

How the Monorepo Flattening Works

The transformation itself is surprisingly straightforward under the hood. Workspace packages simply become internal directories inside the application structure. For example, UI components are shifted directly into the source tree:

packages/ui/src/components/ui  ──►  src/components/ui

Shared utility functions are moved alongside them:

packages/ui/src/lib/utils.ts  ──►  src/lib/utils.ts

Next, the Abstract Syntax Tree (AST) or file contents are processed to rewrite import paths. A workspace import like this:

// Monorepo Workspace Import
import { Button } from "@notils/ui/components/ui/button";

Is automatically rewritten to a standard Next.js path alias:

// Standalone Local Import
import { Button } from "@/components/ui/button";

The exact same transformation happens for every shared workspace reference across the codebase. Zero component logic changes—only the artificial project boundaries disappear.

The Architectural Benefits

Treating the monorepo as a canonical compilation source provides several massive advantages for long-term maintenance:

1. One Source of Truth

Every bug fix, UI tweak, and architectural improvement is made exactly once. I never have to second-guess whether both project styles are synchronized.

2. Effortless Upgrades

When breaking changes drop for Next.js, Tailwind CSS, or React, I only update the canonical monorepo. Every generated project shape automatically inherits the upgraded foundation.

3. Automated CI Testing

Because generation is 100% deterministic, I can rigorously verify both outputs in a automated Continuous Integration (CI) pipeline:

Generate Monorepo ──► Build & Typecheck
       │
       ▼
Generate Standalone ──► Build & Typecheck ──► Verify Zero "@notils/*" Imports Remain

If the standalone transformation accidentally leaves behind even a single @notils/* workspace import, the CI pipeline fails immediately. Subtle scaffolding bugs become instant, actionable build failures.

Why Not Keep a "Shared Core" Submodule?

One common alternative I explored was keeping shared files in a common repository or submodule and wrapping two thin project templates around them. While this sounds clean in theory, it doesn't actually eliminate maintenance duplication.

You still end up manually managing:

Two separate package.json manifests
Two TypeScript (tsconfig.json) configurations
Two distinct linting and formatting setups
Two shadcn/ui configuration files
Two separate build and deployment pipelines

The duplication doesn't disappear; it just gets pushed to a different layer of the codebase. By treating the monorepo as the canonical compiler source, the standalone application becomes a zero-maintenance generated artifact.

Looking Ahead: From Templates to Targets

Right now, create-notils focuses exclusively on modern Next.js environments. But this compiler-style architecture opens up an exciting possibility: instead of thinking in terms of static templates, I'm starting to think in terms of compilation targets.

A single canonical project can eventually compile into completely different project shapes depending on the exact requirements of the developer. Today's supported targets are simply monorepo and standalone. Tomorrow, they could expand to include mobile-first layouts, desktop wrappers, or alternate frameworks that share a unified design system and backend layer.

Conclusion

The most valuable lesson I learned while building create-notils wasn't about Next.js app routers or Turborepo caching—it was about aggressively reducing maintenance overhead.

Every duplicated template is future technical debt. Every generated template is automation working in your favor.

When building developer tooling, the fundamental question stopped being:

"How many templates should I maintain?"

And became:

"How many project shapes can I generate from a single source of truth?"

That mindset shift fundamentally transformed how I build and maintain open-source software.

What do you think of generating standalone projects from a monorepo source of truth? Have you tackled template drift in your own tooling before? Let's discuss in the comments!

Try out the compiler architecture yourself by running npx create-notils my-app, or check out the source code on GitHub.

Why I Stopped Copy-Pasting Repositories and Started Building My Own Starter CLI

Sanjay Kumar Sah — Sat, 18 Jul 2026 18:51:36 +0000

Every developer has a "starter project." Some keep a GitHub template. Some duplicate their previous SaaS project. Some run create-next-app and spend the next two hours installing the same dependencies, configuring the same tools, and recreating the same folder structure.

I was in the second group. Every new project started the same way.

bun create next-app

Then came the checklist.

Install Tailwind CSS.
Configure Biome.
Add shadcn/ui.
Organize folders.
Set up a UI library.
Configure TypeScript.
Add environment files.
Set up a monorepo.
Copy utility functions.
Configure path aliases.
Install development tools.

None of these tasks were difficult. They were just repetitive. After starting enough projects, I realized something:

I wasn't building products. I was rebuilding the same foundation over and over again.

The Starter Kit Trap

Like many developers, I created a "starter repository." Whenever I wanted to build something new, I'd clone it. It worked... until it didn't.

Eventually I had multiple starter repositories.

One for a monorepo.
One for a standalone project.
One with authentication.
One without authentication.
One for experiments.
One that was already outdated.

Keeping them synchronized became its own maintenance project. Fix a bug in one. Forget to fix it in another. Upgrade Next.js in one repository. Forget the rest.

The more starters I created, the less useful they became.

Why Existing Starters Didn't Quite Fit

There are already fantastic starter kits in the ecosystem. Some focus on minimalism. Others include every feature imaginable. The problem wasn't that they were bad. The problem was that they optimized for someone else's workflow.

Every project I build starts with almost the same stack.

Next.js
TypeScript
Bun/pnpm
Tailwind CSS v4
shadcn/ui
Biome
Production-ready project structure

I didn't want to answer twenty configuration questions every time I scaffolded a project.

I wanted one command.

npx create-notils my-app

…and be ready to start building.

Opinionated Doesn't Mean Inflexible

One thing I've learned is that being opinionated is often a strength. Frameworks like Laravel, Rails, and even Next.js provide sensible defaults. You can always change them later. The important thing is that you're productive on day one.

That's the philosophy I'm following. Instead of trying to support every possible technology combination, I picked a stack that I genuinely enjoy using every day.

Everything generated by the CLI lives inside your repository.

Nothing is hidden.
Nothing is hosted.
Nothing prevents you from changing it.

The starter gives you a foundation—not a cage.

Building for Myself First

A question I've been asked is:

"Why not make everything configurable from the beginning?"

Because I'm the first user. The goal wasn't to build the most flexible scaffolding tool. The goal was to eliminate repetitive work from my own workflow. Once something proves useful in real projects, it can become configurable.

Until then, I'd rather spend my time building products than building configuration screens.

The Beginning of `create-notils`

That idea eventually became create-notils.

Right now, it focuses on doing one thing well:

Scaffold a modern Next.js project.
Support both standalone and monorepo layouts.
Configure a shared shadcn/ui setup.
Use Bun, Biome, Tailwind CSS v4, and TypeScript out of the box.

It's intentionally small.

Future releases will add authentication, database integration, API clients, Docker support, and more—but only after those features have been battle-tested in my own projects.

What's Next?

One design decision turned out to be far more interesting than I expected. I wanted to support both standalone projects and monorepos. Most tools solve this by maintaining two different templates.

I chose a different approach: The monorepo is the single source of truth, and the standalone project is generated from it through a deterministic transform.

That means I only maintain one project while generating two different project shapes.

In the next article, I'll dive into how that architecture works, why I chose it, and how it avoids template duplication.

I'd love to hear how you start new projects.

Do you use GitHub templates, starter repositories, scaffolding tools, or something completely different?

Building React Native Shouldn't Feel Like Assembling IKEA Furniture: A Modern Monorepo Starter Kit

Sanjay Kumar Sah — Tue, 14 Jul 2026 10:54:50 +0000

"I just want to build my app."

That sentence sounds simple. But if you've ever started a new React Native project, you know that is rarely what actually happens.

You open your terminal with excitement:

npx create-expo-app my-app

Five minutes later, you're already searching:

"How to set up Tailwind CSS in React Native?"
"Should I use NativeWind?"
"How do I share components between mobile and web apps?"
"Expo Router or React Navigation?"
"How do people organize React Native monorepos?"
"Should I use Turborepo?"
"How do I keep multiple apps sharing the same UI?"

Before you have written your first screen... you have already spent hours making architectural decisions. Not product decisions. Not business decisions. Just project setup.

The Invisible Tax Every React Native Developer Pays

Imagine you are opening a restaurant. You have recipes. You have chefs. You know exactly what food you want to serve. But before opening the doors, someone tells you:

"First, build the kitchen."

So you start researching:

which stove?
Which oven?
Which refrigerator?
How should the plumbing work?
How do multiple restaurants share ingredients?

Months later... you still haven't served a single customer.

Software development often feels exactly like that. We don't struggle because building apps is hard. We struggle because building the environment to build apps is hard.

Every New Project Starts With The Same Questions

Every engineering team eventually reaches the same crossroads:

"How should we organize this codebase?"

Should every app have its own repository?
Or should they share everything?
Should design components live inside the mobile app folder, or inside separate workspace packages?
What about authentication, API clients, themes, icons, and utilities?

Every answer seems correct... until six months later.

Then The Real Problems Begin

Imagine your company builds two applications: a Customer App and a POS App. Both need:

Buttons & Forms
A consistent design theme
Icons & Typography
Authentication plumbing
A typed API client

At first, copy-pasting feels faster. Until the designer changes one button style. Now your codebase looks like this:

Customer App  👉  Updated ✅
POS App       👉  Outdated ❌

Next week, the typography changes. Then the color palette. Then spacing. Suddenly, you are spending your weekends maintaining two separate design systems that were supposed to be one.

"Let's Make a Shared UI Package"

Sounds easy. Until you actually try to set it up in a mobile environment. Now you are diving deep into:

npm / pnpm workspaces
Turborepo pipeline caching
Package export maps
Metro bundler configuration
TypeScript path aliases & references
Babel plugins & module resolution

You started because you wanted one shared button. Now you are spending your evening debugging why Metro cannot resolve an SVG icon.

Styling Was Supposed To Be Easy, Too

Most web developers already know and love Tailwind CSS. So naturally, they ask:

"Can I just use Tailwind in React Native?"

The answer is yes. Then comes another rabbit hole:

Babel plugins
Metro config adjustments
Dark mode persistence
Theme CSS variables
Hot reload bugs
And version compatibility.

When NativeWind v5 arrived, it solved many long-standing pain points and made styling feel much closer to the web Tailwind experience developers love. But getting everything configured correctly - and keeping it working smoothly across SDK upgrades - still takes considerable time.

The styling itself isn't the hard part. The boilerplate setup is.

Building Components Is Harder Than It Looks

Most production apps don't need fancy, animated components. They need consistent, accessible components. A button should always look and feel like a button. An input should always handle keyboard focus correctly. A modal dialog should behave predictably across iOS and Android.

Projects like React Native Reusables made this dramatically easier by bringing modern, accessible UI primitives into the React Native ecosystem. Instead of reinventing custom components for every project, you start with well-designed building blocks.

But even then... someone still has to integrate, theme, and wire everything together across version upgrades.

⚡ The NativeWind v5 Migration Gap (And How RNStack Solves It)

Right now, React Native Reusables officially targets NativeWind v4. If you try using it with NativeWind v5, you will immediately hit styling bugs and breaking changes.

In RNStack, I have already fully migrated all included components to NativeWind v5 (Tailwind v4) and pre-fixed common problem areas—especially complex components like Icon, Button, and Select—so they render seamlessly across iOS, Android, and web out of the box.

And Then Comes Scale

Your first app becomes successful. Now the business asks:

"Can we build another app for our internal team?"

Great! Except now your architectural requirements have multiplied:

📱 Customer App   |   🛠️ Admin App   |   🏪 POS App   |   🚚 Driver App

Four applications. One engineering team. One design language. One backend API. One authentication system.

Should you create four separate repositories? Or one? This is where monorepos stop being a buzzword and start becoming a practical survival tool.

A monorepo isn't just about putting everything into one giant folder. It is about giving every project access to the exact same foundation: One shared UI. One shared API layer. One shared configuration. One source of truth.

But Monorepos Bring Their Own Challenges

Large repositories can easily become painfully slow. Without proper tooling, every build starts rebuilding everything from scratch, and every dependency install feels heavier.

That is where Turborepo changes the story. Instead of rebuilding the entire house every time you make a change, it only rebuilds the rooms you have actually touched.

The result is a development workflow that stays lightning-fast even as your codebase grows. Not because your apps became smaller—but because your tooling became smarter.

After Solving The Same Problems Again And Again...

I noticed a pattern. Every project I worked on looked different on the surface... but the foundational setup looked almost identical.

Every time I started a new React Native project, I found myself

copying the same workspace files
installing the exact same dependencies
configuring the same Metro resolver fixes
setting up the same TypeScript aliases
building the same shared UI package
and configuring Expo Router and NativeWind.

Over and over again.

Eventually, I stopped asking: "How do I start another project?"

Instead, I asked: "Why am I solving this plumbing problem every single time?"

That's Why I Built RNStack

RNStack isn't trying to replace Expo. It isn't another heavy UI library. It isn't a random collection of disconnected snippets.

It is simply the mobile-first, production-ready monorepo foundation I wished every new React Native project started with. A clean architecture where the difficult, time-consuming setup decisions have already been made for you. So you can focus on building your actual product instead of wrestling with build tools.

One Command To Start

You can scaffold a clean, production-ready project instantly using the create-rnstack npm package:

pnpm create rnstack my-app

A few moments later, you have a fully wired workspace that already includes:

Category	Pre-Configured Tooling
Core Framework	Expo (SDK 56) + Expo Router
Styling & UI	NativeWind v5 + React Native Reusables
Architecture	Turborepo + pnpm Workspaces
Shared Packages	Pre-linked `@repo/ui`, `@repo/api-client`, and `@repo/config`
Code Quality	Strict TypeScript, Biome, Husky
Reliability	Automatic Expo dependency validation & native bundle ID management

No hunting through outdated Medium tutorials. No copy-pasting broken configurations. No wondering whether you forgot a crucial setup step.

Small Details Matter

The biggest improvements in developer experience are often the ones you never notice because everything just works. RNStack automatically handles the subtle details that are easy to forget but painful to fix later:

✅ Unique Native Bundle IDs: Every generated app automatically gets a clean, unique bundle identifier.
✅ Aligned SDK Versions: Expo dependency versions stay strictly aligned with your installed SDK.
✅ Immediate Git Hooks: Pre-commit formatting and linting work right out of the box.
✅ Zero Bloat: Projects start clean without shipping dozens of unnecessary boilerplate demo screens.

These aren't flashy marketing features. They are the quiet, architectural details that save dozens of hours over the lifetime of a production codebase.

The Goal Was Never To Build Just Another Boilerplate

There are already plenty of starters out there. But most of them stop right after generating a few static files.

RNStack tries to go one step further: it gives you an evolving foundation meant to survive far beyond your first commit. Something robust enough to build your next weekend side project on, scale into a startup MVP, or ship to thousands of production users.

Try It Out & Join The Journey

If you are starting a new React Native project this week, give RNStack a spin. I would genuinely love to hear your feedback—what feels intuitive, what feels awkward, and what could be improved!

Every issue opened, suggestion made, and pull request submitted helps make the mobile development experience better for the next engineer.

🔗 Get Started in Seconds

Scaffold your new project right now from your terminal:

pnpm create rnstack my-app

📦 NPM Package: Check out the CLI documentation on the create-rnstack npm page.
⭐ GitHub Repository: Explore the monorepo architecture, star the repo, or contribute on sanjaysah101/rnstack.

If RNStack saves you a few hours—or helps you skip a frustrating evening of configuration—that is exactly why I built it.

Happy building! 🚀

BrewOps: A Production-Grade HTCPCP Dashboard

Sanjay Kumar Sah — Thu, 02 Apr 2026 11:40:36 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built BrewOps, a highly serious, production-grade DevOps dashboard for a delightfully useless protocol: the Hyper Text Coffee Pot Control Protocol (HTCPCP, RFC 2324).

Tired of walking to the breakroom only to find the coffee pot empty? BrewOps brings 1998's best internet joke into the modern era. It's a sleek control center that lets you monitor your network of coffee pots and teapots. You can issue BREW and PROPFIND requests, select your Accept-Additions (like Milk, Syrup, or Alcohol), and watch the live terminal logs.

And yes, if you try to brew coffee using the "Earl Grey Teapot" appliance, the server will correctly reject your request with a 418 I'm a teapot status code, complete with a panic animation.

Demo

Live App: BrewOps HTCPCP Dashboard

Code

Source Code: Google AI Studio Project

How I Built It

I built this using Next.js and Tailwind CSS to give it that authentic, dark-mode "serious developer tool" aesthetic. The icons are from lucide-react, and I used motion/react (Framer Motion) to create the smooth terminal log entries and the bouncing teapot animation when a 418 error is triggered.

The entire project was generated, iterated on, and deployed using Google AI Studio.

Prize Category

I am submitting this for two categories:

1. Best Ode to Larry Masinter:
This project is a literal, playable implementation of Larry Masinter's legendary RFC 2324. It faithfully recreates the HTCPCP headers (Accept-Additions, message/coffeepot content types) and intentionally triggers the famous 418 I'm a teapot error when you target the wrong appliance.

2. Best Google AI Usage:
I built this entire application from scratch using Google AI Studio (powered by Gemini 3.1 Pro). The AI agent helped me scaffold the Next.js app, design the Tailwind UI, write the simulated terminal logic, and instantly deploy the final build to Google Cloud Run (which is where it is currently hosted!).

Serenity: A Personal AI Wellbeing Companion Built with Google Gemini

Sanjay Kumar Sah — Tue, 03 Mar 2026 11:51:28 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built Serenity, a comprehensive, privacy-first mental health and wellbeing application designed to act as your personal caretaker, health coach, and daily companion.

Mental health tools are often fragmented—you use one app for habit tracking, another for journaling, and yet another for meditation. Serenity solves this by combining all these tools into one cohesive, beautifully designed platform. It includes:

Mood Check-ins & Insights: Track daily emotional trends.
Daily Journal: A safe space for reflection.
Habit & Goal Tracker: Build positive routines and set long-term targets.
Wellness Hub: Interactive exercises including Box Breathing, 5-4-3-2-1 Grounding, Body Scan meditations, and Eye Strain Relief.

The Role of Google Gemini:
Google Gemini (gemini-3-flash-preview) acts as the core "brain" and empathetic heart of the app. Instead of just a generic chatbot, Serenity uses the @google/genai SDK to read your recent moods, incomplete habits, journal entries, and long-term goals as context.

Gemini provides highly tailored advice, health tips, and emotional support. For example, if you set a goal to "Run a 5K", you can click "Ask Serenity for a Plan", and Gemini will instantly generate a personalized diet, exercise, and lifestyle plan based on your current habits and mood history. It also proactively generates warm, encouraging reminders if you forget to complete your daily habits!

Demo

You can try out the live version of Serenity here:
🔗 Live Demo
🔗 Github Repo

(Note: The app is designed with a "Warm Organic" aesthetic using Tailwind CSS and Framer Motion to create a calming user experience.)

What I Learned

Building Serenity was an incredible learning experience:

Contextual AI Engineering: I learned how to effectively pass structured JSON data (user moods, habits, journals) into Gemini's system prompt to create an AI that truly "remembers" and understands the user's current state.
UI/UX for Mental Health: I learned the importance of color psychology and micro-interactions. Using glassmorphism, soft sage/earth tones, and smooth Framer Motion animations helped create a UI that actually lowers stress rather than adding to it.
Interactive Component Design: Building the Wellness Hub taught me how to manage complex state and timers in React, especially for the Body Scan and Eye Strain Relief exercises.

Google Gemini Feedback

What worked well:
The new @google/genai SDK is incredibly intuitive. The speed of the gemini-3-flash-preview model is phenomenal—it makes the conversational assistant feel truly real-time. I was also deeply impressed by how well Gemini understood the structured context I passed to it. It seamlessly connected the dots between a user feeling "anxious" in their mood log and suggesting the built-in grounding exercises.

Where I ran into friction:

The main challenge was prompt engineering to get the tone exactly right. Initially, the AI sounded a bit too clinical or robotic. I had to refine the system instructions heavily to ensure it consistently spoke with the warmth, empathy, and brevity of a "personal caretaker." Additionally, handling the multimodal inputs (allowing users to upload images to the chat) required some careful base64 encoding logic to pass to the API correctly, but once set up, it worked flawlessly.

Built with ❤️ for the Hack for Mental Health 2026 & DEV Challenge.

From Zero Rust to DevOps: Building a System Monitor with GitHub Copilot CLI

Sanjay Kumar Sah — Sun, 15 Feb 2026 06:34:12 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built rust-tui-dashboard, a terminal-based system monitor (similar to htop or btop) written entirely in Rust.

As a Full-Stack developer primarily experienced with JavaScript and the MERN stack, I have always wanted to learn Rust. However, the steep learning curve—specifically the borrow checker and strict type system—was intimidating. For this challenge, I decided to use the GitHub Copilot CLI as my "Senior Rust Engineer" to guide me through building a production-ready application from scratch.

Key Features:

Visual Gauges: Real-time CPU & Memory usage visualized with colorful progress bars (Cyan & Yellow).
Disk Alerts: Tracks partition usage (which hilariously warned me that my own drive is 97.5% full!).
Network Stats: Live upload/download speed tracking.
Cross-Platform: Runs on Linux, macOS, and Windows.
Automated Builds: A CI/CD pipeline set up via GitHub Actions.

Demo

Here is the final result running in my terminal:

Repository: rust-tui-dashboard

My Experience with GitHub Copilot CLI

Building this project was a journey of "Prompt -> Error -> Explanation -> Fix." The Copilot CLI didn't just write code for me; it taught me why the code worked (or didn't).

1. The "Hello World" Moment

I started with an empty folder and didn't even know the command to initialize a Rust project.
Prompt: how to initialize a new rust project named dev-dashboard
Result: It gave me cargo new dev-dashboard immediately. I was up and running in seconds.

2. Overcoming the "Generic" Hallucination

This was the most valuable interaction. I used the ratatui library for the UI, but the code Copilot initially suggested threw a complex compilation error:
error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied

Instead of pasting this into Google, I asked the CLI:

Prompt: struct takes 0 generic arguments but 1 generic argument was supplied

The Fix: Copilot correctly identified that the library version I installed had a breaking API change (Frame<B> became just Frame). It explained the difference, and while its initial code fix was slightly aggressive (it removed generics from everything), the explanation gave me enough context to manually fix the Terminal struct generics while simplifying the Frame struct. It turned a potential 2-hour debugging session into a 5-minute fix.

3. From Text to "Eye Candy"

Initially, my dashboard was just text blocks. I wanted it to look professional.

Prompt: "Update the ui function. Instead of displaying CPU Usage as simple text, use the ratatui::widgets::Gauge widget. Set the percent to app.cpu_usage and color it Cyan."

It instantly scaffolded the Gauge widget code, giving me professional-looking progress bars without me needing to read the entire documentation.

4. The DevOps Bonus

I didn't want users to have to compile the code themselves.

Prompt: "Create a GitHub Actions workflow file named .github/workflows/release.yml to build the project on push."

Copilot generated a perfect YAML file. Now, every time I push code, GitHub Actions automatically compiles my Rust binary and uploads it as an artifact.

Conclusion

The GitHub Copilot CLI bridged the gap between my JavaScript knowledge and Rust's strict environment. It allowed me to build a tool that I actually use now—if only to remind me to clean up my hard drive (seriously, only 7GB left!).

How I Improved Email Rendering Performance 15x Using Rust + WebAssembly (Next.js 16 Devlog)

Sanjay Kumar Sah — Fri, 13 Feb 2026 10:41:57 +0000

I decided to do something scary: Build a SaaS product in public, from scratch, sharing every win and every embarrassing error log along the way.

The product is Ansomail—an AI-powered drag-and-drop email editor.
The goal? To build a tool where Developers set the rules (Design System) and Marketers just drag-and-drop blocks, without ever breaking the layout.

Here is the unvarnished truth of my first week: battling the "bleeding edge" tax of Next.js 16, crashing my database, and eventually rewriting my engine in Rust for a 15x speed boost.

The Stack: Betting on Speed

I didn't want a legacy stack. I wanted speed.

Runtime: Bun (for instant startup)
Framework: Next.js 16 (Turbopack)
Monorepo: Turborepo (preparing for the Ansospace ecosystem)
Database: Postgres + Drizzle ORM
Linting: Biome (Farewell, ESLint)

It looked perfect on paper. Then I started coding.

Days 1-2: The Architecture & The "AI Architect"

The first challenge wasn't code; it was philosophy. How do you stop an AI from generating broken HTML?

Most AI builders treat LLMs like creative writers. I decided to treat them like Strict Architects. I set up a system where the AI's output is validated against a rigid JSON Schema. If the AI hallucinates a CSS class that doesn't exist in my system, the update is rejected before it ever hits the UI.

I also set up the "Hello World" of modern SaaS: An empty repo configured with Biome and Bun. It was clean, fast, and satisfying.

Days 3-4: The "Bleeding Edge" Tax

Then came the pain.

I hit what I call the "Bleeding Edge Tax." Next.js 16 and Bun are incredible, but they don't always play nice together. My dev server started crashing on hot reloads.

And then, I killed my database. 💀

I started getting the dreaded error:
FATAL: sorry, too many clients already

Because I'm using a serverless environment, every hot reload was opening a new connection to Postgres without closing the old one. My database choked.

The Fix: I had to implement strict Connection Pooling. It was a harsh reminder that "Serverless" doesn't mean "Ops-less." Once I capped the active connections, the backend stabilized, and I shipped the "My Templates" dashboard.

Days 5-6: Chasing the "Google Docs" Feel

With the backend stable, I moved to UX. I wanted a "Rename Template" feature that felt like Google Docs—instant.

I implemented Optimistic UI. When a user types, the UI updates immediately. The server validates it in the background. If it fails, we revert. If it works, the user never notices the lag.

// Detect dark theme var iframe = document.getElementById('tweet-2021209854837158185-500'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2021209854837158185&theme=dark" }

I also built the first version of the Rendering Engine:

DB stores JSON.
Parser converts JSON → MJML.
mjml-browser converts MJML → HTML.
Result renders in an iframe.

It worked. But it was slow. ~18ms per render. For a drag-and-drop tool, that felt sluggish.

Day 7: The Rust Rewrite (15x Speed Boost) 🚀

I couldn't settle for 18ms. I knew mjml-browser (Pure JS) was the bottleneck.

So, I did something drastic for a one-week-old project: I swapped the engine to Rust.

import { Engine, type ToHtmlResult } from "mrml";

const convertMJMLToHTML = (mjmlString: string) => {
  const engine = new Engine();
  const result = engine.toHtml(mjmlString);
  return result;
};

I integrated MRML (a Rust port of MJML) via WebAssembly.
The integration was tricky—Rust is strict. It refused to compile my "sloppy" JSON that JS had been happily ignoring. It forced me to fix my data structure.

But once it worked? The results were insane.

JS Engine: ~18ms
Rust (WASM): ~1.1ms

That is a 15x speed increase. The preview is now effectively real-time, running at 60fps.

What's Next?

Week 1 was about the Foundation. Week 2 is about the Interaction.

Now that I have a 1ms rendering engine, I'm building the actual Drag-and-Drop layer.

I'm documenting this entire journey daily on X (Twitter). If you're into Next.js, Rust, or just want to see a developer struggle and succeed in real-time, come say hi!

Follow the journey: #ansomail / @ansomail
Connect with me: x.com/sanjaysah101

Ansomail Devlog #1: Replacing JavaScript with Rust for 15x Faster Email Rendering (Next.js + WASM)

Sanjay Kumar Sah — Fri, 13 Feb 2026 05:46:06 +0000

Ansomail is an AI-powered drag-and-drop email builder I’m building in public. This week, I replaced its JavaScript rendering engine with Rust — and made it 15x faster.

I decided to do something scary: build a SaaS product in public, from scratch, sharing every win and every embarrassing error log along the way.

By Day 4, I had:

Crashed my database
Broken hot reload
Built an engine that felt painfully slow

By Day 7, I had:

Rewritten the rendering engine in Rust
Reduced render time from ~18ms → ~1.1ms (~15x faster)
Learned that “bleeding edge” stacks come with hidden costs

This is my Week 1 retrospective building Ansomail, an AI-powered drag-and-drop email editor.

The Goal: Building a High-Performance AI Email Builder

I’m building an email editor where:

Developers define the design system
Marketers drag-and-drop blocks
AI generates content — but never breaks layout

The constraint: The preview must feel like Google Docs. Instant.

Tech Stack: Next.js 16, Bun, Postgres & MJML

I deliberately chose a modern stack optimized for speed:

Runtime: Bun
Framework: Next.js 16 (Turbopack)
Monorepo: Turborepo
Database: Postgres + Drizzle ORM
Linting/Formatting: Biome
Initial Rendering Engine: mjml-browser

It looked perfect on paper.

Then reality happened.

Days 1–2: Enforcing AI Output with JSON Schema Validation

The first architectural decision wasn’t about performance.

It was about control.

Instead of letting the LLM freely generate HTML, I:

Forced output into a strict JSON Schema
Validated structure before rendering
Rejected hallucinated classes or invalid styles

If the AI generates something outside the system, the update is rejected before it ever touches the UI.

That constraint will save me months later.

Days 3–4: The “Bleeding Edge” Tax (Next.js + Bun Issues)

Using Bun with Next.js 16 is fast — but not always stable.

Hot reload started crashing with cache component errors:

Next.js cannot guarantee that Cache Components will run as expected due to the current runtime's implementation of setTimeout().

Then I hit this:

FATAL: sorry, too many clients already

In a serverless dev environment, every hot reload opened a new Postgres connection.

They weren’t being closed. My database choked.

Fixing “Too Many Clients Already” with Proper Connection Pooling

“Serverless” does NOT mean “Ops-less.”

I implemented strict pooling and ensured a singleton pattern during development:

import { drizzle } from "drizzle-orm/node-postgres";
import { Pool } from "pg";

import * as schema from "./schema";

const connectionString = process.env.DATABASE_URL;

if (!connectionString) {
  throw new Error("DATABASE_URL is missing");
}

const globalForDb = globalThis as unknown as {
  pool: Pool | undefined;
};

const pool =
  globalForDb.pool ??
  new Pool({
    connectionString,
    max: process.env.DB_MAX_CONNECTIONS
      ? parseInt(process.env.DB_MAX_CONNECTIONS, 10)
      : 10,
    idleTimeoutMillis: 30000,
    connectionTimeoutMillis: 2000,
  });

if (process.env.NODE_ENV !== "production") {
  globalForDb.pool = pool;

  pool.on("connect", (client) => {
    console.log(`🔌 Database: New client connected to the pool; client: ${client}`);
  });

  pool.on("error", (err, client) => {
    console.error(`❌ Database: Unexpected error on idle client; client: ${client}`, err);
  });

  pool.on("remove", (client) => {
    console.log(`🗑️ Database: Client removed from pool; client: ${client}`);
  });
}

export const db = drizzle(pool, { schema });

Once I capped connections, everything stabilized.

Lesson: Dev hot reload + serverless Postgres can quietly DOS your own app.

Days 5–6: Implementing Optimistic UI for Instant Feedback

I implemented Optimistic UI for renaming templates.
// Detect dark theme var iframe = document.getElementById('tweet-2021209854837158185-995'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2021209854837158185&theme=dark" }

User types → UI updates immediately.
Server validates in the background.
Failure → rollback.
Success → seamless.

That part worked beautifully.

But the real bottleneck was rendering.

Initial Rendering Pipeline (JavaScript + MJML)

The original rendering pipeline:

JSON stored in DB
JSON → MJML
mjml-browser converts MJML → HTML
HTML rendered inside an iframe

It worked.

But it averaged ~18ms per render.

For a drag-and-drop email builder, that felt sluggish.

Day 7: Replacing JavaScript with Rust + WebAssembly

The bottleneck was mjml-browser (pure JavaScript).

So I replaced it.

I integrated MRML (a Rust port of MJML) compiled to WebAssembly (WASM).

Why?

Rust → predictable performance
MRML → faster MJML parsing
WASM → near-native speed in the browser

Rust Integration Challenges

Rust does not tolerate “almost correct.”

It refused to compile my “sloppy” JSON that JavaScript had been happily ignoring.

It forced me to fix my data structures.

That strictness improved my architecture.

Performance Results: 15x Faster Email Rendering

After integrating MRML via WASM:

JavaScript Engine: ~18ms
Rust (WASM) Engine: ~1.1ms

That’s roughly a 15x performance improvement.

The preview now runs comfortably within a 16ms frame budget — effectively real-time at 60fps.

Unexpected Benefits of Moving to Rust

Cleaner schema enforcement
Deterministic parsing
Smaller rendering bottleneck surface
Future-proof performance foundation

Lessons Learned Building a SaaS in Public (Week 1)

Bleeding-edge stacks save time — until they don’t.
Serverless still requires backend discipline.
Rust’s strictness is a feature, not friction.
Early performance decisions compound.

What’s Next for Ansomail?

Week 1 was about the foundation.

Week 2 is about interaction.

Now that I have a ~1ms rendering engine, I’m building the actual drag-and-drop layer on top of it.

I’m documenting this entire journey publicly.

If you're building with Next.js, Rust, WebAssembly, or experimenting with high-performance SaaS architecture — I’d love to connect.

Ansomail is currently in development. If you're a developer or marketer who struggles with email design systems, I’d love to talk.

SanjayOS: I Built an AI-Powered Operating System for My Portfolio 🚀

Sanjay Kumar Sah — Thu, 29 Jan 2026 10:08:32 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi there! 👋 I'm Sanjay Sah, a Software Engineer based in India (originally from Nepal) with over two years of experience building high-performance web applications. I currently work at Zuru Tech, where I focus on the MERN stack, Next.js, and crafting smooth user experiences.

I've always felt that standard portfolio websites are... well, a bit static. They tell you about a developer, but they don't show you how they think.

For this challenge, I wanted to break that mold. I wanted to express my love for complex systems, retro aesthetics, and cutting-edge AI. My goal was to build a portfolio that isn't just a document you read, but a system you explore.

Portfolio

Welcome to SanjayOS v1.0 — an AI-native Developer Operating System.

Instead of navigating a menu, you boot into a desktop environment. You can drag windows, run terminal commands, and interact with an intelligent system core.

Go ahead, give it a spin! The entire OS is running serverless on Google Cloud Run.

(If the interactive embed above doesn't load fully, you can launch SanjayOS in a new tab here)

How I Built It

Building an "Operating System" in the browser is no small feat. Here is the architecture that powers SanjayOS:

🛠️ The Tech Stack

Framework: Next.js 16 (App Router) for the core structure.
Runtime: Bun for ultra-fast builds and package management.
Styling: Tailwind CSS + Shadcn/ui (heavily customized for that "Glassmorphism" OS look).
State Management: Zustand to handle the complex window manager logic (z-indexing, minimizing, focusing apps).
Deployment: Dockerized and hosted on Google Cloud Run to handle Server-Side Rendering (SSR) while scaling to zero when idle.

🧠 The Google AI & Antigravity Workflow

The heart of SanjayOS is Google Gemini 2.5 Flash, integrated via the Vercel AI SDK. But the construction of this complex system was accelerated by Google Antigravity.

Built with Antigravity: I used Google's Antigravity (AI-first IDE) to scaffold the complex window management logic and rapidly prototype the Generative UI components. It acted as my "pair programmer," helping me integrate the Gemini API correctly and ensuring my prompt engineering was optimized for tool calling.
System Instructions: I fed the AI a structured JSON context of my entire career (resume, projects, skills). This means no RAG vector database was needed—Gemini's massive context window handles it all in real-time.
Tool Calling: The AI has permission to "control" the OS. If you ask, "Show me Sanjay's projects," Gemini doesn't just write a list; it executes a function to launch the Project Viewer app automatically.

What I'm Most Proud Of

There are three specific achievements I'm thrilled with:

The "Alive" Feeling: The moment you realize the AI isn't just a text box—it's the OS Kernel. Seeing the AI open windows and highlight UI elements based on a conversation feels like the future of web interfaces.
The Window Manager: Building a performant, draggable, resizable window system in React was a complex challenge. Solving the "z-index stacking" (ensuring the clicked window always comes to the front) without causing re-renders was a great engineering puzzle.
The Cloud Run Deployment: Getting a Next.js Docker container to run smoothly on Cloud Run with the correct standalone output and environment variables was a huge win. It proves that personal portfolios can be both high-tech and cost-effective.

I hope you enjoy exploring SanjayOS as much as I enjoyed building it.

Happy Hacking! 💻✨

🎉 From Hackathon Idea to Super Contributor — My Hacktoberfest 2025 Journey

Sanjay Kumar Sah — Tue, 14 Oct 2025 06:55:31 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Open Source Reflections

“Hackathons build projects. Open source builds people.” 💡

Hey everyone 👋 I’m Sanjay Kumar Sah, and this Hacktoberfest was more than just a coding challenge — it was a journey of growth, collaboration, and community.

I started with a small idea from a hackathon project, and ended up becoming a Super Contributor with 6 merged PRs, open-source growth, and even the official Hacktoberfest T-shirt! 🎽

Here’s the story 👇

🌱 The Beginning: Humanizing AI Text

It all began with the Humanizing AI Text Hackathon, organized by Hackathon Raptors.
My goal was simple but exciting:

Make AI-generated text feel more human — natural, emotional, and contextual.

The result?
My project Humanize-AI was born.

And guess what — it ranked 3rd place! 🥉

That recognition gave me the push to take it further — beyond the hackathon and into the open-source world.

🚀 Turning a Hackathon Project into an Open-Source Repo

After the hackathon, I decided to open-source Humanize-AI so others could contribute, improve, and learn from it.

The response was incredible:
⭐ 26 stars
🍴 19 forks
💬 and real collaboration from developers around the world.

It was the first time I saw how powerful open source can be — how a small idea can grow when shared publicly.

Open source isn’t just about publishing your code — it’s about building a community around your ideas.

🤝 From Contributor → Collaborator

This year, I also became an official contributor at NexGenStudioDev.

But instead of just submitting PRs, I started doing code reviews — and that changed everything.

Reviewing others’ code helped me:

Understand new perspectives 👀
Learn clean coding practices 💡
Communicate better as a developer 🧠

Writing code makes you a contributor.
Reviewing code makes you a collaborator.

If you’ve never reviewed a PR before, I highly recommend it.
It’s the fastest way to level up your technical and communication skills.

🏁 The Finish Line: Super Contributor Badge

Completing 6 pull requests this Hacktoberfest earned me the Super Contributor Badge 🏅 — and the classic Hacktoberfest T-shirt 🎽 (the best kind of swag 😄).

But beyond the badge and T-shirt, what I really earned was:

Confidence to contribute anywhere 💪
Deeper respect for maintainers 🛠️
And lifelong connections in the developer community 🌐

📚 What I Learned Along the Way

Here are my top takeaways from this journey:

Start small.
You don’t need a huge project — even a simple idea can inspire others.
Open-source early.
Don’t wait for perfection. Share your work and invite collaboration.
Review more.
Reviewing others’ code teaches you more than writing your own.
Engage with the community.
Hacktoberfest is about people, not just pull requests.
Celebrate progress.
Every PR, every merge, every star — it all counts. 🎉

💬 What’s Next?

I plan to keep improving Humanize-AI with new features and better humanization techniques for AI-generated text.
If you’re interested in NLP, prompt engineering, or AI communication — I’d love to collaborate!

👉 Check it out here: github.com/sanjaysah101/humanize-ai

And if you’re preparing for Hacktoberfest 2026, here’s my advice:

Don’t just aim to complete PRs — aim to connect, learn, and give back.

🫶 Thanks to the Community

A huge shoutout to:

@NexGenStudioDev team
Hackathon Raptors organizers for Humanizing AI Text
Every contributor who starred, forked, or opened an issue

You all made this journey memorable.

🏆 TL;DR – My Hacktoberfest 2025 in Numbers

Category	Highlights
Hackathon	Humanizing AI Text (Ranked 3rd 🥉)
Repo	26+⭐ + 19+🍴
Contributions	6+ PRs merged
Roles	Contributor + Reviewer
Rewards	Super Contributor Badge 🏅 + Official T-shirt 🎽

💌 Final Thoughts

Hacktoberfest isn’t just a celebration of code — it’s a celebration of collaboration.
If you’ve ever hesitated to start, remember:

“The best time to contribute to open source was yesterday. The next best time is today.”

DEV Community: Sanjay Kumar Sah

You Should Own Your UI Components, Not Just Install Them

Installing Dependencies vs. Owning Your Code

Source Code Is the API

One Design System, Multiple Applications

Updating Isn't a Package Upgrade

The Same Philosophy Beyond Components

Version 0.2.0 is Live

Opinionated by Design: Why I Chose Sensible Defaults Over Endless Configuration

The Configuration Trap

I Built the Tool I Wanted to Use

Opinionated Doesn't Mean Closed

Defaults Should Be Battle-Tested

Configuration Can Come Later

Optimizing for Momentum

The Road Ahead

One Monorepo, Two Outputs: How I Eliminated Duplicate Starter Templates

The Hidden Cost of Multiple Templates

What Actually Changes?

A Different Approach: The Canonical Source of Truth

Thinking Like a Compiler

How the Monorepo Flattening Works

The Architectural Benefits

1. One Source of Truth

2. Effortless Upgrades

3. Automated CI Testing

Why Not Keep a "Shared Core" Submodule?

Looking Ahead: From Templates to Targets

Conclusion

Why I Stopped Copy-Pasting Repositories and Started Building My Own Starter CLI

The Starter Kit Trap

Why Existing Starters Didn't Quite Fit

Opinionated Doesn't Mean Inflexible

Building for Myself First

The Beginning of create-notils

What's Next?

Building React Native Shouldn't Feel Like Assembling IKEA Furniture: A Modern Monorepo Starter Kit

The Invisible Tax Every React Native Developer Pays

Every New Project Starts With The Same Questions

Then The Real Problems Begin

"Let's Make a Shared UI Package"

Styling Was Supposed To Be Easy, Too

Building Components Is Harder Than It Looks

And Then Comes Scale

But Monorepos Bring Their Own Challenges

After Solving The Same Problems Again And Again...

That's Why I Built RNStack

One Command To Start

Small Details Matter

The Goal Was Never To Build Just Another Boilerplate

Try It Out & Join The Journey

🔗 Get Started in Seconds

BrewOps: A Production-Grade HTCPCP Dashboard

What I Built

Demo

Code

How I Built It

Prize Category

Serenity: A Personal AI Wellbeing Companion Built with Google Gemini

What I Built with Google Gemini

Demo

What I Learned

Google Gemini Feedback

From Zero Rust to DevOps: Building a System Monitor with GitHub Copilot CLI

What I Built

Demo

My Experience with GitHub Copilot CLI

1. The "Hello World" Moment

2. Overcoming the "Generic" Hallucination

3. From Text to "Eye Candy"

4. The DevOps Bonus

Conclusion

How I Improved Email Rendering Performance 15x Using Rust + WebAssembly (Next.js 16 Devlog)

The Stack: Betting on Speed

Days 1-2: The Architecture & The "AI Architect"

Days 3-4: The "Bleeding Edge" Tax

Days 5-6: Chasing the "Google Docs" Feel

Day 7: The Rust Rewrite (15x Speed Boost) 🚀

What's Next?

Ansomail Devlog #1: Replacing JavaScript with Rust for 15x Faster Email Rendering (Next.js + WASM)

The Beginning of `create-notils`