Smash Story: The Missing Module That Brought My Backend to a Halt

Williams Favour — Tue, 21 Jul 2026 09:58:42 +0000

Project Overview

I was building the backend for a web application using Node.js and Express. The goal was straightforward: create a scalable REST API that would later power authentication and other application features. Everything seemed properly configured until I attempted to start the server.

Instead of seeing my application running, I was greeted with an error indicating that Express could not be found.

At first, it seemed like a simple installation issue. It turned out to be much more educational than that.

The Problem

Running the development server immediately failed with an error similar to:

Error: Cannot find module 'express'

Despite having already installed Node.js, the application refused to start.

Investigation

Rather than reinstalling everything immediately, I approached the issue methodically.

First, I verified that Node.js was correctly installed.

node -v
npm -v

Both commands worked as expected.

Next, I inspected the project's structure and confirmed that the package.json file existed and contained Express as a dependency.

"dependencies": {
  "express": "^5.x"
}

Everything looked correct.

I then realized the actual dependencies had never been installed inside the project directory.

Running:

npm install

generated the missing node_modules folder.

However, the application still failed because I was starting the server from the wrong working directory.

After navigating into the correct project folder and restarting the application, everything worked exactly as expected.

The Fix

The solution involved three steps:

Verify the runtime environment.
Install all project dependencies using npm install.
Launch the application from the correct project directory.

After these changes:

npm run dev

started the Express server successfully.

Impact

Although the bug itself was relatively small, solving it reinforced an important engineering lesson.

Many development issues are not caused by faulty code but by inconsistencies in the development environment. Carefully validating assumptions, checking dependencies, and verifying the execution context proved more effective than repeatedly rewriting code.

This experience also encouraged me to adopt a more systematic debugging process:

Verify the environment first.
Reproduce the issue consistently.
Test one assumption at a time.
Confirm the fix before moving on.

Those habits have continued to improve the reliability of my development workflow.

Lessons Learned

One of the biggest lessons I took away is that debugging is less about guessing and more about gathering evidence.

A clear, structured troubleshooting process often solves problems faster than making random changes. Since then, I have become much more intentional about checking project configuration, dependency management, and execution context before assuming the application logic is at fault.

Every bug teaches something. This one taught me that disciplined debugging is just as valuable as writing new code.