Forem: sanjay kumar

Turborepo vs Regular Monorepo: When It's Worth It (And When It's Not)

sanjay kumar — Mon, 19 Jan 2026 16:32:44 +0000

📦 Turborepo vs. Regular Repos: When It Helps — and When It’s Overkill

Modern JS/TS projects often grow into multiple packages — maybe a backend, a frontend, shared UI components, and utilities. At that point you face a choice:

➡️ Stick to separate repos (or a basic monorepo)
➡️ Add tooling like Turborepo

Let’s break down what you gain (and lose) with each.

🌐 What Regular Repos / Basic Monorepos Look Like

With multiple separate repos (or a raw monorepo without tooling), each package manages its own:

Build scripts
Testing
Dependency installs
CI pipelines
Versioning

Pros

Simple mental model
Lower setup cost
Works for small teams / small projects
No new tooling required

Cons

Repeated installs (npm install everywhere)
Repeated builds
Harder to share common code
CI takes longer
Coordination pain when projects depend on each other

This setup tends to break down once people start reusing internal components or libraries.

⚡ What Turborepo Brings to the Table

Turborepo is a build system for JavaScript/TypeScript monorepos with features like:

✔ Caching — skip repeated builds/tests
✔ Parallel execution — run tasks across packages
✔ Remote cache (Vercel) — great for teams
✔ Pipeline orchestration — define dependencies (build → test → lint)
✔ Zero config for common setups (Next.js, React, etc.)

That means:

build becomes fast
CI stops wasting cycles doing repeated work
Local iteration improves a lot when switching branches

👨‍👩‍👧 Team & Scale — The Key Decision

Where Turborepo shines:

Multiple apps + shared UI libs
Long CI pipelines
Teams with 3+ engineers
Repeated tasks between packages
Next.js projects (native support is great)
Component libraries
Microfrontends / microservices

Example setups that benefit:

dashboard + marketing + shared-ui
backend + frontend + shared-types
API + worker + CLI + shared config

💥 Where Turborepo Is Overkill

This is the part people underestimate.

Turborepo is too heavy if:

You have just one app
No shared components/libs
Builds/tests are already fast
CI cost isn’t a pain point
Solo developer moving fast

Also overkill if:

You don’t plan for growth
You don’t need cross-repo orchestration
You don’t care about remote caching

Example scenario:

"React frontend + basic Node backend with no shared code"

You can run it as two repos or a single folder without tooling and life is fine.

🔧 Dev Productivity Angle

Criteria	Regular Repos	Turborepo
Setup Complexity	⭐ Easy	⚠️ Medium
Scaling	😬 Painful	⭐ Excellent
CI Time	Slow	Fast
Dev Experience	Basic	Polished
Learning Curve	Low	Low-Medium
Tooling Overhead	None	Some
Team Benefit	Low	High

📈 When It Starts Feeling Worth It

If you start hitting these symptoms:

Duplicate dependencies
“Why is CI so slow?”
“Build is taking forever”
Shared types between backend/frontend
Releasing packages becomes manual work

Then Turborepo feels like turning on a cheat code.

📝 Final Take

Use Turborepo if:

You care about DX + CI performance + shared workspace between multiple packages.

Skip it if:

You’re building solo, have a single app, or don’t feel coordination pain yet.

Tools should remove friction — not add ceremony.

Networking Mistakes That Cost Me 6 Months

sanjay kumar — Sat, 03 Jan 2026 07:31:11 +0000

What I Learned About Networking and Building Credibility (After Doing It Wrong)

For a long time, I believed that skills alone were enough.

If I built good things, learned fast, and shared my work, I thought opportunities and networks would naturally follow. So I joined communities, connected with people on LinkedIn, tried cold outreach, and kept posting what I was building.

What I got was a lot of connections — but very little real network.

These are the most important things I learned from that experience.

1. Communities give connections, not networks

I joined many communities hoping to “network”.

Most of them turned out to be:

memes
generic posts
shallow discussions

I realized something important:

A community is only valuable if you can contribute to it.

Without contribution:

there’s no trust
no memory
no real relationship

Communities create connections by default.
They only become networks when you add value.

That’s why smaller, focused spaces — like open-source projects or builder-driven ecosystems — are far more useful than large generic communities.

2. Showing skills is not the same as adding value

I used to showcase:

what I built
what I learned
what I was capable of

But people don’t really care about what you’ve done.

They care about:

what problem you can help them solve
what pain you can reduce right now

Skills are potential value.
Solving someone’s real problem is actual value.

Once I understood this, my approach changed completely.

3. Cold outreach rarely works (especially early)

