标签：#NeXT

Bridging Design and Code to Empower Local Businesses As a full-stack developer specializing in JavaScript and React, one of the most exciting ventures I'm currently on is building ready-made websites and Next.js templates through Softchic. This isn't just about coding; it's about deeply understanding the needs of businesses, particularly within the vibrant and rapidly evolving Nigerian market, and translating those into high-performance, beautiful web solutions. Why Next.js? Performance, SEO, and Developer Experience My choice of Next.js as the primary framework for these templates was deliberate: Performance: Server-side rendering (SSR) and static site generation (SSG) capabilities are crucial. In areas where internet speeds might vary, a fast-loading website isn't just a nice-to-have; it's essential for user retention and conversion. SEO: For businesses looking to establish a strong online presence, robust SEO capabilities out-of-the-box mean our templates provide a solid foundation for discoverability. Developer Experience: Building with Next.js allows for efficient development, leveraging the power of React while simplifying routing, data fetching, and API routes. This means faster iteration and higher quality templates. The Nigerian Market: Unique Challenges, Immense Opportunity Crafting templates specifically for the Nigerian market presents a fascinating set of considerations: Design Aesthetics: Understanding local preferences in terms of color palettes, layouts, and user flows is critical. It's not just about what looks good globally, but what resonates locally. This is where my dual role as creative director for promotional materials comes into play – applying that eye for design directly to the templates. Mobile-First Mentality: A significant portion of internet users in Nigeria access the web via mobile devices. Every template is meticulously designed with a mobile-first approach to ensure optimal responsiveness and user experience on smaller screens. Aff

Static site generation has a branding problem. Say "static site" and people picture a blog with twelve posts and a contact form. So how far can you actually push it before you need a backend? Further than most people assume. This is a walkthrough of a production site that has no database, no API layer, no user accounts and no server-side state, and still ships 232 prerendered pages with per-user results, shareable links and dynamic social cards. The site is a Spanish political test with nine ideological axes, seventeen parties, fifty-four questions. It is in Spanish, but nothing here depends on reading it. Treat it as the reference implementation. The architecture in one sentence Three data files are the source of truth, everything else is derived at build time, and everything user-specific happens in the browser. That is the whole trick. The rest is consequences. 1. Derive pages, don't author them The site has 232 URLs. Almost none of them were written by hand. There are three data modules: the axes, the parties, and the questions. From those, generateStaticParams produces every content route: // app/ejes/[id]/page.tsx export function generateStaticParams () { return AXES . map (( a ) => ({ id : a . id })) } The interesting one is the comparison pages. Seventeen parties means 17 × 16 / 2 = 136 unique pairs, and each pair gets its own page, its own metadata and its own canonical URL: export function allPairs () { const out = [] for ( let i = 0 ; i < PARTIES . length ; i ++ ) for ( let j = i + 1 ; j < PARTIES . length ; j ++ ) out . push ({ a : PARTIES [ i ]. id , b : PARTIES [ j ]. id }) return out } export function generateStaticParams () { return allPairs (). map (( p ) => ({ pair : pairSlug ( p . a , p . b ) })) } 136 pages from twelve lines. And because the page body is computed from the same vectors, recalibrating one party silently rewrites the sixteen pages that involve it . No CMS, no migration, no content drift. The numbers on the page cannot disagree with

