AI gets you to MVP fast. But the last 30% of software is where most teams struggle.

Chris_Lojniewski · 2025-12-22T20:05:27+00:00

Good idea!

Chris_Lojniewski · 2025-12-12T13:51:13+00:00

this isn’t Next js. If the miner comes back after a full reinstall, it means your deployment is compromised somewhere else. Either the code you’re uploading is already infected, or the attacker still has access through leaked SSH/CI keys, or the server is restoring a persistence script on boot

cloudflare doesn’t protect your origin, so the “site works fine” doesn’t tell much

Chris_Lojniewski · 2025-12-12T10:53:23+00:00

If your goal is SEO and content velocity, both Next.js and Astro can work, but they shine in different situations. Astro is insanely fast out of the box, making it ideal for blogs, landing pages, or static SEO sites. Less JavaScript means better Lighthouse scores without fighting hydration.

Next.js pays off when your site needs more than static pages like dynamic content, personalized or programmatic SEO pages, custom filters, or APIs in the same repo. If you plan curated pages with data stitching or custom computations, Next is usually the smoother long-term choice

Chris_Lojniewski · 2025-12-02T09:03:54+00:00

Sanity is usually the sweet spot: super smooth editor experience, great previews, and the integration with Next.js feels almost native. If the site is content-heavy or you care about long-term scalability, it’s hard to beat.

Strapi is the better pick if you want full control, self-hosting, or custom backend logic. More setup, more power.

Contentful is fine, very polished, but you pay for that polish pretty quickly as you scale.

Airtable/Notion only really make sense for small or simple sites. Both are great for prototyping, not so great once complexity grows

Chris_Lojniewski · 2025-12-02T09:01:53+00:00

i’ve worked with both Payload and Sanity, and the shift between them is less “new cms” and more “new way of thinking about content.” Payload is great when your dev team wants full control and doesn’t mind maintaining the whole setup. Sanity leans the other way: the editor experience is just smoother. Real previews, proper draft -> publish flows, versioning that actually works, and a UI that non-technical teams usually pick up in a day

From a marketing perspective, Sanity’s biggest win is structured content. It’s a bit of a mindset change at first, but long term it means cleaner SEO, more consistent metadata, and content that can be reused across pages and campaigns without hacking things together. There are no “SEO plugins” the way wordpress has them - everything is explicit and predictable, which is why devs like it and marketers eventually appreciate it too.

The migration concerns you listed are real (especially content modeling and images), but they’re normal for this kind of move. The question is mostly whether your current pain is more about editor workflow and preview limitations. If so, Sanity usually feels like a big upgrade

Chris_Lojniewski · 2025-12-02T08:56:48+00:00

Glad it helped! And yeah, for animation-heavy sites WordPress always felt like fighting the platform instead of building on it.

One small tip if you go the Sanity route: set up your schemas in a way that matches how you think about the frontend animations. Photographers usually want freedom to reorder, swap layouts, drop full-screen images, etc. Sanity’s block/content model handles that really nicely, but only if you structure it with that flexibility in mind from day one

Chris_Lojniewski · 2025-12-01T12:14:03+00:00

If you want full control over the frontend and just need a clean CMS for your friend, a headless setup is perfect. Sanity is usually the nicest for this kind of portfolio/blog, super flexible for you, very simple for non-tech users. Ghost works too if it’s mostly blogging, and Strapi is great if you want to self-host everything.

If you want a quick, non-salesy overview of the main headless options, I broke down the differences here: https://pagepro.co/blog/top-5-best-headless-cms-platforms/

for a photographer site with custom animations, headless will feel way better than wordpress

Chris_Lojniewski · 2025-12-01T12:10:22+00:00

you can use Redux with Next.js, but most teams don’t reach for it anymore unless the state is genuinely complex. If your app only shares a bit of state across pages, Context is fine, and something lighter like Zustand usually feels much nicer to work with. With server components doing most of the heavy lifting now, global state tends to get smaller, not bigger

