• Home
  • About
Post header banner
User's profile
Leon Martin Published on Mar 22 • 4 min read

Why Stop Using TypeScript for Small Projects?

I used to be that developer who pushed TypeScript into every single project. Backend? TypeScript. Frontend? TypeScript. A five-minute script to automate file renaming? Yep, even that. It felt like the right move—after all, static typing makes everything better, right?

Well, not always.

After years of forcing TypeScript into every project, I’ve finally admitted something: for small projects, TypeScript is more of a hassle than a help. If I’m spinning up a quick MVP, personal project, or a simple API, I no longer reach for TypeScript by default. Here’s why.

1. The Setup Overhead Isn’t Worth It

Let’s be real—TypeScript requires setup.

  • Configuring tsconfig.json
  • Making sure dependencies work with TypeScript
  • Installing and configuring type definitions (@types/whatever)
  • Adjusting the build process

Yes, I know that modern frameworks like Vite, Next.js, or Nuxt make setup easier with zero-config templates. But when you’re starting from scratch or not using a full framework, that configuration still exists—and for quick hacks or scripts, it's friction I’d rather avoid.

For a large-scale project, this setup pays off. But for something small—like a quick API or a weekend side project—why am I spending 20 minutes wrestling with configs instead of actually writing code?

A simple JavaScript file just works:

// index.js
console.log("Hello, world!");
Enter fullscreen mode Exit fullscreen mode

With TypeScript, even something this basic comes with extra ceremony:

const message: string = "Hello, world!";
console.log(message);
Enter fullscreen mode Exit fullscreen mode

Let’s get this out of the way: no, you don’t need to explicitly annotate string here—TypeScript would infer the type just fine.

This example became a bit symbolic for me. It represents how even the simplest scripts start to feel more formal and verbose when TypeScript is involved. In a quick project where I just want to print a message or hit an API, that extra layer often feels like friction instead of help.

And that’s before setting up the build process.

2. TypeScript Slows Down Experimentation

One of JavaScript’s biggest strengths is its flexibility. Want to throw together a proof-of-concept? No problem. With TypeScript, that agility disappears.

Say I’m trying out a new API. In JavaScript, I’d just fetch some data and move on:

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error(err));
Enter fullscreen mode Exit fullscreen mode

In TypeScript? Now I need to define types:

interface ApiResponse {
  id: number;
  name: string;
  email: string;
}

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then((data: ApiResponse) => console.log(data))
  .catch(err => console.error(err));
Enter fullscreen mode Exit fullscreen mode

Of course, TypeScript lets you use any or gradually introduce types. But that kind of defeats the purpose of using TS in the first place, right? My point is—when I’m in experiment mode, I don’t want to think about types at all. I want fast feedback and no friction.

Sure, it’s safer—but if I’m just playing around, why am I writing extra code before I even know if this API is useful?

3. TypeScript’s Benefits Aren’t That Useful in Small Projects

I get it—TypeScript helps prevent bugs. But in a small project, does it really matter?

Most of the time, the “bugs” TypeScript prevents in small projects are things I’d catch instantly anyway.

Bad example:

const age = "30";  
console.log(age * 2); // NaN
Enter fullscreen mode Exit fullscreen mode

Okay, TypeScript would catch that. But is this the kind of bug that’s keeping me up at night? No. If my entire app is 500 lines of code, I don’t need a compiler to protect me—I can just read the code.

4. The Extra Build Step Feels Unnecessary

With JavaScript, I can run my script instantly:

node script.js
Enter fullscreen mode Exit fullscreen mode

With TypeScript, I have to compile it first:

tsc script.ts && node script.js
Enter fullscreen mode Exit fullscreen mode

For a massive project? No problem. But if I’m writing a quick utility script, this extra step kills momentum.

And yes, I know you can use ts-node to avoid manual compilation, but it still introduces unnecessary complexity.

5. Not Every Dependency Plays Nice with TypeScript

Ever installed a third-party package and immediately run into TypeScript errors?

Property 'xyz' does not exist on type 'SomeModule'.
Enter fullscreen mode Exit fullscreen mode

Then you check the package’s GitHub repo and see no TypeScript support. Now you have three options:

  • Find a DefinitelyTyped package (@types/xyz) (if it exists).
  • Write your own type definitions (ugh).
  • Use any and pretend TypeScript isn’t there.

If I’m working on a big project, I’ll take the time to figure this out. But for a small app, it’s just another headache.

When I Still Use TypeScript

I’m not saying TypeScript is bad—I still use it for the right projects.

✅ Large-scale apps (especially with multiple developers).

✅ Projects with long-term maintenance in mind.

✅ Codebases that rely heavily on strict contracts between modules.

But for:

❌ Side projects

❌ Quick scripts

❌ MVPs and prototypes

I stick with JavaScript. It’s just faster, simpler, and more fun when you don’t have to fight the compiler.

TypeScript is a Tool, Not a Religion

Some developers treat TypeScript like the only way to write JavaScript in 2025. But that’s not true. TypeScript is great when used where it makes sense—but forcing it into every project? That’s just unnecessary friction.

If you love TypeScript, great—use it where it benefits you. But if you’re working on something small, and TypeScript feels like more trouble than it’s worth… maybe it is.

What’s your take? Do you still use TypeScript for everything, or have you started picking your battles? Let’s chat in the comments!