This is part of my Building Fluentic Style series, where I’m writing down the design decisions, tradeoffs, and small surprises from building Fluentic Style . It is one thing to make a styling library feel good in a client-side app. It is another thing to make it feel good in Next.js App Router. In a simple SPA-style development setup, most of the styling loop lives in one place: component renders in the browser Fluentic style chain resolves atomic CSS rule is inserted DevTools can inspect the generated rule sourcemap points back to authored code That is already a lot of work. But at least the browser is the main place where the style is produced and consumed. Next.js App Router changes the shape of the problem. Now the page can involve: server rendering React Server Components client components streamed HTML hydration client-side navigation HMR Webpack or Turbopack development sourcemaps production extraction So the hard part is not just “can Fluentic run in Next.js?” The hard part is: Can Fluentic keep the same CSS debugging experience when styles cross the server/client boundary? That is what this post is about. Docs for the Next.js integration are here: Next.js Integration DevTools And Sourcemaps Runtime And Dev Debug Without Getting Lost The Goal Was Not A Special Next.js API I did not want Fluentic to have one mental model for client apps and another one for Next.js. This should still be normal Fluentic: const card = style ({ padding : 16 , borderRadius : 12 , }). hover ({ boxShadow : ' 0 12px 30px rgb(15 23 42 / 0.16) ' , }); export function Card () { return < section css = { card } > Hello </ section >; } And this should still be normal Fluentic too: const buttonStyles = { root : style . slot ({ display : ' inline-flex ' , border : 0 , }), label : style . slot ({ fontWeight : 700 , }), }; const danger = style . scope ([ buttonStyles . root ({ backgroundColor : ' #dc2626 ' , }), buttonStyles . label ({ color : ' #ffffff ' , }), ]); The Next.js integration shou

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The build was done. Themis Lex worked on my machine, and not in the "works if you squint" way. A court clerk enters their role, describes their workflow, picks a data sensitivity level, and gets back a PDF with two sections: where AI can safely support the work, and where it must never touch it. Claude via Bedrock generates the assessment. Server-side PDF render. No accounts, no storage, session ends when the download does. Three weeks solo, for the Women in AI Accelerator Spring 2026 Build Challenge. Initial commit went in at 7:06pm on May 9. I pushed to AWS Amplify . Build went green. I opened the live site, filled out the form, hit submit. Nothing. Twenty eight seconds later, "Request timed out." I told myself the bug was not in my code. Everything ran locally. This had to be a platform problem. That belief carried me all night. It mostly held up. The exception was the first thing I should have checked. Here is the commit log, because it tells the story better than I can: 19:06 Initial commit: Themis Lex MVP 20:31 refactor: migrate Bedrock auth to IAM compute role 22:29 diag: log credential env vars at runtime (booleans only, remove after fix) 22:40 fix: forward BEDROCK_MODEL_ID to SSR runtime via next.config.js env 22:50 fix: switch to InvokeModelWithResponseStreamCommand to beat 28s Lambda timeout ... 06:28 fix: remove unused type export that broke isolatedModules build 06:37 fix: end-to-end response streaming to beat Amplify 28s gateway timeout 06:48 fix: reduce max_tokens to 3000 to fit Amplify 30s timeout 06:52 fix: reduce max_tokens to 2000, 3000 still exceeded 30s timeout 07:00 fix: switch to Claude Haiku 4.5 to fit Amplify 30s timeout Ten and a half hours from first deploy to the fix that shipped it. That gap between 22:50 and 06:28 is me sleeping on it, which turned out to be the second most productive thing I did. The error message was the absence of an error message My f

There are exactly three sensible ways to get an SVG icon into a React codebase: paste it inline as a component, import the file through a build transform like SVGR, or reference it from a sprite. Most projects need only the first. This guide walks through the inline approach with Next.js and Tailwind specifics, and points to the deeper guides where a topic deserves its own article. Option 1: an inline JSX component Take a real icon from the catalog, convert the SVG attributes to JSX casing, and you have a dependency-free component. This is Lucide's search icon, exactly as it ships in the Lucide set , wrapped for React: export function SearchIcon ( props ) { return ( < svg xmlns = "http://www.w3.org/2000/svg" viewBox = "0 0 24 24" fill = "none" stroke = "currentColor" strokeLinecap = "round" strokeLinejoin = "round" strokeWidth = { 2 } aria-hidden = "true" { ... props } > < path d = "m21 21l-4.34-4.34" /> < circle cx = "11" cy = "11" r = "8" /> </ svg > ); } The JSX gotchas are all attribute casing: stroke-width becomes strokeWidth , stroke-linecap becomes strokeLinecap , and class becomes className . Icon pages on this site do the conversion for you: every icon offers React, Vue, Svelte, and Solid snippets next to the raw SVG, so you can copy the JSX form directly. If you have a folder of SVG files instead, the free SVG to component converter batch-converts them in the browser. Prefer importing .svg files over pasting? That is the SVGR route, covered step by step in our React with Vite and SVGR guide . Next.js: server components by default An icon component like the one above has no state, no effects, and no event handlers, which makes it a perfect React Server Component. In the Next.js App Router it renders to static markup on the server and adds nothing to the client bundle: import { SearchIcon } from " @/components/icons " ; export default function DocsHeader () { return ( < label className = "flex items-center gap-2" > < SearchIcon className = "h-5 w-5 text-zinc