I tried cold emails and DMs where I explained my skills and experience.

Very few replies.

Not because people were rude — but because:

founders already have networks
senior engineers are busy
generic outreach is just noise

Cold outreach only works when:

the problem is extremely specific
timing is perfect
value is obvious immediately

That combination is rare.

4. Random commenting is forgettable

I also tried commenting everywhere to “stay visible”.

That didn’t work either.

What does work:

extending someone’s idea
adding a missing perspective
sharing a concrete insight from your own experience

If a comment doesn’t add value, it’s forgotten instantly.

Networks are built on recall, not reach.

5. You must know where you can provide value

Another mistake I made was trying to be everywhere.

Now I ask:

What do I actually know well?
Who does this help?
Where does this matter?

Networking becomes easier when you stop asking:

“How do I connect with people?”

and start asking:

“Where can I be genuinely useful?”

6. Platforms matter more than we think

Different platforms reward different kinds of content.

For example:

dev.to works best for clear, accessible technical ideas
very complex or deep work often gets less reach
YouTube favors entertainment and storytelling
LinkedIn favors narrative and social proof

I once shared work that was too complex for the platform and got almost no engagement.

It wasn’t bad work — it was platform mismatch.

Understanding the audience matters as much as the content.

7. Think from the founder’s perspective

One mental shift helped me a lot:

If I were a founder with credibility and a strong network, how would I view a random inbound message?

Most founders:

already know talented people
don’t urgently need help
optimize for signal, not curiosity

So instead of asking for attention, it’s far more effective to:

contribute to their product
improve documentation
fix a bug
extend their ideas publicly

That’s how cold connections slowly become warm.

Final thought

What I learned is simple, but not easy:

Networking isn’t about being skilled.
It’s about being useful — in the right context, at the right time.

I’m still learning this, but understanding the difference between connections and networks completely changed how I approach building credibility.

I Built Real-Time Voice AI in 3 Days (YC Interview)

sanjay kumar — Tue, 23 Dec 2025 04:03:10 +0000

Freya Voice AI Agent Console (Forward-Deployed Engineering Deep Dive)

As part of a YC-style technical assessment, I built Freya Voice AI Agent Console — a production-grade, real-time voice-to-voice AI system focused on low latency, clean architecture, and real-world constraints.

The goal wasn’t just to “make it work”, but to design something that feels forward-deployable: a system you could realistically ship, iterate on, and operate.

👉 Source code:
https://github.com/05sanjaykumar/Freya-Voice-YC25-Assessment

🎯 What Was Built

Freya is a real-time conversational voice AI that supports:

Bidirectional voice-to-voice conversations
Sub-200ms latency streaming
Prompt versioning via a web console
Session metrics and analytics
Fully Dockerized deployment

The project was built in 3 days, prioritizing voice pipelines over chat UIs, similar to real YC engineering evaluations.

🔊 Voice AI Pipeline (End-to-End)

The core pipeline looks like this:

User speaks → audio streamed via WebRTC
Speech-to-Text (STT) → Groq Whisper
LLM reasoning → Groq LLaMA-3.1-8B
Text-to-Speech (TTS) → Cartesia Sonic
Audio streamed back to the user in real time

To improve accuracy and latency:

Silero VAD detects speech boundaries
Audio chunks are processed incrementally
Responses are streamed, not buffered

This architecture mirrors how modern voice assistants are built in production.

🏗️ System Architecture

[ Browser Client ]
     ↓ WebRTC (LiveKit)
[ Next.js Frontend ]
     ↓ HTTP / WS
[ Python Voice Agent ]
     ↓
[ Groq (STT + LLM) ] → [ Cartesia (TTS) ]

Why LiveKit?

LiveKit handles:

WebRTC negotiation
Low-latency audio routing
Session lifecycle management

This avoids re-implementing complex real-time networking logic — a key forward-deployed engineering decision.

🧰 Tech Stack

Frontend

Next.js 15 (App Router)
TypeScript
Tailwind CSS
LiveKit Client SDK

Backend

Python 3.11
LiveKit Agents
Groq APIs (Whisper + LLaMA)
Cartesia TTS
Silero VAD

Infrastructure

Docker & Docker Compose
Multi-service orchestration
Health checks & env-based config

🧠 Prompt Management & Observability

Freya includes a lightweight prompt management system:

Create & version prompts
Edit prompts without restarting sessions
Track which prompt version was used per conversation

Session metrics include:

Duration
Latency
Active connections

These are essential when deploying AI agents into real customer environments.

🚀 Running Locally

