From HTML to Next.js: The Painful (and Honest) Transition of a FUTO Undergrad

Ngbaronye Nmesirionye — Tue, 14 Apr 2026 07:37:33 +0000

I started my frontend journey like many developers: writing index.html, linking style.css, and maybe throwing in a script.js if I was feeling fancy.

It was simple. It was predictable. It was home.

Then I decided to learn Next.js.

The Wake-Up Call

I'm an undergraduate at FUTO, and I'm building an offline AI companion called Pantero. The waitlist is growing (187+ now), the offline AI core is stable, and the frontend is complete. But let me tell you—getting there involved a lot of pain.

Coming from plain HTML and CSS, Next.js felt like being handed the controls to a spaceship after only ever riding a bicycle. Suddenly there was file-based routing, Server Components, Client Components, and this mysterious 'use client' directive that I kept forgetting to add until my useState hooks exploded in my face[reference:0].

The Mistakes I Made (So You Don't Have To)

Mistake #1: Treating Next.js Like Plain HTML + React

I thought I could just drop my components anywhere and import react-router-dom like I used to. Wrong. Next.js has its own routing system. If you try to fight it, you'll spend more time debugging than building. I learned that the hard way[reference:1].

Mistake #2: Forgetting That Everything Is a Server Component by Default

In the App Router, every component is a Server Component unless you explicitly say otherwise. I kept trying to use useState and useEffect in components that were running on the server. The error messages were cryptic. The frustration was real[reference:2].

Mistake #3: Ignoring File-Based Routing

I thought, "How hard can routing be? I'll just make components and link them manually." Chaos. Some links worked, some didn't. Dynamic routes became unpredictable. SEO was broken. Once I embraced the /app folder structure, everything clicked[reference:3].

Why I'm Sticking With It

Despite the pain, Next.js is teaching me a better way to build. It's forcing me to think about performance, SEO, and user experience from the start. And for Pantero—where every kilobyte matters on a 3G connection—that's essential.

The Build Goes On

While I'm wrestling with Server Actions and trying to understand caching, Pantero keeps moving forward:

🚀 187+ waitlist members
🌍 3+ countries (Nigeria, Ghana, Kenya)
✅ Offline AI core stable and running entirely in-browser

Join the Waitlist

If you're a developer who's been through this transition (or you're in the middle of it right now), I'd love to hear your story. And if you're curious about what I'm building through all this struggle:

🔗 pantero.vercel.app

The waitlist is open. The build continues. The pain is real—but so is the progress.

What was your biggest struggle when you first moved from plain HTML/CSS to a real framework? Let's commiserate in the comments.

No Internet? No Problem. I Built an AI That Works Offline from My Hostel Room

Ngbaronye Nmesirionye — Mon, 13 Apr 2026 11:57:49 +0000

I'm a student at the Federal University of Technology, Owerri (FUTO). Between lectures, assignments, and the occasional power outage, I've spent the last three months building something I believe can change how young Africans learn tech skills.

It's called Pantero.

The Problem: Ambition vs. Infrastructure

Here's a scene that plays out daily across Nigeria:

A student finds a great online course. They're excited. They start learning. Then the data finishes. Or the network drops. The momentum dies. The tab gets closed. And the dream of becoming a developer gets pushed to "someday."

I've lived this. And I knew there had to be a better way.

The Solution: An AI Mentor That Works Offline

What if you had a personal mentor that:

Runs entirely in your browser
Works without an internet connection after the first load
Guides you from zero to job-ready skills
Never judges you for asking the same question twice

That's Pantero. The core idea is simple but technically ambitious: offline-first AI mentorship for African youth.

The Tech Stack (For the Curious)

Layer	Technology
Frontend	React + TypeScript + Tailwind
AI Engine	Local-first models running in the browser
Hosting	Vercel
State Management	React Context + LocalStorage
Build Tool	Vite (bootstrapped with Lovable)

The Hardest Part: Offline AI

The offline AI integration was the biggest technical challenge. I needed models that were:

Small enough to load quickly on 3G
Powerful enough to provide real mentorship value
Capable of running entirely client-side

After testing several approaches, I landed on a combination of quantized models and intelligent caching. The AI runs in your browser, not on a server. Your data never leaves your device. And it works even when you're offline.

Where We Are Now

Pantero is pre-launch. The frontend is complete. The offline AI core is live for testing.

Current metrics:

🚀 187+ waitlist members
🌍 3+ countries (Nigeria, Ghana, Kenya)
🛠️ 12+ early testers

What I've Learned So Far

Build for the reality, not the ideal. Assuming everyone has fiber internet is a mistake. Offline-first isn't a feature—it's a necessity.
Share early, share often. Posting updates on Indie Hackers and WhatsApp has brought more valuable feedback than any closed-door development.
Your constraints are your differentiator. Being a student with limited resources forced me to keep Pantero lean and focused. That's now a strength.

What's Next (The Roadmap)

[ ] Polish the AI mentorship flows
[ ] Add verified credential generation
[ ] Open beta access for waitlist members
[ ] Public launch on Product Hunt

Let's Connect

I'm building Pantero in public. If you're a developer, a student, or just curious about offline AI, I'd love to hear from you.

🔗 Join the waitlist
💬 Follow the build: I'm posting weekly updates in this series

Have you tried building offline-first experiences? What challenges did you face? Let's discuss in the comments.

DEV Community: Ngbaronye Nmesirionye