The Situation Our team's CI/CD pipeline on Azure DevOps was taking 15 minutes to complete on every push to develop. You'd merge a PR, grab a coffee, come back — and it was still running. A 15-minute feedback loop breaks flow state — by the time the pipeline finishes, you've already switched context twice and forgotten what you were checking. I spent an afternoon digging into the Azure DevOps logs. Here's what I found. The Numbers (Before) Artifact content (uncompressed): 1,218 MB (1.2 GB) Artifact downloaded (compressed): 614 MB Download time: 3-4 min Pipeline breakdown: Build stage: ~5 min (Docker build + artifact) Download artifact: ~3 min (614 MB over the wire) Configure App Service: 2m54s (5 Azure API calls) Deploy (AzureWebApp@1): ~1 min Validate: 2m07s (sleep 30 + 3×30s probes) ───────────────────────────────── Total: ~15 min Root Cause #1: Ignoring output: 'standalone' next.config.js had this: const nextConfig = { output : ' standalone ' , // ← was there the whole time ... }; output: 'standalone' tells Next.js to produce .next/standalone/ — a self-contained directory with only what's needed at runtime. Trimmed node_modules . Auto-generated server.js . No source files. No dev dependencies. But the pipeline was ignoring it: # Old pipeline — copies everything from Docker docker cp deployImage:/app/node_modules . # 600 MB 😱 docker cp deployImage:/app/src . docker cp deployImage:/app/.next . docker cp deployImage:/app/server.js . # ... more files /bin/zip -r deploy.zip .env .next public node_modules package.json \ next.config.js jsconfig.json postcss.config.mjs decs.d.ts src server.js # Then published the ENTIRE working directory as the artifact - task : PublishPipelineArtifact@0 inputs : targetPath : ' $(System.DefaultWorkingDirectory)' # 1.2 GB of loose files + zip Azure DevOps compressed this to 614 MB for transfer. The deploy stage downloaded 614 MB to use a 24 MB zip buried inside it. The fix: # New pipeline — standalone only docker cp deployImage:/app/.next/

