Forem: Fabunmi George Goodluck

Stop Overengineering: How to Build Scalable Apps Without Killing Your Momentum

Fabunmi George Goodluck — Sun, 19 Apr 2026 18:00:11 +0000

Okay so here's something I see constantly with devs who've been coding for a year or two.

You get past the "how do I even make this work" phase. And suddenly you're not just building stuff anymore. You're architecting.

Like, every new feature turns into this whole thing:

"Where does this actually belong in the folder structure?"
"Better make this component reusable... just in case"
"What if we need to swap this out later?"

Next thing you know, it's Tuesday afternoon and you've written zero working code. You've just moved files around and argued with yourself about abstractions.

Ugh.

The real problem (it's not just premature optimization)

We all know premature optimization is bad. But there's a sneakier version:

Premature architecture.

You're literally designing solutions for problems that don't exist yet.

Adding layers "for scalability" when you have 12 users
Building reusable components that get used once
Overthinking state management for a todo list

And the cost? Slower dev, harder debugging, and you're constantly second-guessing yourself.

Here's the thing nobody tells you

Scalable systems aren't designed.

They evolve.

Go look at any successful product's early code. I guarantee it's messy. Probably embarrassing. But it shipped. Then they refactored when the pain got real.

You can't predict what's gonna break. You can only get good at responding fast when it does.

Just do this instead

Step 1: Make it work.

Hardcode stuff. Skip abstractions. Just ship the feature.

Step 2: Wait for it to hurt.

When you're like "omg changing this is painful" or "this is slow as hell" — that's your signal. Not before.

Step 3: Then refactor.

Now you actually know what needs to be reusable. What's actually slow. What's actually painful.

Now architecture makes sense.

Real example (React folders)

Start stupid simple:

src/
  components/
  pages/
  utils/

That's it. Boring. Works fine.

Later, when you're drowning in files:

src/
  features/
    auth/
      components/
      hooks/
      api/
    dashboard/
      components/
      services/
  shared/
    ui/
    hooks/

See the difference? You earned that structure. You didn't start there.

Red flags you're overdoing it

If you catch yourself saying:

"We might need this later" (you won't)
"Let's make this super reusable" (it's used once)
"This should support multiple cases" (there's one case)
Or you're organizing more than you're coding

Stop. Take a breath. Ship something.

Some rules that actually work

Build for today. Not for "what if we get 10 million users"
Duplicate code twice before abstracting it the third time
Don't add libraries you barely understand
Only optimize when you can measure the problem
Ship faster than you refactor

If you're building something right now...

You don't need microservices. You don't need a fancy state machine. You don't need enterprise architecture.

You need working features. You need feedback. You need to move fast.

Everything else is just procrastination wearing a fancy hat.

The best devs aren't the ones who design perfect systems. They're the ones who know when to just shut up and build the damn thing.

How I structure Scalable React Applications

Fabunmi George Goodluck — Fri, 03 Apr 2026 22:38:35 +0000

How I Structure Scalable React Applications

Most React apps start clean… and slowly turn into chaos.

At first, everything makes sense. Then the app grows. Suddenly:

Files are everywhere
Logic is hard to track
Reusability becomes messy

I ran into this problem myself, and the fix was simple: stop organizing by file type — start organizing by feature.

1. The Feature-First Folder Structure

Instead of grouping files like this:

/components
/styles
/hooks

Group them by what they actually do in your app.

src/
├── assets/          # Images, fonts, icons
├── components/      # Shared UI (Button, Input, Modal)
├── features/        # Core app logic
│   ├── auth/        # Login, signup, auth logic
│   ├── dashboard/   # Charts, stats
│   └── profile/     # User settings
├── hooks/           # Global reusable hooks
├── services/        # API layer
├── store/           # State management
└── utils/           # Helpers

This keeps everything related to a feature in one place — which makes scaling way easier.

2. Inside a Feature Folder

Each feature should be self-contained.

Example: features/auth/

auth/
├── components/   # UI specific to auth
├── api/          # API calls
├── hooks/        # useAuth, etc.
└── index.ts      # Public API

That index.ts is important. It controls what the rest of your app can access.

So instead of:

import LoginForm from "@/features/auth/components/LoginForm";

You do:

import { LoginForm } from "@/features/auth";

Cleaner. Easier to refactor later.

3. Component Hierarchy (Keep It Clean)

There are two types of components:

1. Shared Components
Located in /components
Reusable and unaware of business logic
Examples: Button, Card, Modal

2. Feature Components
Located inside /features/[name]/components
Built for a specific purpose
Examples: LoginForm, UserProfileHeader

This separation prevents your “shared” components from becoming messy and overcomplicated.

When This Approach Makes Sense

If your app is:

Growing fast
Has multiple features
Getting harder to navigate

This structure will save you a lot of pain.

If you’re building something small?
Don’t over-engineer it.

Final Thought

Good structure doesn’t matter on day one.

But a few weeks in… it matters a lot.

Organize by feature early — your future self will thank you.

Covid-19 Tracker App

Fabunmi George Goodluck — Sat, 26 Feb 2022 18:20:16 +0000