DEV Community: Stephen Akugbe

Stop writing custom scrapers. We built an AI app that generates local lead lists in 30 seconds.

Stephen Akugbe — Wed, 04 Mar 2026 21:05:02 +0000

Every developer has fallen for the "quick script" trap at least once.

You need a list of local businesses for a project, a client, or your own sales outreach. You think to yourself, "I'll just write a quick script to pull this data. It'll take 20 minutes." Three days later, you're knee-deep in proxy rotations, fighting rate limits, getting blocked by CAPTCHAs, and trying to figure out why the website's DOM completely changed overnight. It’s soul-crushing work.

A few months ago, my co-founder and I finally got completely sick of this cycle. We realized that nobody actually wants to maintain scrapers or copy-paste from Google Maps until their eyes bleed. You just want the damn data so you can get to work.

So, we put our heads down and built DensOps—an AI-powered lead generation app.

How it actually works ⚙️

The UX is entirely AI-driven. You literally just search in plain English, like "4-star plumbers in Chicago," and the AI figures out exactly what you need. In about 30 seconds, DensOps hands you a clean, export-ready CSV complete with validated emails, phone numbers, and social links. No proxies, no coding, no bullshit.

But as developers, you know that doing that reliably at scale takes more than just a basic API wrapper. We had to build a serious engine to handle the messy data extraction in the background:

The Core API (NestJS & TypeScript): We use NestJS to handle all the standard backend operations—user routing, state management, and API endpoints. The strict typing of TypeScript keeps our core logic solid and maintainable.
The Enrichment Engine (Python & FastAPI): For the heavy lifting—the actual data extraction, standardization, and AI enrichment—we spun up a dedicated microservice using Python and FastAPI. Python’s data ecosystem is unmatched for this kind of work, and FastAPI ensures the service stays lightning-fast and highly concurrent.

It’s been a massive challenge getting these two services to communicate seamlessly while keeping latency low. But we finally nailed it.

The Ask: We just launched on Product Hunt yesterday 🚀

I’ll be honest—it’s terrifying putting something you’ve poured your soul into out into the public. You always wonder if people will actually care. But we’re incredibly proud of what we’ve built, and we really believe this will save devs and sales teams hundreds of hours.

Want to test it out? We set it up so that new sign-ups get one free search. Go run your hardest query, see how fast the backend actually processes it, and look at the data quality yourself. You can try it out at DensOps.com.

If you like what we've built:
It would mean the absolute world to us if you checked out our launch today on Product Hunt. Drop a comment, tell us what we got right, tell us what sucks about the UX, and if you think it's a great tool, your support and upvotes would mean everything to us right now.

👉 Support DensOps on Product Hunt here

Let me know what you think of the app in the comments! I'm open to answering any questions you have about the tool or the stack.

Thanks for reading, and back to the monitors.

My 2025 as a Software Engineer: Building Less, Understanding More

Stephen Akugbe — Wed, 31 Dec 2025 20:13:50 +0000

2025 was not a loud year for me.
It was a builder year and a thinking year.

I spent most of the year working across both backend and frontend systems. On the backend, I worked with Node, TypeScript, PHP, Laravel, Express, NestJS, PostgreSQL, MySQL, MongoDB, AWS, GCP and Docker. On the frontend, I worked with React, Next.js, Vue, and modern TypeScript workflows. These were real production systems with real constraints and tradeoffs.

But this year was not just about building. It was about understanding.
I slowed down and started thinking more deeply about architecture, scale, abstractions, and long term impact. I became more intentional about decisions and less interested in clever solutions that only worked in the short term.
Clarity started to matter more than speed.

Alongside my technical growth, I spent the year learning French and living within a new culture. Learning a new language forces you to listen more than you speak. It changes how you process ideas and express intent. I realized how closely this mirrors software engineering. You cannot express a good solution until you truly understand the problem.

Because of this shift, I cared less about shipping fast and more about meaning.
I asked better questions. What problem does this system actually solve. How will this decision age. What happens when this codebase grows.

I worked across different domains including elearning platforms, gaming APIs, and AI products. Each domain reinforced the same lesson. Depth beats speed.
Systems tend to fail long before code does.

I also explored AI thoughtfully. I looked into RAG (Retrieval Augmented Generation), LLM powered tools, and practical SaaS ideas. Instead of chasing hype, I focused on what could be built lean and sustainably.