Next.js Sitemap Not Updating? Here's the Real Fix If your Next.js sitemap is not updating after you publish new content, you're dealing with a cache-coherence bug that almost nobody writes up. It has an exact symptom, a reproducible root cause, and a one-line fix. This is the guide you'll wish you had the moment you notice /sitemap.xml serving fewer entries than your real site. The symptom: your sitemap lags behind your published content The mismatch is impossible to miss once you look. On our own site, /lab lists 11 published posts, yet /sitemap.xml shows only 7. Same database, same deploy, two different answers. If that gap sounds familiar, you're in the right place. You might have checked your afterChange hook, verified that revalidateTag('posts') fires, and even confirmed that the tagged data refreshes — only to find the sitemap still frozen. That's because the problem lives between two cache layers, not inside the data fetch. Why revalidateTag doesn't fix a stale Next.js sitemap The answer lies in what sitemap.ts actually is. According to the Next.js Metadata Files: sitemap.xml documentation, it's a special Route Handler. And like any Route Handler, Next.js caches its rendered output by default. Here's what happened in our own repository (this bug is documented in a comment at the top of app/(frontend)/sitemap.ts because it cost real indexation time): We read content from Payload using unstable_cache , tagged with the collection slug posts . An afterChange hook called revalidateTag('posts') whenever a post was published. That call did work — it invalidated the inner unstable_cache data entry. But the route's statically-rendered outer XML output was never re-run. The frozen route output kept serving the old XML built from the old data, long after the inner cache was refreshed. Two cache layers. Tag-based revalidation busted the inner one, but the outer route handler cache was never told to re-execute. That's the missing piece. The one-line fix: route-level ISR o

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. When building AI-powered applications, the hardest part is not connecting an LLM API. The real challenge is making AI-generated output reliable enough to use in real-world workflows. While building GrowEasy AI-Powered CSV Importer, an AI-powered CRM lead import pipeline, I faced an important engineering challenge: How can we safely use AI-generated data when importing business records into a CRM? The application accepts lead data from different sources: 🔹 Facebook Lead Ads 🔹 Google Ads 🔹 CRM exports 🔹 Excel sheets 🔹 Custom spreadsheets Each source follows a different structure. The same field can have different names: phone mobile_number contact_no whatsapp_number The goal was to automatically understand these variations, map the columns correctly, and convert the data into a fixed CRM structure using Google Gemini. 🐛 The Challenge Initially, the workflow looked simple: CSV Upload ↓ AI Processing ↓ CRM Import But AI responses cannot always be treated as perfect structured data. Possible issues: ❌ Missing required fields ❌ Invalid values ❌ Incorrect formats ❌ Unexpected AI responses ❌ Incomplete lead records For example: A CSV file may contain: phone_number The AI can correctly understand that this represents a phone field, but there can still be problems: Missing phone values Invalid formats Incorrect mappings Incomplete records The problem was not the AI model itself. The problem was treating AI output as trusted data without an additional validation layer. 🔍 Finding the Root Cause The import pipeline needed a safety checkpoint before saving any data. Instead of: AI Response → Import The workflow needed to become: AI Response → Validation → Import The backend needed to remain the final source of truth. 🛠️ The Solution I added backend validation to verify every AI-generated result before importing it into the CRM. The improved workflow: CSV Upload ↓ CSV Parsing ↓ AI Column Mapping ↓ Va

Remix 3 is a full-stack web framework that moves away from React, focusing on web platform primitives. It integrates routes, request handlers, and UI components into a single structure, utilizing a forked Preact for the frontend. Unlike previous versions, it emphasizes server ownership of the request lifecycle. Migration from Remix 2 is not straightforward, as it requires changes to existing apps. By Daniel Curtis

Published on Feb 16th, 2023 My solar e nergy startup platform FasoLara has reached a new milestone recently and I decided to start a new blog series about it! The project management platform has been a long journey since I published my first commit to GitHub in October 2020. What started based on a simple idea quickly became a behemoth of a software engineering project for my beginner programmer skills. I have poured thousands of hours into research, tutorials and coding to figure out how to put something like this together. Since then, I have made multiple changes to the FasoLara repository. The platform is currently open source, but I am using a private fork to publish the 3 different components to the Vercel platform. I had a basic demo of the admin dashboard with 6 pages before I removed all the sample data, then upgraded everything to the app directory in NextJS 13 and connected the dashboard to the backend server featuring Apollo GraphQL server v4. Yesterday, February 15th, 2023, I added Next-Auth to handle authentication. Initial testing of the next-auth version seems to work with the appDir in Next.JS 13. It is far from the login experience that I want. It will take more effort to iron out the details because proper documentation is still rare Lots of testing needs to be done Although I have successfully connected the Cypress testing framework to the frontend app, I have yet to do the same on the admin app. I am managing a lot of complexity with lots of new packages. Every mistake under the sun I have lost count of how many times I made breaking changes to the code base trying to implement new features on the main branch only to hard reset the branch after tens of hours of work that I could have done on a new branch instead. I can say that I am moving fast and breaking things per facebook's motto! Mobile app on the backburner I have 3 sample pages that I made on the mobile application. I would have liked to have at least a fully functional landing page on th

