DEV Community: Antar Mukhopadhyaya

I got tired of setting up the same stack 50+ times — so I built this

Antar Mukhopadhyaya — Thu, 09 Apr 2026 06:39:38 +0000

I didn’t procrastinate because I was lazy.

I procrastinated because I didn’t want to deal with setup.

Next.js. Auth. Database.

Not hard.

Just enough friction to stop me from starting.

The idea was simple

One day I wanted to build a small app for myself — a simple fact memorization app.

Every day it would show me 5–6 facts and prompt me to add new ones for my competitive exams.

Nothing complex. Just something useful.

I was ready to build it.

The stack I kept repeating

Expo + NativeWind + Supabase
Next.js + Auth + Database
Same configs. Same steps. Every time

I’ve done this 40–60 times.

At some point, it’s not learning anymore.

It’s just repetition.

Then reality hit

Before writing a single line of actual logic, I had to:

Set up Expo
Install NativeWind packages
Configure NativeWind, Babel, and Metro
Wire Supabase into the app
Install and configure additional tools like TanStack Query

And I just paused.

Because I’ve done this before.

Not once. Not twice.

But dozens of times.

The real problem

Setting things up isn’t hard.

That’s not the issue.

The issue is what it does to your brain.

To set up a modern stack, you end up:

opening multiple tabs
reading scattered documentation
switching between configs
debugging small, annoying errors

Sometimes you miss one tiny step — like updating metro.config.js — and suddenly things break.

Now you’re debugging instead of building.

And momentum is gone

By the time everything finally works, I’ve already lost most of my momentum.

Not because I don’t know what to do.

But because my focus got fragmented.

The insight:

The problem isn’t time.

The problem is context switching.

Your brain is wired for deep work.

But setup forces you to constantly switch context before you even start building.

Repetition makes it worse

The first time you set up a stack, you’re learning.

The tenth time, you’re faster.

The fiftieth time?

You’re just repeating yourself.

At that point, it’s no longer learning.

It’s friction.

So I built something for myself

I didn’t want to feel this every time I started a project.

So I built a CLI tool called Forge.

Define your stack once. Reuse it forever.

What Forge does

Forge lets you scaffold complete setups using presets.

Instead of manually wiring everything every time, you just run:

npx @antardev/forge-dev init next-saas-pro my-app

And you're ready to start building.

No configs. No context switching. Just start building.

It comes with baked-in presets like:

Expo + NativeWind + Supabase
Next.js + Better-Auth + Drizzle
MERN stack

Bring your own setup

But I didn't want to lock you into my preferences. You can define your own custom presets or even run them directly from GitHub repositories. If your team has a specific starter kit, just point Forge to the repo, and it handles the rest.

What it doesn’t do

Forge doesn’t generate business logic. It doesn’t try to be smart about your app's architecture. It only removes the most painful phase of development:

install → configure → glue

Why this matters

Because the hardest part of building isn’t coding. It’s getting into flow. If starting your project feels annoying, you simply won’t start it.

What’s next?

Right now, Forge uses predefined and custom-linked presets. But the next step is more interesting: Recording setup steps and turning them into reusable presets automatically. So you never repeat yourself again.

Final thought

I didn’t build Forge to save time. I built it to save momentum. Because once you lose that, starting becomes the hardest part.

Try it out:

📦 NPM Package

🐙 GitHub Repository

If you try Forge, I’d love to know what stack you build with it.

I tried “forgotten” frameworks — and shipped a client app in 3 hours

Antar Mukhopadhyaya — Sun, 05 Apr 2026 12:10:06 +0000

I didn't expect to use Framework7 or NativeScript in 2026.
But yesterday evening, I got a small client requirement: a simple inventory tracking system.

Two roles:

Admin -> add items, restock, edit/delete, view audit logs.
Staff -> only deduct/sell items.

The usual instinct

My first thought was obvious:

React Native
or Jetpack Compose

But then I paused. That meant setting up environments, fixing dependencies, dealing with configs, and running npx expo install --fix type commands.

And for what? A simple app. I didn't need the best stack; I needed the fastest path to working software.

Trying NativeScript

I had seen NativeScript before in a YouTube video, so I gave it a try.

And honestly,

NativeScript felt closer to native and more fluid.

The UI felt smooth and the experience was solid.

But...

It works really well when it works.
But when it doesn't, you are kind of on your own.

I ran into:

inconsistent documentation
outdated packages (6-8 years old)
issues with font icons not rendering
styling that isn't exactly standard CSS

I fixed some of it, but it was slowing me down.

And for this project, speed mattered more.

Switching to Framework7

So I switched.

I scaffolded a Capacitor app, added Framework7, and just started building.

And this is where things clicked.

Framework7 already had:

pull to refresh
swipeable list items
infinite scrolling
built-in toasts, dialogs and alerts
ready-made UI components like search bar and icons

Everything I needed for this kind of app was already there.

No overthinking.

Just import and use.

What surprised me

I finished the entire app in under 3 hours (including testing).

Stack:

Framework7
Capacitor
TanStack Query
Supabase

And the result?

The UI looked completely like a native Material app.

If I showed it to someone, they'd probably assume it was built with Jetpack Compose.

The tradeoff

Of course:

NativeScript -> more native feel, smoother
Framework7 -> runs in WebView with the help of Capacitor.

So yes, NativeScript felt more fluid and performant.

But:

I didn't need that level of fidelity.

I needed something:

simple
fast
correct

The real lesson

This project reminded me of something important:

Not every problem needs the best framework.
It needs the right framework for the constraints.

Final thought

Before I wrap up, one thing I want to say about NativeScript.

Personally, I think the idea behind NativeScript is genuinely unique.

Being able to use JavaScript/TypeScript to directly access native APIs without a heavy bridge layer is a very powerful concept. The team behind it has done some really impressive work.

But at the same time:

a great idea alone isn’t enough.

The ecosystem and documentation haven’t kept up, and that makes it hard to rely on in real-world scenarios where time matters.

That said, I would still consider using it for future projects — especially when I have more time.

The idea and execution behind NativeScript are too unique to ignore.

Most clients don’t need complex systems.

They don’t care about:

architecture purity
cutting-edge stacks

They care about:

something that works consistently and fits into their workflow.

And sometimes, the tools that help you do that fastest
are the ones people stopped talking about.