On the product side, I planned and built real things. I co founded a product and currently close to finishing the MVP. I planned and built a social media post generation tool using NestJS and PostgreSQL with a Nextjs frontend.

Giving back remained important to me, I’m mentoring someone to become a great backend dev, I published an npm package, worked on open source repositories, and wrote developer articles. My goal was to document real fixes and real lessons, not recycled advice.

2025 taught me that growth can be quiet.
It comes from thinking deeply, learning continuously, and building with intent.

Going into 2026, my focus is clear. Fewer projects, deeper execution, and visible impact.

Why NestJS Hot Reload Does Not Work in Docker and How to Fix It Properly

Stephen Akugbe — Mon, 22 Dec 2025 21:51:00 +0000

If you are running NestJS inside Docker and your code changes are not reflecting, you are not alone. This is one of the most common pain points developers hit when combining NestJS, Docker, and macOS or Windows.

You save a file.
Nothing happens.
You rebuild the container.
Still confused.

Sidenote: I have actually fixed this exact problem before on another project. But when I hit it again on a new NestJS setup, I realized I could not remember all the details. That was the moment I decided to document it properly this time.

At some point, you install webpack because someone on the internet said it fixes the issue.

This article explains what is really going on, why Docker behaves this way, when webpack is actually needed, and what the correct setup looks like for NestJS development.

The core misunderstanding

Docker does not watch your files.

Docker only sees what exists inside the container. Whether changes reflect or not depends entirely on how files get into the container and how NestJS is running.

There are two very different worlds that often get mixed up.

Development mode
Production mode

If you confuse the two, hot reload will never work.

How NestJS hot reload works without Docker

When you run NestJS locally using

npm run start:dev

The Nest CLI uses a file watcher. When a file changes, the process restarts automatically.

No Webpack is involved here.
No HMR.
Just process a restart.

This works because your filesystem events are available directly to Node.

What changes when you introduce Docker

Once NestJS runs inside a container, file watching depends on three things.

How files get into the container
How NestJS is started
Whether filesystem events propagate correctly

If any of these is wrong, hot reload breaks.

The only setup that works reliably for development

For NestJS changes to reflect instantly inside Docker, all of the following must be true.

Your source code is mounted into the container using volumes
NestJS runs in watch mode using start dev
File watching works inside Docker

If even one is missing, you will be rebuilding images unnecessarily.

Volumes are non-negotiable in development

If your Dockerfile copies files like this

COPY . .

Then your container has a snapshot of your code. Docker has no idea when you edit files locally.

That setup is correct for production but wrong for development.

In development, your compose file must mount the project into the container.

Example conceptually:

Local files
Shared into the container
Changes appear instantly

This is exactly what your compose file already does.

.:/usr/src/app

That line is the backbone of hot reload.

Why node_modules must be excluded

This line is subtle but important.

/usr/src/app/node_modules

It prevents your local node_modules from overwriting the container dependencies. Without it, you get native module issues and random crashes.

This is a best practice, and you got it right.

start dev is not optional

NestJS will only watch files if you explicitly run it in watch mode.

This means your command must be

npm run start:dev

and not

node dist/main.js
or
nest start

The moment you run compiled JavaScript, hot reload is gone. That is expected behavior.

The macOS and Windows file watching problem

Even with volumes and start dev, many developers still see no reload.

This is not a NestJS bug.

On macOS and Windows, Docker Desktop runs Linux containers inside a virtual machine. Native filesystem events often do not propagate correctly into the container.

That is why NestJS does not detect changes.

The fix is polling.

These environment variables force Node-based watchers to actively check for changes instead of relying on filesystem events.

CHOKIDAR_USEPOLLING=true WATCHPACK_POLLING=true

This is not a hack. It is a known workaround and widely used.

Once enabled, NestJS reliably restarts when files change.

The webpack confusion explained

This is where most people go wrong.

NestJS supports two different reload strategies.

Process restart using the Nest CLI watcher
Hot Module Replacement using webpack

Webpack is only required for HMR.

If you never enabled HMR, you don't need Webpack at all.

So why do people install it?

Because they accidentally enable HMR.

If you see any of these, Webpack becomes mandatory.

module.hot in main.ts
webpack: true in nest cli config
Custom HMR setup

At that point, NestJS expects Webpack and Webpack CLI to exist.

Many developers install Webpack, thinking it fixes Docker reload issues, when in reality, polling was the missing piece.

When webpack actually makes sense

Webpack HMR can be useful if:

Your application startup time is slow
You want instant reload without restarting the process
You know you enabled HMR intentionally

But it adds complexity and is not required for most backend APIs.

For many projects, a simple restart on change is stable and good enough.

Development versus production mental model

This simple rule will save you hours.

In development:

Use volumes
Run start dev
Enable polling
Never rebuild

In production:

Do not use volumes
Copy files during build
Run compiled JavaScript
Rebuild on every change

If you mix these two worlds, things break.

Final thoughts:

Docker is not broken.
NestJS is not broken.
Hot reload is not magic.

Once you understand how files enter the container and how NestJS watches them, everything becomes predictable.

If you ever find yourself rebuilding Docker images just to see a console log update, something in your setup is wrong.

And if you installed Webpack just to make file watching work, you probably did not need it.

If this article saved you time, chances are it will save someone else hours of frustration too.

Why You Should Care About Pre-Commit Hooks (and How Husky Makes It Easier)

Stephen Akugbe — Sat, 01 Nov 2025 08:52:36 +0000

I thought about writing this because pre-commit checks are one of the most overlooked parts of the development process. Many developers push code straight to GitHub or GitLab without realizing that a simple setup could save them countless hours of debugging and keep their projects clean and consistent.

So, let’s talk about pre-commit hooks and how Husky helps make them easy to use.

What Are Pre-Commit Hooks?

Pre-commit hooks are scripts that run automatically before a Git commit is finalized.

They allow you to run checks or commands that ensure your code meets certain standards before it’s saved into the repository.

Think of them as automated gatekeepers for your commits.

For example, a pre-commit hook can:

Run your tests and stop the commit if something fails
Lint and format your code automatically
Enforce commit message standards
Prevent large or sensitive files from being committed

The main goal is simple: catch issues early and maintain consistency across your team.

The Problem With Manual Git Hooks

Git actually supports hooks natively. You can find them in the .git/hooks folder of any repository.

However, these hooks aren’t shared when you clone or pull a repo because they’re stored locally.

That means every developer has to set them up manually — and that’s both inconvenient and error-prone.

This is where Husky comes in.

Enter Husky

Husky is a tool that makes it easy to manage and share Git hooks within your project.

Instead of manually editing .git/hooks, Husky lets you configure hooks right inside your repository so everyone benefits automatically.

With Husky, you can automate tasks like linting, formatting, or running tests before every commit or push — all version-controlled and consistent for every developer.

Setting Up Husky

Here’s how you can set it up quickly:

# Step 1: Install Husky
npm install husky --save-dev

# Step 2: Enable Git hooks
npx husky install

# Step 3: Add a pre-commit hook
npx husky add .husky/pre-commit "npm test"

Now, every time you commit, your tests will run automatically.
If they fail, the commit won’t go through, protecting your main branch from broken code.

You can also use tools like ESLint, Prettier, or lint-staged to format and lint your code before commits.

For example:
npx husky add .husky/pre-commit "npx lint-staged"

And in your package.json:

{
  "lint-staged": {
    "*.{js,ts,jsx,tsx}": ["eslint --fix", "prettier --write"]
  }
}

This ensures only the staged files are linted and formatted, making the process faster.
Other Pre-Commit Tools You Should Know

Different languages and ecosystems have their own pre-commit tools. Here are a few popular ones:

JavaScript/TypeScript: Husky, Lefthook, Yorkie
Python: pre-commit
Ruby: Overcommit
Go: pre-commit-go
Java: Spotless
C#/.NET: GitHooks.NET

No matter what stack you’re working with, the idea remains the same: ensure quality before the code lands in your repo.

Why I Think This Matters

Developers often focus on writing features and fixing bugs, but forget to automate the boring parts that ensure quality.
Pre-commit hooks are one of those simple setups that can dramatically improve your workflow and team collaboration.

Husky, in particular, makes it effortless for JavaScript and TypeScript projects to keep their codebase clean, consistent, and ready for production, every single commit.

So if you’ve never used pre-commit hooks before, now’s a good time to start.

Never Miss a Cloud Run Error: A Guide to Comprehensive GCP Alerting

Stephen Akugbe — Mon, 25 Aug 2025 17:13:06 +0000

Deploying an application to Google Cloud Run is an exhilarating experience. The serverless magic, the automatic scaling, the elegant containerization—it all works seamlessly. But what happens when things go wrong? When your NestJS API throws an unhandled exception, or your Next.js app starts returning 5xx errors?