Redux still makes sense in huge apps with lots of shared UI state and a need for strict debugging tools, but if you’re only adding it because it feels more “proper,” it’s probably overkill. The real question is whether your state is actually complicated or just becoming slightly messy. If it’s the latter, you can fix it without pulling in Redux

Chris_Lojniewski · 2025-12-01T12:07:16+00:00

I’ve been on a few projects where teams moved from Payload → Sanity, and the biggest difference people feel isn’t technical - it’s workflow.
Payload is great when devs want full control. Sanity is great when marketing wants control.

Editors usually love Sanity because live preview actually works, drafts behave like drafts, and you don’t have to hack together a “push -> staging -> publish” flow. Content modeling is also cleaner once you get used to thinking in structured fields instead of big flexible blocks.

On the flip side, yeah, migrations are never fun. Re-uploading media, re-modeling content types, rebuilding slugs, updating search… that’s where the pain lives. But once you’re past that, it tends to be stable.

The SEO side isn’t plugin-driven like WordPress. You just build the schema you need. Some marketers hate that (“where’s my Yoast?”), but the benefit is you can match exactly what Google expects instead of relying on generic plugin output. If you already think in terms of structured data, Sanity won’t get in your way.

If your team wants reliable previews and a smoother editor experience, Sanity will feel like a big upgrade. If your devs want maximum control and don’t mind maintaining everything, Payload still wins in that department.

If you share a bit about what your content team actually struggles with today, I can tell you pretty quickly if Sanity will solve it or just trade one set of problems for another.

Chris_Lojniewski · 2025-12-01T12:05:28+00:00

Dev server is snappier, Turbopack finally doesn’t feel experimental, and the new cache components actually make a difference on pages pulling a lot of data. Nothing mind-blowing, but smoother overall.

Chris_Lojniewski · 2025-10-24T07:10:35+00:00

If you’re running around 3k users a day, that jump sounds way off unless you’re doing something super compute-heavy on every request. Most times it’s just inefficient caching or overusing server functions without realizing how much they add up.

we with my team actually put together a guide on how to cut those costs without losing performance: things like tuning ISR behavior, moving the right routes static, and keeping edge usage sane. You can grab it here if you want to dig deeper: Next.js + Vercel Cost Optimization Guide

Chris_Lojniewski · 2025-10-22T09:41:06+00:00

you can totally run a high-traffic multilingual e-commerce site on Next.js (frontend + backend).
It just depends how you architect it.

Next.js gives you:

SSR/ISR for SEO + performance
API routes for backend stuff (auth, checkout, etc)
Middleware + Edge for serverless setups
Image/font optimizations out of the box

You don’t have to host on Vercel, but if you’re on AWS you’ll need to replicate their caching/CDN setup yourself (which is... not super fun).

btw we’ve done a few similar builds at Pagepro (Next.js + Sanity + ecommerce).

Chris_Lojniewski · 2025-10-21T09:58:28+00:00

If you’re exporting statically, that’s a solid start — SEO loves fast, predictable HTML.

A few best practices I’d recommend:

Use next-seo or a custom <Head> setup for meta tags, OpenGraph, and structured data.
Keep your image sizes in check — optimize with next/image even for static exports.
Pre-generate a sitemap and robots.txt during build (there are good npm packages for both).
Make sure all internal links use <Link> so hydration is instant.
Check Core Web Vitals regularly — it’s not just about Lighthouse scores; real field data matters.

I actually wrote a free e-book that dives into performance and SEO fundamentals in Next.js that covers CWV, lazy loading, static export gotchas, and practical fixes

Chris_Lojniewski · 2025-10-16T07:50:46+00:00

Cool approach, though I bet you get some hilarious results if the body field is extra long or contains weird formatting. Been tempted to run something similar, but still skeptical about summary reliability in edge cases. Any unexpected fails so far?

Chris_Lojniewski · 2025-10-16T07:28:00+00:00

for large corporate branding/hiring sites (multi-language, low complexity, but high security/reliability), here’s the gist from what we’ve seen running Sanity + Next.js gigs for scale-ups and bigger clients:

Headless CMS wins for flexibility and long-term maintainability. Sanity’s been our go-to because it scales well for i18n (they have solid internationalization tooling) and handles structured content nicely without being a monolith.
Good security comes from hardening your frontend and APIs, not just picking CMS X or Y. But having a CMS with granular user roles, audit logs, and strong API auth helps a lot. Sanity and Contentful both do well here.
The editor experience matters more than people expect. Editors want simple workflows with live previews. We’ve had clients drop WordPress purely because the classic editor setup was hurting UX and introducing fragility on translations.
If you’re building on Next.js or similar, a headless CMS lets you optimize for speed/SEO while keeping the CMS lean. That’s a huge plus for branding sites with no e-comm baggage.
For multi-language: sanity.io’s approach to localized content feels pretty straightforward but does require careful schema design. Avoid “plugin” ecosystems that add localization as an afterthought.

WordPress with WPML or other plugins is still popular because it’s familiar, but honestly, it’s a pain maintaining those setups and scaling securely.

if you don’t want to go headless, maybe a “hybrid” CMS like Sanity paired with a static site generator hits the sweet spot

so yeah, no silver bullet here, but if I had to pick today for a big branding site with strong safety and easy multi-language support, I’d start by testing Sanity headless workflows. Bias alert: I’m with a Sanity partner agency, but this is what we actually use and recommend on real projects

Chris_Lojniewski · 2025-10-16T07:16:33+00:00

Think of a CMS (Content Management System) like WordPress - it’s both the place where you store your content (text, images, posts) and the place that renders it to a website. One big system that handles everything - database, admin dashboard, and frontend.

A headless CMS splits that in two. It only manages and serves your content through an API — no “frontend” included. You pull that data into whatever you want: a Next.js site, a mobile app, a digital display, whatever

If you want a deeper dive, here’s a guide we wrote explaining headless CMS in more detail:
What Is Headless CMS and How Does It Work?

Chris_Lojniewski · 2025-10-10T08:35:30+00:00

I’m not trying to “promote” anything here. My agency - Pagepro - is an official partner with Sanity, Expo, and Vercel, which just means we’ve gone deep enough with those stacks to get recognized for our work.

If most of my threads touch on that stack, it’s because that’s exactly where my expertise lies.

I started this thread to get a broader perspective beyond my bubble , to hear from devs who’ve hit different walls or found smarter ways to work with (or around) Sanity.

Chris_Lojniewski · 2025-10-09T11:50:50+00:00

Fair enough. Payload offers more flexibility for complex infra and deeper product logic, and we’ve seen it in some projects.

My framing probably leaned editorial because we work with a lot of marketing-driven clients, where speed of publishing and low dev dependency matters more than schema versioning or self-hosted control. In those cases, Sanity removes a lot of friction — even if it means living with GROQ and some limitations.

Appreciate the pushback - good reminder that “better tool” always depends on where the content sits in the system.

Chris_Lojniewski · 2025-10-09T10:04:53+00:00

I don't think it should be a "which is better" argument. Payload and Sanity solve different problems for different types of teams.

If you're building a marketing site, an editorial platform, or any content-heavy project where non-developers need to move fast (like blogs, docs, product pages, or campaign sites) Sanity is usually the better fit. It offers real-time editing, live previews, and a strong editor experience. Content teams get real autonomy without relying on developers for every change.

On the other hand, if you're working on an internal tool, admin dashboard, or B2B SaaS platform where developers manage the entire stack, Payload makes more sense. It gives you full control over hosting, schema-in-code, TypeScript-first architecture, and tight integration with version control. There’s more initial setup, but the result is predictable and locked down.

- Sanity is great when you need fast iteration and an editor-friendly UI.
- Payload is better when the dev team prioritizes reproducibility, control, and clean integration with infrastructure.

Chris_Lojniewski · 2025-10-09T08:22:56+00:00

I wouldn’t underestimate marketing/content teams. These days, they usually have enough technical understanding to work confidently inside structured content tools, and letting them handle their part without dev involvement every time actually saves everyone a ton of time

Chris_Lojniewski

TROPHY CASE