I used to juggle ESLint and Prettier every day. Two tools. Multiple config files. Plugin conflicts. Slow checks. And that constant feeling that something was always fighting something else. Then I found Biome . Biome is a single, Rust-powered tool that does both formatting and linting. It replaces the classic ESLint + Prettier combo with one binary and one simple config. Why it feels different It’s extremely fast. According to the official benchmark, Biome formats ~35x faster than Prettier when processing 171,127 lines of code across 2,104 files (on an Intel Core i7 1270P). In real projects, the difference is impossible to ignore — checks that used to take seconds now finish almost instantly. One tool, one config. No more keeping a linter and a formatter in sync. Biome uses the same parser for both jobs, so they never disagree. High compatibility, clear feedback. The formatter is about 97% compatible with Prettier. The linter comes with hundreds of solid rules inspired by ESLint and TypeScript ESLint. And when something is wrong, the error messages actually tell you where the problem is and how to fix it. It just works. You can format, lint, and organize imports in a single command. It supports JavaScript, TypeScript, JSX, JSON, CSS, HTML, GraphQL, and more. Companies like Vercel, Cloudflare, Discord, Microsoft, and Google are already using it in production. That says something. I’m not saying you must drop everything tomorrow. But if you’re tired of slow tooling and config complexity, Biome is worth a serious look. Have you tried it yet?

Download the MD files HERE Download the MDc files for Cursor HERE Download the Single MD file HERE Stop fighting your AI. Start giving it an architecture. Large Language Models (LLMs) have become incredible coding assistants. They can scaffold projects, generate components, write tests, and even refactor entire codebases in minutes. But there's one major problem. Without clear architectural boundaries, AI will often generate code that works—but doesn't scale. You'll commonly see it: 🍝 Mixing database queries directly inside React components 🎨 Repeating the same Tailwind utility classes across dozens of files ⚡ Using outdated React patterns instead of modern Next.js App Router features 🔐 Skipping validation and authorization checks 📦 Creating unnecessary client-side state 🚫 Ignoring accessibility, SEO, and Core Web Vitals The result? A project that becomes harder to maintain with every AI-generated feature. If you want your AI to behave like a Senior Software Architect instead of a junior developer, you need to provide it with a clear engineering playbook. That's exactly what the 5-Pillar Architecture accomplishes. Instead of placing thousands of lines of instructions into one massive prompt, you split your engineering standards into focused rule files that are automatically loaded when they're needed. The result is cleaner code, fewer hallucinations, better consistency, and dramatically improved developer experience. Download the MD files HERE Download the MDc files for Cursor HERE Download the Single MD file HERE 🏛️ The 5-Pillar Architecture The idea is simple. Rather than giving your AI every instruction every time, divide your project standards into specialized domains. For example: Your Request Rules the AI Should Load Build a landing page Global + UI/UX Create authentication Global + Security + API Add database tables Global + API Improve SEO Global + SEO Create reusable components Global + UI This focused approach has several benefits: 🚀 Faster responses 🧠 Bet

Headline: Next.js Middleware (middleware.ts at the project root) runs before every matched request — before cache, before rendering, before the route. That position makes it right for auth redirects, A/B cookie bucketing, and locale detection. Wrong for database queries and heavy imports. In 2026, Middleware on Vercel runs on Fluid Compute (standard Node.js), so the constraint is latency budget, not API availability. Key takeaways Middleware runs before every matched request — before cache, rendering, or route handler — the right layer for auth, locale, and A/B bucketing. Middleware can read requests, set cookies, redirect, rewrite, or return early — without the route running. DB queries and large packages add latency to every request. On Vercel in 2026, Middleware runs on Fluid Compute (standard Node.js). The constraint is latency: every added millisecond is paid on every matched request. Use matcher to scope Middleware to only the routes that need it; without it Middleware runs on every static asset request. Auth in Middleware = verifying a self-contained JWT without a DB call. Full session validation belongs in the route. I spent a long time only using Middleware for locale redirects. After shipping auth-protected routes and an A/B test, the full shape became clear. What is Next.js Middleware and where does it run? Middleware is exported from middleware.ts at the project root. It intercepts matched requests before route resolution, cache lookup, and Server Component execution. Returns one of four types: pass through ( NextResponse.next() ), redirect, rewrite (serve different content while keeping original URL in address bar), or a direct response. export function middleware ( request : NextRequest ) { return NextResponse . next (); } export const config = { matcher : [ ' /((?!_next/static|_next/image|favicon.ico).*) ' ], }; Without matcher , Middleware runs on every request including static files. On Vercel in 2026, Middleware runs on Fluid Compute — standard Nod