Without a proper alerting system, you're flying blind. You'll most likely not be aware of the problem until a user reports it. In this post, We’ll walk through the definitive guide to setting up a comprehensive, "catch-all" alerting system for all your Cloud Run applications using Google's built-in tools: Cloud Logging and Cloud Monitoring.

We'll cover the right way to query logs, how to create a single, unified metric for all errors, and how to configure an email alert that notifies you the second a problem occurs.

Step 1: The Core Principle: From Logs to Alerts

The foundation of our strategy is that both of your applications (NestJS and Next.js) automatically write all their standard output and errors to Cloud Logging. Anything written to stderr is automatically given a severity: ERROR label. We'll leverage this to build our alerting system.

Our goal is to create a single Logs-based Metric that acts as a central counter for every error from every Cloud Run service in your project. Once we have that metric, we can set an alert policy that triggers on the very first error.

Step 2: Creating a Unified Logs-Based Metric

Instead of creating separate alerts for each service, we'll create one metric to rule them all.

Navigate to Logs-based Metrics: In the Google Cloud Console, find and navigate to Cloud Monitoring and select Logs-based Metrics from the left-hand menu.
Create a New Metric: Click the "Create Metric" button at the top of the page.
Configure the Metric:
- Metric Type: Select Counter. This will count the number of matching log entries.
- Name: Give it a clear name like cloud-run-errors.
- Description: Add a helpful description: "A counter for all log entries with a severity of ERROR or higher from all Cloud Run services."
- Log Filter: This is the most crucial part. Paste this query into the "Build filter" box. This query finds all logs with an ERROR severity from any Cloud Run revision in your project.
```
resource.type="cloud_run_revision" AND severity>=ERROR
```
Finalize: Click "Create Metric". The metric is now created but won't be visible in the alerting policy selector until it receives its first data point.

Step 3: Setting Up a "Zero-Tolerance" Alerting Policy

Now we'll create the policy that sends you a notification as soon as a new error is logged.

Create an Alerting Policy: Go to Cloud Monitoring > Alerting > Create Policy.
Select Your Metric: In the "Select a metric" dialog, search for the name of the metric you just created: cloud-run-all-errors.
Note: If it doesn't appear, you need to wait for a new error to
be logged in your service. The metric won't be searchable until
it has received its first data point.
Configure the Trigger:
- Condition: Any time series violates a value threshold
- Threshold: Is above
- Value: 0
- For: 1 minute (This ensures you get an alert as soon as the first error occurs, and the metric count goes above zero).
Add Your Notification Channel: If you haven't already, you need to create a notification channel (e.g., your email address) in Alerting > Edit notification channels.
Select your email channel to receive notifications.
Finalize the Alert:
- Give the policy a descriptive name, like "Cloud Run: First Error Detected."
- In the Documentation section, add a helpful message. This is essential, as it will be included in the email. It should tell you where to go to find the error. A perfect addition is a link to the Logs Explorer with a pre-filled query:

Troubleshoot this issue by checking the logs:

https://console.cloud.google.com/logs/query;query=resource.type%3D"cloud_run_revision"%20AND%20severity%3E%3DERROR;timeRange=1h

Finally, click "Create Policy" and you're all set!

By following these steps, you've established a robust, centralized alerting system for your Cloud Run environment. You've moved beyond reactive troubleshooting and can now proactively respond to issues the moment they happen. This "set it and forget it" approach not only gives you peace of mind but is a critical step in building reliable and scalable cloud-native applications.

Efficiently Migrating Data Between PostgreSQL Databases: A Practical Guide

Stephen Akugbe — Sun, 17 Aug 2025 22:01:52 +0000

Migrating or syncing data between PostgreSQL databases is a common task for developers. Whether consolidating user data, archiving old records, or migrating production data to a reporting database, having a reliable and simple method can save hours of headaches.

PostgreSQL’s dblink extension makes this process straightforward, allowing you to query one database from another as if the two were connected tables.

Before using dblink, you need to make sure the extension is created in your target database:

CREATE EXTENSION IF NOT EXISTS dblink;

This only needs to be done once per database. After that, you can safely use dblink to query other PostgreSQL databases.

Example Scenario

Imagine you have:

Source database: user_data_archive
Target database: user_data_main
Target table: users

The users table has unique constraints on:

username
email

The goal is to copy users from the archive to the main database without violating these constraints.

Using dblink to Move Data

Here’s a simple example:

INSERT INTO users (username, email, created_at, updated_at)
SELECT DISTINCT
    username,
    lower(email) AS email,
    NOW() AS created_at,
    NOW() AS updated_at
FROM dblink(
    'dbname=user_data_archive user=app_user password=securepass',
    'SELECT username, email FROM archived_users'
) AS t(username text, email text)
ON CONFLICT DO NOTHING;

How This Works:

dblink allows the target database (user_data_main) to query the source (user_data_archive) directly.

DISTINCT removes duplicate rows from the incoming data.

ON CONFLICT DO NOTHING ensures that unique constraints on the target table (like unique usernames or emails) do not cause the query to fail.

This keeps the insert process safe while letting you move large amounts of data efficiently.

Why Use This Approach?

Simple setup: No need to dump and restore SQL files manually.
Flexible: You can filter, transform, or normalize data as part of the select.
Reliable: Works even when the source and target databases live on the same server or different servers.

Practical Use Cases:

Migrating users, products, or content from a legacy database to a new system.
Populating a reporting or analytics database from production tables.
Syncing staging and production data safely during testing.

dblink is a powerful tool for querying one PostgreSQL database from another.

Combining DISTINCT and ON CONFLICT DO NOTHING allows you to safely insert data without worrying about violating unique constraints.

This approach keeps your workflow clean, efficient, and maintainable, especially for large tables or ongoing migrations.

Fixing Global npm Install Permissions on macOS

Stephen Akugbe — Sat, 05 Jul 2025 04:38:49 +0000

> PS: This is also a note to myself in case I need it again in future

I recently switched to macOS and tried installing some global npm packages like pnpm using:

npm install -g pnpm

But I got a permissions error saying it couldn't create a folder in /usr/local/lib/.... This happens because macOS doesn't allow normal users to write to that system directory by default.

Here’s how I fixed it:

Step 1: Create a folder to store global npm packages

mkdir ~/.npm-global

Why: This creates a new directory in your home folder where you’ll install global npm packages safely, without needing admin rights.

Step 2: Tell npm to use that folder

npm config set prefix '~/.npm-global'

Why: This changes npm’s settings so it knows to install global packages into the new folder you just created instead of the system one.

Step 3: Add that folder to your system PATH

Open your terminal and run:

nano ~/.zshrc

Then add this line at the bottom of the file:

export PATH="$HOME/.npm-global/bin:$PATH"

Why: This tells your system where to find the npm packages you install globally, so you can run them like any other command (e.g., pnpm or eslint).

Step 4: Apply the changes

source ~/.zshrc

Why: This reloads your terminal settings so the PATH change takes effect immediately.

Step 5: Install the global package again

npm install -g pnpm

Why: Now that everything is set up, this should install without any permission error.

Step 6: Verify it works

pnpm -v

Why: This checks if pnpm was installed correctly and is available to run.

What If You Installed pnpm But It Still Says "command not found"?
After installing pnpm, I ran this in my project:

pnpm install

But the terminal said:

zsh: command not found: pnpm

That means macOS can’t find the pnpm command yet. Here’s how I fixed it:

Step A: Check where pnpm was installed

npm config get prefix

If it shows something like /Users//.npm-global, then run:

ls ~/.npm-global/bin

If pnpm is listed, we just need to make sure the terminal can see it.

Step B: Add it to your PATH (if not already done)

Open your terminal config again:

nano ~/.zshrc

Make sure this line exists at the bottom:

export PATH="$HOME/.npm-global/bin:$PATH"

Then save and close the file.

Step C: Reload your terminal settings

source ~/.zshrc

Now try:

pnpm -v

If it works, then run pnpm install in your project folder again. Everything should now work smoothly.

Introducing Postimy: Your Personal Content Assistant for Social Media

Stephen Akugbe — Tue, 10 Jun 2025 21:05:09 +0000

Hello, I’m excited to finally share what I’ve been working on: Postimy.

Postimy is your virtual assistant for all things social media. It helps you generate posts that actually sound like you, learning your tone, voice, and style over time. Whether you're trying to stay consistent on LinkedIn or Twitter, schedule posts across platforms, or brainstorm content ideas, Postimy is here to make it easier.

You can join the waitlist here if you want to try it early.

Why I Started Postimy

I’ve always struggled with the consistency part of social media. I have ideas, I know what I want to say, but actually sitting down to write content every few days? That was always the problem.

Then it hit me! What if I could automate the content creation process but still make it feel authentic?

