Why I rebuilt my portfolio in Next.js (and what I'd do differently)
I'm a designer and trainer who builds for the web, so my portfolio is two things at once: a place to show my work, and a piece of work in itself. When I decided to rebuild it, the obvious route was a no-code builder (Webflow, Framer, a Squarespace template). I chose Next.js instead. Here's the honest reasoning, including the parts I'd reconsider.
Why not a no-code builder
No-code tools are genuinely good, and for many people they're the right answer. I went the other way for three reasons.
Control. My site has to flex around an unusual setup: three audiences (design, training, development) that each need their own page, their own proof, and their own call-to-action, plus a freebies funnel and a contact pipeline. Bending a template to do all that is often harder than building exactly what you want.
Performance. A portfolio is my technical résumé. If I'm telling clients I care about fast, accessible interfaces, the site has to demonstrate it with real Core Web Vitals, not a heavy template loaded with scripts I don't control. Next.js gives me static generation, image optimization, and fine control over what ships to the browser.
Owning the backend bits. This was the deciding factor. My freebies and contact forms run through Next.js API routes wired to an email service. The lead-capture flow (someone enters their email, gets the resource, and I get notified) is something I own end to end, not a third-party form with limits. Being able to ship the API route alongside the UI is the thing no-code couldn't give me cleanly.
What worked
- Static-first. Most pages are statically generated, so they're fast and cheap to serve, with a single serverless route for email. For a portfolio, that's the right default.
- A single source of truth for data. I moved every stat, certification, and experience entry into one data file so the same number can't say "1,000+" on one page and something else on another. (Learned that one the hard way.)
- The site as a portfolio piece. Building it myself means the codebase is a sample, and writing this article is part of that.
What I'd do differently
Honesty is more useful than a victory lap, so here's what I got wrong or would change:
1. I shipped with the safety rails off. To move fast I let the build ignore TypeScript and lint errors. That's fine for momentum and dangerous for maintenance. Regressions ship silently. If I were starting again I'd keep the type-check in the build from day one and pay the small tax up front.
2. Internationalization deserved a real plan. I work across Arabic, French, and English, and I bolted i18n on later instead of choosing a proper routing strategy at the start. Retrofitting translations is far more painful than designing for them on day one. If multilingual matters to you, decide before you build.
3. I over-installed. A component library is convenient and quietly heavy. I pulled in far more than I used. Next time I'd add dependencies only when a real need appears, and audit the bundle regularly.
4. No tests, then surprises. With no automated checks, small changes occasionally broke things I didn't notice until later. Even a handful of smoke tests (does the nav render, does the form submit, do the stats show real numbers) would have saved me.
Should you use Next.js for a portfolio?
If you're a developer, yes. Your portfolio should prove you can build, and this is the most honest proof there is. If you're not, a good no-code builder will get you a beautiful site faster, and that's completely valid; a live site beats a perfect one that never ships. The framework is a means, not the point.
What I keep coming back to is this: the tool you choose should match the story you're telling. I tell clients I can take an idea from design through to a shipped, fast, maintainable product. Building this site myself, mistakes and all, is the most credible thing I could put in front of them.
Curious about the build, or want one like it? I take on web projects. Book a free call and I'll walk you through what I'd ship for you, or see the development work.