Next.js 16 shipped Cache Components - the feature that finally lets a single route mix static HTML, cached data, and per-request dynamic content without splitting it into separate pages. It is Partial Prerendering (PPR) made stable, plus a new use cache directive that replaces the old unstable_cache and the awkward route-segment config flags. This guide covers what changed, the three content types you now think in, and the runtime-data rule that trips up almost everyone on day one. What actually changed If you were using the experimental PPR flag, it is gone. Cache Components is a single config switch, and it turns on the whole model - static shell, cached segments, and streamed dynamic content in one route. // next.config.ts import type { NextConfig } from ' next ' const nextConfig : NextConfig = { cacheComponents : true , // replaces experimental.ppr } export default nextConfig Once it is on, every piece of your route falls into one of three buckets. The whole mental model is learning which bucket each component belongs in. The three content types Static - synchronous code, imports, and pure markup. Prerendered at build time and served instantly from the CDN. Your header, nav, and layout shell. Cached - async data that does not need to be fresh on every request. Marked with use cache . Think product lists, blog posts, dashboard stats. Dynamic - runtime data that must be fresh (cookies, headers, per-user state). Wrapped in Suspense so it streams in after the shell paints. import { Suspense } from ' react ' import { cookies } from ' next/headers ' import { cacheLife } from ' next/cache ' export default function DashboardPage () { return ( <> { /* Static - instant from the CDN */ } < header >< h1 > Dashboard </ h1 ></ header > { /* Cached - fast, revalidates hourly */ } < Stats /> { /* Dynamic - streams in with fresh data */ } < Suspense fallback = { < NotificationsSkeleton /> } > < Notifications /> </ Suspense > </> ) } async function Stats () { ' use cache ' cacheL

Storyblok pricing trips up teams because the free tier is genuinely usable — until one specific limit hits and suddenly you're looking at a four-figure annual bill. This post breaks down every tier as of July 2026: what's included, what the hard ceilings are, and which usage pattern pushes you past each one. If you're comparing across the whole headless CMS landscape, I've already written a Headless CMS Pricing Comparison 2026 covering Sanity, Contentful, Payload, and Strapi side-by-side. This post zooms in on Storyblok specifically. How Storyblok structures its pricing Storyblok sells on three axes: seats (users who log into the Studio), locales (languages per space), and API calls (CDN requests to their Content Delivery API). There's also a fourth soft limit that catches people by surprise: the number of spaces (separate CMS environments). Pricing is per-space, not per-organisation, which matters for agencies managing multiple clients. All paid plans are billed per space per month, with annual billing being roughly 17–20% cheaper than monthly. Storyblok tier breakdown Plan Price (per space/mo, annual) Seats included Locales API calls/mo Custom roles Community (Free) $0 1 1 10,000 CDN calls No Starter $23 1 3 25,000 CDN calls No Growth $99 3 (then $15/seat) 5 1,000,000 CDN calls No Business $299 5 (then $25/seat) 10 Unlimited Yes Enterprise Custom Custom Unlimited Unlimited Yes + SSO Prices reflect Storyblok's published rates as of July 2026. Monthly billing adds roughly 20% to each tier. Community tier: the real limits The free Community plan is genuinely useful for a personal project or a proof of concept. One editor seat, one locale, and 10,000 CDN API calls per month. That 10k call limit is the thing most people underestimate. Every published story fetched from Storyblok's CDN counts as one call. If your Next.js site fetches 12 stories on the homepage, that's 12 calls per visitor. At 1,000 monthly visitors you've burned through 12,000 calls — already over the f