There are already tons of AI writing tools out there, but most of them generate stuff that feels... generic... They don't sound like you. They don't evolve with you. And most importantly, they don't help you build a personal brand in a meaningful way.

That’s what I’m aiming for with Postimy.

Who Is It For?

Postimy is built for:

Founders & indie hackers trying to build in public
Creatives and professionals growing their audience
Freelancers wanting to showcase expertise
Anyone who’s tired of figuring out what to post

Whether you're building a product, a personal brand, or just want to stay relevant on social, Postimy helps you write consistently, without sounding robotic or generic.

How I Started Using It (And What Happened)

Before turning this into a web app, I started with a simple CLI tool that used OpenAI to generate LinkedIn posts based on my background and industry. I’d just run a command, and out came a few post options tailored to my style.

To my surprise, they weren’t just “good enough”, they were actually getting me results. I started seeing more engagement, more connections, and even more DMs from potential recruiters, founders and some others peeking at my profile (thanks to LinkedIn's profile viewers section).

That’s when I knew I was onto something.

How It Works (Right Now)

Currently, Postimy has:

A Next.js frontend (for user interface, onboarding, dashboard)
An Express.js server (handling post generation, user data, auth)
Uses OpenAI’s API to generate posts based on user background and goals
Simple scheduling logic and a content calendar to help users stay consistent

The idea is to start lean but scalable enough to get value from day one, while setting the stage for personalization and smarter content generation.

What’s Next: Learning You

Here’s where it gets fun. I want Postimy to become more than a content generator... I want it to learn how you think.

Here’s a breakdown of what I’m working on:

Voice + Style Adaptation: As you generate more posts, Postimy starts recognizing your tone, sentence structure, emoji usage, word choices, even preferred themes, and uses that to make future posts sound more like you.
Smart Onboarding: You’ll be able to set tone preferences (casual, formal), emoji habits, platform focus, and more (still not so sure about other preferences) so Postimy gets your voice right from day one.
Content Memory (RAG): I’m planning to store generated posts as embeddings in a vector database (e.g., pgvector or Pinecone). When generating new content, the system retrieves similar past posts to make each one context-aware.
Custom ML Pipeline: Eventually, I’ll be spinning up a Python Docker microservice to handle more advanced ML tasks, like Hugging Face-based embedding, tone scoring, and maybe even fine-tuning on user data.
LangChain (Possibly, still unsure): For better chaining of user context → memory retrieval → structured prompt → post generation, I’m exploring LangChain as an orchestration tool — or building a custom version of it if needed.

All of this is to ensure Postimy grows with you, becoming more accurate, more personal, and more useful over time.

Want to Try It?

If you’re tired of staring at a blank text box trying to figure out what to say online, Postimy can help.

Join the waitlist to be part of the early access group.

Thanks for reading. If you’ve ever tried building your dev tools to solve your own problem, I’d love to hear your story.

Let’s build better tools for ourselves.

Mental RAM: Why You're Tired But Haven't Done Much

Stephen Akugbe — Fri, 30 May 2025 18:19:19 +0000

Understanding the invisible drain of cognitive load and how you can reclaim mental clarity as a dev.

Have you ever wrapped up your day feeling drained, yet your GitHub commits, PRs, or task tracker don't reflect much progress? You're not alone. What you're experiencing is likely a depletion of mental RAM, that limited pool of attention and cognitive energy we all rely on to work effectively.

What is Mental RAM?

Just like a machine, your brain has limited memory to juggle multiple tasks, decisions, and distractions. Developers, especially, burn through this "RAM" quickly:

Context-switching between different codebases
Keeping track of logic while debugging
Mentally holding todos or unsaved thoughts
Background concerns (meetings, Slack pings, personal stress)

These micro-loads add up fast.

Mental Load is Real Work

Even if you're not actively coding, you're processing, replaying a bug, planning the next sprint, reviewing edge cases. This cognitive multitasking wears you down like CPU cycles running on high without delivering real output.

It’s why you can be tired after a day of “not much,” and still feel like your brain's fried.

Why This Is a Problem for Developers

When your mental RAM is full, it leads to:

Reduced problem-solving capacity
Slow task switching
More errors and bugs
Decision fatigue (yes, even choosing between map and forEach)
Burnout over time

You can't optimize code with a laggy IDE. The same goes for your brain.

How to Free Up Mental Bandwidth

Here's how to reclaim clarity and energy:

1. Write It Down, Don’t Hold It

Use a personal notepad, digital app (like Notion, Obsidian), or even your notes app on your device. Get those mental tabs out of your head.

“Your brain is for having ideas, not holding them.” – David Allen

2. Reduce Context Switching

Batch similar tasks. Avoid reviewing a PR while debugging an unrelated issue. If possible, block notifications during deep work.

3. Do a Brain Dump Each Morning

Before coding, jot down what's in your head—tasks, worries, ideas. It clears the cache.

4. Close Open Loops

An open loop is anything that demands mental attention (e.g., unanswered emails, pending bugs). Either address them or park them on a trusted list for later.

5. Set Mental Bookmarks

When pausing work, write a quick comment like // stopped here, was checking data flow. You’ll re-enter the context faster.

6. Use Daily Shutdown Rituals

End your workday with a short review:

What did I complete?
What’s pending?
What's on deck tomorrow?

It tells your brain it’s okay to stop thinking about work.

Clarity is a Developer Superpower

Your ability to think clearly is just as important as your ability to write clean code. Guarding your mental RAM means you'll get more meaningful work done with less stress.

So if you're feeling exhausted and unsure why, pause. Clear your head. Empty the mental RAM. Your future self (and your stack traces) will thank you.

Written for developers who are tired of feeling tired.

What are your go-to ways to reclaim mental clarity? Drop them in the comments.

Why Caching Matters More Than You Think (A Real-World Example)

Stephen Akugbe — Wed, 21 May 2025 14:59:33 +0000

We all love to build things that “just work.”

But sometimes, the very things that seem perfect on the surface can silently rack up technical debt, or worse, financial cost.

Let’s talk about caching.
Not in theory, but from a real-world, high-stakes experience.

The Problem That Wasn’t a Problem (Until It Was)

Sometime last year, I implemented a payment integration flow:

Generate a token
Authorize the request
Create a payment link

It was seamless. This setup successfully handled hundreds of thousands of deposits. No errors. No downtime. Everything looked rock solid.

Until about 6 months later.

Our payment gateway provider reached out:

"We’re seeing a spike in token generation. It’s burning through our resources."

My first reaction: Wait, what?

The problem?

We followed the docs and generated a new token before every payment. Nothing seemed wrong. But here’s what we missed: each token had a 20-minute lifespan. Yet, we hit the token endpoint on every transaction, ignoring reuse.

At scale, that “works fine” code turned into resource-heavy behavior, burning unnecessary compute on the provider’s side.

The Fix: Caching to the Rescue

We introduced a simple but powerful fix: caching:

Store the token once it’s generated
For subsequent requests, we check if it’s still valid
If valid, we reuse it; if not, we generate a fresh one.

Now here’s where it gets interesting.

Even though the token is valid for 20 minutes, we decided to cache and reuse it for only 15 minutes.

Why leave 5 minutes on the table?

Because using a token right up to its expiration is risky.
Factors like network latency, server clock differences, and the provider's internal buffer could cause the token to expire mid-request.

By shaving off 5 minutes, we:

Avoid last-second expiry errors
Ensure predictable behavior
Maintain a healthy buffer for time-sensitive requests

It’s a minor trade-off that massively improved reliability.

The Result:

Over 90% reduction in token requests
Better performance across board
Happier provider
Zero disruption to our users

Just a simple cache, and we went from unintentionally wasteful to clean and efficient.

The Bigger Lesson

Caching isn’t just about speed.
It’s about cost, efficiency, resilience, and being a responsible API consumer.

Whether you're dealing with:

Authentication tokens (Like in my case)
Frequently accessed data
Static assets
Third-party API responses

Caching can be the difference between a system that just works... and one that scales gracefully.

What I Learned

“It works” is not the finish line
Success at scale can hide deep inefficiencies
Always consider the cost behind your architecture decisions

What Would You Do?

Have you ever shipped something that worked great, only to discover it wasn’t as efficient or considerate as it looked?

If you were in this situation, how would you approach the fix?
Would you use a cache? Adjust the token strategy? Something else entirely?

Using NestJS Interceptors for Performance Monitoring

Stephen Akugbe — Mon, 05 May 2025 18:23:04 +0000

When APIs feel slow, most developers start by blaming the database or trying to "optimize the code."

But here’s a better first step: instrument your endpoints and find out exactly where the delays are.

What should you be asking instead?

Which endpoints are consistently slow?
Which services take the longest to resolve?
Are response times spiking under certain conditions?

This kind of visibility is where NestJS Interceptors come in handy — and they’re seriously underrated.

🧠 What are NestJS Interceptors?

Interceptors in NestJS let you hook into the request-response cycle.

You can run logic before or after a request is handled.

They’re perfect for:

Logging
Transforming responses
Caching
Measuring execution time

And the best part? You can do this without touching your business logic.

🛠 Example: Measuring API Execution Time

Let’s create a custom MetricsInterceptor to log how long each endpoint takes:

import {
  Injectable,
  NestInterceptor,
  ExecutionContext,
  CallHandler,
} from '@nestjs/common';
import { Observable, tap } from 'rxjs';

@Injectable()
export class MetricsInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const now = Date.now();
    const req = context.switchToHttp().getRequest();
    const method = req.method;
    const url = req.url;

    return next.handle().pipe(
      tap(() => {
        const timeTaken = Date.now() - now;
        console.log(`[${method}] ${url} took ${timeTaken}ms`);
        // Optionally push to Sentry, Datadog, Prometheus, etc.
      }),
    );
  }
}