git clone https://github.com/05sanjaykumar/Freya-Voice-YC25-Assessment
cd Freya-Voice-YC25-Assessment
cp .env.example .env
docker compose up --build

Visit: http://localhost:3000

You’ll need:

LiveKit credentials
Groq API key
Cartesia API key

🧩 Engineering Tradeoffs (YC-Style)

Some deliberate decisions:

Voice-first over chat: harder, but closer to real-world systems
In-memory storage: faster iteration, easier debugging
Service boundaries early: frontend, agent, and infra separated from day one
Docker everywhere: reproducibility > local hacks

These choices optimize for clarity, deployability, and iteration speed — not just demos.

🛣️ What I’d Build Next

If this were going to production:

PostgreSQL + Redis for state
Horizontal agent scaling
CI/CD (GitHub Actions)
OpenTelemetry for tracing
Session replay & recording
Rate limiting & abuse prevention

🎤 Final Thoughts

This project was less about “AI magic” and more about engineering judgment:
latency, reliability, real-time systems, and clean abstractions.

If you’re preparing for YC-style interviews, Forward Deployed Engineer roles, or real-time AI systems, I hope this serves as a practical reference.

Happy building 🚀

Extract GitHub Folders in 1 Command (No Clone)

sanjay kumar — Fri, 04 Jul 2025 11:09:11 +0000

🚀 Solving GitHub Folder Extraction with Go — A CLI for Real-World Git Edge Cases

Cloning a full GitHub repo when you only need one folder or file is overkill — especially with monorepos.

I wanted a simple CLI tool that lets me extract just a folder from any GitHub repo. Sounds simple, right?

It’s not. GitHub’s structure, especially with branches that have slashes in their names, makes this problem deceptively tricky. Here's how I solved it — and why the hard part wasn’t syntax or boilerplate, but reasoning through ambiguity.

🧠 The Problem

Let’s say you have this URL:


[https://github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/http/plugins](https://github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/http/plugins)

You want just the src/http/plugins folder.
But fix/pgboss-on-error-callback is the branch name — and it has slashes in it.
So how do you distinguish the branch name from the folder path?

This is where traditional methods like git sparse-checkout break down unless you know the exact branch and folder manually.

🔧 My Solution: GitSlice CLI

I built GitSlice, a Go CLI tool that:

Accepts a GitHub folder or file URL
Parses and resolves the correct branch and path
Clones only the required data
Extracts it into your current directory

gitslice https://github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/http/plugins

🧪 The Hardest Part: Branch vs Path Resolution

GitHub doesn’t give you the branch and folder explicitly — just a single URL. So I had to build a resolver that intelligently distinguishes between them.

Here’s how I approached it:

🧠 Step-by-Step Path Resolution Logic

1. Clone the Repository (Sparse Mode):

GitSlice starts by shallow cloning the entire repo into a temporary folder (e.g., cloneTemp). This avoids full history and keeps things lightweight

2. Parse the GitHub URL into Parts:

postTree = ['fix', 'pgboss-on-error-callback', 'src', 'http', 'plugins']

3. Inspect the Local Folder After Clone:

After cloning, we list the folder structure at the root of the repo. This gives us the actual directories present at that commit.

4. Smart Matching to Infer the Real Path:

Now we iterate through postTree, trying different splits:

First, assume the first n parts of postTree could be the branch name.
The remaining parts are then assumed to be the path within the repo.

At each step, we check if the path exists on disk. If it does, we lock that in as the correct branch/path combo.

5. Example Matching:

github_url = github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/http/plugins

GitSlice tries: Branch = fix, Path = pgboss-on-error-callback/src/http/plugins → Not found Branch = fix/pgboss-on-error-callback, Path = src/http/plugins → ✅ Match

6. Handle Nested Branch Names Intelligently:

This means GitSlice doesn’t rely on hardcoded assumptions or magic string slicing. Instead, it lets the filesystem be the truth.

🧩 Step-by-Step Logic

1. Parse the post-`tree` part of the URL

From a URL like:

https://github.com/user/repo/tree/branch-name/src/plugins

Split it into:

postTree = [fix, pgboss-on-error-callback, src, http, plugins]

2. Clone the repo to a temp dir

git clone --filter=blob:none --no-checkout https://github.com/user/repo cloneTemp

3. Compare folder structure to detect real path

I implemented this logic in resolveBranchAndPath() in internal/clone/clone.go file:

func resolveBranchAndPath(clonePath string, postTree []string) (string, string, error) {
    for i := 1; i < len(postTree); i++ {
        branchCandidate := postTree[:i]
        pathCandidate := postTree[i:]
        if len(pathCandidate) == 0 {
            continue
        }

        fullPath := filepath.Join(clonePath, filepath.Join(pathCandidate...))
        if info, err := os.Stat(fullPath); err == nil && info.IsDir() {
            return strings.Join(branchCandidate, "/"), strings.Join(pathCandidate, "/"), nil
        }
    }
    return "", "", fmt.Errorf("❌ Could not resolve branch/path. Check if URL or folders exist")
}

This method tries all possible splits of the post-tree part and validates whether the resulting folder exists in the cloned repo. It worked across many real-world repos with complex branch names.

🐍 Pseudocode (Pythonic Version)

Just for clarity, here's the rough equivalent logic in pseudocode:

github_url = "github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/http/plugins"
local_after_clone = 'storage/src/http/plugins'

# Split the URL and detect where 'tree' starts
result = github_url.split('/')
for i, x in enumerate(result):
    if x == 'tree':
        base_url = result[:i]
        post_tree = result[i+1:]
        break

# Now try matching folder structure
for j in range(len(post_tree)):
    if post_tree[j] == local_after_clone.split('/')[0]:
        branch_candidate = post_tree[:j]
        path_candidate = post_tree[j:]
        break

🧠 Why I Used AI (And Why That’s Fine)

Yes, I used AI to assist with some parts — like refreshing Go syntax or generating boilerplate for CLI args. But the real problem-solving — like figuring out branch-path ambiguity, recursive folder matching, and edge case debugging — was 100% me.

AI didn’t know how to solve this. It only accelerated parts of the process — like a calculator helps with math, but doesn’t understand the problem.

📦 Installation

With Go:

go install github.com/05sanjaykumar/gitslice@latest

Or clone and build:

git clone https://github.com/05sanjaykumar/gitslice
cd gitslice
go build -o gitslice main.go

🛠️ Usage

gitslice <github-folder-or-file-url>

Examples:

gitslice https://github.com/supabase/storage/tree/fix/pgboss-on-error-callback/src/auth
gitslice https://github.com/vercel/next.js/tree/canary/packages/next
gitslice https://github.com/05sanjaykumar/Flappy-Bird-OpenCV/blob/main/assets/background-day.png

🆚 GitSlice vs Manual Git Steps

With GitSlice:

gitslice https://github.com/user/repo/tree/branch/folder

Manually:

git clone --filter=blob:none --sparse https://github.com/user/repo
cd repo
git sparse-checkout init --cone
git sparse-checkout set folder
git checkout branch
cp -r folder ../
cd ..
rm -rf repo

GitSlice reduces 7 steps to 1 — and eliminates the guesswork.

💬 Final Thoughts

This project taught me how even basic-sounding ideas hide a surprising amount of technical complexity. Let me know your thoughts or how you'd approach it differently!

🔗 GitSlice GitHub Repo

Made By Sanjay Kumar

How I Built a URL Shortener Using Node.js, Redis, Docker & Deployed It on Render

sanjay kumar — Sat, 24 May 2025 10:30:50 +0000

👋 A Quick Backstory
Hey everyone, I’m Sanjay — a self-taught dev who loves building from scratch and learning by doing. I recently went deep into DevOps and containerization, and this URL shortener project was my way of exploring Redis, Docker, and cloud deployment — all in one shot.

This project was never about just shortening URLs. For me, it was about:

Learning how to structure a scalable backend 🧱

Working with Redis as a primary data store 🧠

Deploying real-world projects with Docker + Render 🚀

It’s simple on the surface, but I learned a ton building this. Here's the breakdown 👇

🔗 URL Shortener – Node.js, Redis & Docker

A full-stack, production-grade URL shortening service built with Node.js, Express, Redis, and Docker — complete with a RESTful API, unit tests, containerization, and cloud deployment on Render.

🌍 Live Demo

🟢 Deployed on Render
Frontend: Static HTML + JS
Backend: Node.js + Redis
Dockerized with Dockerfile and nginx (for local use)

🧰 Tech Stack

Frontend: HTML, JavaScript (Vanilla)
Backend: Node.js + Express
Database: Redis (for storing shortened URLs)
Testing: Jest
DevOps: Docker, Render, NGINX
(Experimental): Rate Limiting, GitHub Actions (CI)
- Docker & docker-compose (for local development)
- Render (for cloud deployment)
- NGINX (proxy for local routing)

📁 Project Structure

05sanjaykumar-url-shortern/
├── public/             # Static frontend (HTML + JS)
├── src/
│   ├── app.js          # Main app setup
│   ├── controllers/    # Shorten & redirect logic
│   ├── middleware/     # Rate limiting (dummy)
│   ├── routes/         # API endpoints
│   └── services/       # Redis logic + URL generation
├── test/               # Unit tests + Redis mocks
├── nginx/              # NGINX config (for local Docker)
├── .github/workflows/  # CI pipeline (placeholder)
├── Dockerfile + docker-compose.yml
├── server.js
└── .env-example

✅ Features

🔗 Shortens long URLs to unique 6-character codes
🚀 Redirects to original URLs
🧠 Stores URL mappings in Redis
🧪 Unit-tested with mocked Redis interactions
🛠️ Includes a basic demo rate limiter (not production-grade)
🐳 Local Docker support
🌐 Fully deployed backend + frontend on Render

⚙️ Running Locally

Option 1: Docker (recommended)

docker-compose up

Then open: localhost

(OR)

Option 2: Manual

git checkout render-deploy
npm install
redis-server
npm start

Then open: http://localhost:3000

🧪 Run Tests

npm test

Tests include mocked Redis functionality for isolated unit testing.

📦 Deployment (Render)

The app is deployed using Render:

Backend connects to Redis
Frontend served statically (via nginx or Render)
Base URL is dynamically handled in production

📌 Learnings

📦 Designed modular Express backend (routes, controllers, services)
🧪 Wrote unit tests with Redis mocks
🐳 Containerized with Docker + Docker Compose
🚀 Deployed on Render (frontend + backend)
🛠️ Explored how rate limiting works in Express (demo-only)
🌱 Gained deeper insight into app structure, devops, and deployment

⚠️ Note: The rate limiter is a basic, demonstration-only middleware. For real-world production use, consider packages like express-rate-limit or Redis-backed implementations.

🙌 Author

Sanjay Kumar — Lifelong learner, and builder of things.
GitHub Repo

Forem: sanjay kumar

Turborepo vs Regular Monorepo: When It's Worth It (And When It's Not)