Over the last 14+ years, I've been working with the Microsoft technology stack, designing and delivering enterprise applications for procurement, inventory management, warehouse operations, and EPOS systems. As a Tech Lead, I've worked on projects involving: Procurement & Purchase Order Management Inventory & Warehouse Management EPOS integrations Accounting integrations REST APIs & Microservices Azure cloud solutions Performance optimization and secure application design While enterprise software has always been my primary focus, I've recently been expanding my work with Next.js, React, and TypeScript by building browser-based productivity tools. One of my goals is to build applications that are fast, privacy-friendly, and solve real business problems directly in the browser whenever possible. Some of the tools I've been building include: YAML Studio for Kubernetes, Docker Compose, GitHub Actions, Azure DevOps, Helm, Prometheus, and Grafana configuration generation. JSON ↔ Excel Converter with support for nested JSON, multi-sheet exports, and parent-child relationships. Multilingual OCR for business documents. PDF to Excel with structured table extraction. JSON Formatter & Validator. CSV, Excel, and other data conversion tools. One thing I've learned while building document-processing tools is that file conversion is the easy part. The real challenge is preserving document structure—detecting tables, handling multi-line descriptions, reconstructing wrapped product codes, and generating output that users can actually work with instead of spending time cleaning it up. My experience in procurement has made this especially interesting because Purchase Orders, Delivery Notes, Goods Receipts, and Invoices all have different layouts and business rules. Building reliable tools requires understanding both the technology and the business process behind the documents. Alongside application development, I'm also continuing to strengthen my DevOps knowledge with Docker, Azure D

When people hear about a new project scaffolding tool, one of the first questions they ask is: "Can I choose React Query or TanStack Query?" "What about pnpm instead of Bun?" "Can I use ESLint instead of Biome?" "Can I choose Radix instead of Base UI?" "Can I skip Tailwind?" These are reasonable questions. In fact, I asked myself the same ones while building create-notils . My first instinct was to make everything configurable. The more I thought about it, the more I realized I was about to build something I didn't actually want to use. The Configuration Trap Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library. Eventually the CLI starts looking like this: ? Which package manager? ❯ npm pnpm yarn bun ? Which CSS framework? ? Which ORM? ? Which auth library? ? Which formatter? ? Which icon library? ? Which deployment target? It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features. I Built the Tool I Wanted to Use One thing I've learned from building side projects is this: the first user should always be yourself. Every project I start today uses almost exactly the same stack: Next.js 16 React 19 Bun Tailwind CSS v4 shadcn/ui Base UI Biome TypeScript Turborepo (when needed) I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have. npx create-notils my-app A few seconds later, I'm writing features instead of answering prompts. Opinionated Doesn't Mean Closed There's an important distinction between opinionated and restrictive . Some tools hide their implementation behind abstraction