You can apply this:

Globally
Per controller
On specific routes

Why do this?

You measure what actually matters
You catch performance outliers (e.g. admin-only or rarely used endpoints)
You keep observability separate from your main code
You reduce blind spots

It’s also a great way to complement tools like Sentry or Datadog — especially when you need internal visibility fast.

Some real-world use cases:

Track slow DB or third-party calls per endpoint
Set up alerts on endpoints crossing thresholds
Visualize which modules need refactoring
Add tags to identify patterns in traffic vs. performance

NestJS Interceptors are a powerful yet lightweight way to gain observability into your backend APIs. No magic. No overhead. Just TypeScript and good architecture.

How do you handle monitoring in your nestjs projects?

Install Tailwind CSS v4 in a Vue 3 + Vite Project

Stephen Akugbe — Wed, 05 Feb 2025 08:27:16 +0000

Tailwind CSS v4 is here, bringing a more streamlined installation process and performance improvements. However, if you check the official Tailwind CSS documentation, you might not find explicit installation instructions for Vue 3 with Vite. This guide will walk you through the process step-by-step.

What’s New in Tailwind CSS v4?

Tailwind CSS v4 introduces several improvements, including:

No PostCSS configuration required – You no longer need postcss.config.js.
Faster build times – Thanks to better optimizations.
New @tailwindcss/vite plugin – Tailwind now integrates more seamlessly with Vite.