📦 Turborepo vs. Regular Repos: When It Helps — and When It’s Overkill

🌐 What Regular Repos / Basic Monorepos Look Like

⚡ What Turborepo Brings to the Table

👨‍👩‍👧 Team & Scale — The Key Decision

💥 Where Turborepo Is Overkill

🔧 Dev Productivity Angle

📈 When It Starts Feeling Worth It

📝 Final Take

Networking Mistakes That Cost Me 6 Months

What I Learned About Networking and Building Credibility (After Doing It Wrong)

1. Communities give connections, not networks

2. Showing skills is not the same as adding value

3. Cold outreach rarely works (especially early)

4. Random commenting is forgettable

5. You must know where you can provide value

6. Platforms matter more than we think

7. Think from the founder’s perspective

Final thought

I Built Real-Time Voice AI in 3 Days (YC Interview)

Freya Voice AI Agent Console (Forward-Deployed Engineering Deep Dive)

🎯 What Was Built

🔊 Voice AI Pipeline (End-to-End)

🏗️ System Architecture

Why LiveKit?

🧰 Tech Stack

Frontend

Backend

Infrastructure

🧠 Prompt Management & Observability

🚀 Running Locally

🧩 Engineering Tradeoffs (YC-Style)

🛣️ What I’d Build Next

🎤 Final Thoughts

Extract GitHub Folders in 1 Command (No Clone)

🚀 Solving GitHub Folder Extraction with Go — A CLI for Real-World Git Edge Cases

🧠 The Problem

🔧 My Solution: GitSlice CLI

🧪 The Hardest Part: Branch vs Path Resolution

🧠 Step-by-Step Path Resolution Logic

1. Clone the Repository (Sparse Mode):

2. Parse the GitHub URL into Parts:

3. Inspect the Local Folder After Clone:

4. Smart Matching to Infer the Real Path:

5. Example Matching:

6. Handle Nested Branch Names Intelligently:

🧩 Step-by-Step Logic

1. Parse the post-tree part of the URL

2. Clone the repo to a temp dir

3. Compare folder structure to detect real path

🐍 Pseudocode (Pythonic Version)

🧠 Why I Used AI (And Why That’s Fine)

📦 Installation

🛠️ Usage

🆚 GitSlice vs Manual Git Steps

💬 Final Thoughts

Made By Sanjay Kumar

How I Built a URL Shortener Using Node.js, Redis, Docker & Deployed It on Render

🔗 URL Shortener – Node.js, Redis & Docker

🌍 Live Demo

🧰 Tech Stack

📁 Project Structure

✅ Features

⚙️ Running Locally

Option 1: Docker (recommended)

Option 2: Manual

🧪 Run Tests

📦 Deployment (Render)

📌 Learnings

🙌 Author

1. Parse the post-`tree` part of the URL