A birth-chart form looks simple: ask for a date, time, and place, then calculate. The interface may be simple. The input is not. 1992-11-01 01:30 does not identify one universal instant. It is a wall-clock reading that only becomes meaningful after you resolve the place, the historical time-zone rule, and any daylight-saving transition. If the time is unknown, inventing a convenient default can create chart features that were never supported by the user’s data. I ran into these problems while building AstroZen , a Next.js application that calculates a BaZi Four Pillars chart and a Western natal chart before generating an optional interpretation. The most important architectural decision was this: Calculation is an evidence pipeline. Interpretation is a separate layer. This post explains the calculation pipeline, the failure modes I had to remove, and why “unknown” must remain unknown. 1. A city name is not a coordinate Early prototypes often use a short city list or a default coordinate. That works for a layout demo, but it is not acceptable once location affects the result. Names are ambiguous: Paris can mean France or Texas. Springfield needs a state or region. Country abbreviations come in several forms. A valid city must resolve to both coordinates and a time-zone identifier. AstroZen sends the submitted city to Open-Meteo’s geocoding service, then scores the returned candidates against the requested country and optional region hint. It keeps the following structured result: type ResolvedPlace = { name : string ; region : string | null ; country : string ; countryCode : string ; latitude : number ; longitude : number ; timeZone : string ; // IANA, for example "Europe/Madrid" }; Candidate selection considers exact city-name matches, country matches, an optional region hint, and population as a small tie-breaker. Population never replaces the country check. The more important rule is what happens when resolution fails: if ( ! selected || ! countryMatches ( selecte

I shipped a Next.js 16 app on Cloudflare Workers via OpenNext. Not a demo. A real product with streaming chat, server components, D1 at the edge, and anonymous user sessions. Here is what broke, what barely worked, and what turned out to be surprisingly fine. The stack Next.js 16.2 (App Router) @opennextjs/cloudflare 1.19 D1 for SQLite at the edge Streaming chat via the AI binding (DeepSeek-V3 through a Workers proxy) React 19 Tailwind CSS 4 No auth wall, no OAuth, no database on the origin The site runs a few thousand sessions a week across ~30 persona pages, blog posts, guides, and learning content. Most pages are statically generated. The chat interaction is server-rendered components with streaming responses. What worked surprisingly well Static generation and ISR Pages, blogs, guides, persona pages — everything that does not need user-specific rendering — runs as static HTML at deploy time. Next.js 16 with generateStaticParams and fetch caching worked without modification. OpenNext handles the Cloudflare output format. The build step produces something Workers can serve. Revalidations are limited to Workers' cache API, but since most content changes at deploy time, I never hit that limit in production. The one caveat: revalidateTag() does not work the same way in a Workers runtime. Tags are Node.js memory constructs, and Workers are stateless. If you depend on tag-based revalidation for content updates, you need to either trigger deploys or accept stale-while-revalidate behavior from the CDN. D1 at the edge D1 was the least surprising part of the stack. SQL queries from Next.js route handlers feel like calling a regular database. Sessions store in D1, messages store in D1, and the latency is low enough that restoring a full chat thread from 30 messages takes under 200ms cold. The only sharp edge: D1 connections count against your Worker's concurrent request limit in development. With Next.js making its own fetch calls for compilation, I hit the D1 connection ce

Most “WordPress to Next.js” tutorials show you how to fetch posts from the WP REST API and render them in the App Router. That’s the easy 20%. The 80% that actually decides whether your organic traffic survives is everything around the content: your URLs, your redirects, your metadata, your sitemap, and your images. Get those wrong and you’ll watch impressions fall off a cliff two weeks after launch, right when everyone assumes the migration “went fine.” This guide is the checklist I wish every team ran before flipping DNS. It’s framework-accurate for the Next.js App Router, and it works whether your new backend is headless WordPress, a headless CMS, or flat files. The one rule that saves rankings Every decision in a migration comes back to a single principle: Nothing about how Google already sees your pages should change, except the parts you deliberately improve. Google ranks specific URLs based on their content, their metadata, and the links pointing to them. A migration is dangerous precisely because it’s tempting to change all three at once: new URLs, a “cleaner” content structure, redesigned templates. Do that and you’ve thrown away the signals every ranking is built on. The safe path is boring: same URLs, same content, same meta, just a faster, modern frontend underneath. Step 1: Inventory everything before you touch anything You cannot preserve what you haven’t captured. Before writing a line of Next.js, you need a complete, structured snapshot of the live site: every published URL, its rendered content, its SEO metadata, its images, and its internal links. This inventory becomes the source of truth for your redirect map, your generateMetadata , and your sitemap. This is the step most guides wave away with “export your content from WordPress.” In reality it’s where migrations break, because the default WordPress export (WXR) gives you raw post content, not the rendered HTML your page builder actually outputs, and it drops most of the SEO fields you need. If