Why Vue 3 Instead of Nuxt?

I'm sure you're wondering why I would need Vue 3 instead of just using Nuxt. Vue 3 is a great choice if you’re building a SPA or an SSR-ready app without the full complexity of Nuxt. Here’s why you might choose Vue over Nuxt:

Better Performance: Vue 3 is lightweight and doesn’t add the overhead that Nuxt brings.
More Control: With Vue 3, you decide how your app is structured rather than following Nuxt’s conventions.
No Need for SSR: If you don’t need server-side rendering (SSR) or static site generation (SSG), Vue 3 is simpler.
Faster Builds: Since Nuxt includes additional features, Vue 3 + Vite can be faster for development and deployment.

Installing Tailwind CSS v4 in Vue 3 + Vite

Step 1: Create a Vue 3 Project with Vite

If you don’t already have a Vue 3 project set up, create one using Vite:

npm create vite@latest my-vue-app -- --template vue
cd my-vue-app
npm install

Step 2: Install Tailwind CSS v4

Run the following command to install Tailwind CSS v4 along with its Vite plugin:

npm install -D tailwindcss @tailwindcss/vite

Step 3: Configure Vite to Use Tailwind CSS

Edit vite.config.ts (or vite.config.js if using JavaScript) and add Tailwind CSS as a plugin:

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [
    vue(),
    tailwindcss(),
  ],
})

Step 4: Add Tailwind to Your Styles

Edit the CSS file src/style.css and add:

@import 'tailwindcss';

Step 5: Import Tailwind CSS in main.ts

Check your src/main.ts and ensure your style.css is imported:

import { createApp } from 'vue'
import App from './App.vue'
import './style.css'

createApp(App).mount('#app')

Step 6: Start Your Development Server

Run the Vite development server:

npm run dev

That’s it! You’ve successfully set up Tailwind CSS v4 in a Vue 3 project using Vite. With this new streamlined setup, you can enjoy faster builds and an even smoother development experience.

Have you tried Tailwind CSS v4 yet? Share your thoughts in the comments! 🚀