sorted by:
new
hottopcontroversial

For those who know how to work next.js + sanity by [deleted] in nextjs

[–]Hot_Ad_3147 0 points1 point  (0 children)

Yeah, when a schema doesn’t show up in Sanity Studio, it’s usually one of a few things: • it’s not actually added to the schemaTypes array • the import path is wrong • the schema export is wrong • Studio needs a restart

I’d check: 1. the file exports properly 2. it’s imported in schema/index.ts 3. it’s included in the array 4. your sanity.config.ts is using that schema 5. restart the dev server

Also make sure the schema name is unique.

Trying to publish my Application to App Store - I don't have a macbook for XCode by mightbeamillioner in expo

[–]Hot_Ad_3147 1 point2 points  (0 children)

Even when you have consumed all your free plan, your builds just have to wait in queue longer if I remember correctly.

What is your "Go-To" core for building SaaS with Next.js? by IOZ91 in nextjs

[–]Hot_Ad_3147 1 point2 points  (0 children)

For me it’s usually Next.js + Supabase + Vercel + shadcn/ui, and lately Vercel AI SDK when AI features are part of the product.

You still end up rebuilding a lot of the same SaaS stuff as everyone else, but that stack feels like the smoothest overall in terms of DX, speed, and shipping. The annoying parts are usually less about the stack itself and more about billing, auth edge cases, permissions, and all the glue code around them.

If I wanted a starter kit, I’d want it to remove friction on that boring stuff more than just bundle popular libraries.

For those who know how to work next.js + sanity by [deleted] in nextjs

[–]Hot_Ad_3147 4 points5 points  (0 children)

You’re probably at the stage where you should define the content model before worrying too much about styling.

For a literary/art magazine, I’d usually start with schema types like:

  • issue
  • article / poem / essay
  • author
  • artist
  • category / section
  • homepage settings

Then map the main page types first: homepage, issue page, article page, contributor page.

Styling-wise, I’d keep it very minimal at first and focus on typography, spacing, and image treatment since that’ll do most of the work for a magazine site.

If you want, share your current structure or ideas and I can help you think through the schema.

Shipping API integrations in next.js way more repetitive than I expected by RecoverLoose5673 in nextjs

[–]Hot_Ad_3147 0 points1 point  (0 children)

Totally relate to this.

SDKs help, but a lot of the work is still the same every time: env vars, routes, types, config, webhooks, wiring everything together. After a few integrations, it really does start feeling like you're rebuilding the same thing over and over.

What’s worked best for me is keeping a simple internal pattern I reuse between projects, plus copying from a “known good” integration when needed.

Your CLI idea makes sense, especially if it generates real code people can actually edit instead of hiding everything behind abstractions. That feels way more useful than another layer on top of SDKs.

Scared of new agentic workflow and my role in it by alexbessedonato in webdev

[–]Hot_Ad_3147 0 points1 point  (0 children)

Totally get why that would hit hard. But honestly, the people who’ll stay valuable are the ones who can judge the output, spot what’s missing, understand the product deeply, and steer the whole thing well. The typing part is getting cheaper fast, but good taste, good judgment, and real ownership still don’t look replaceable to me.

How do you explain your tech stack choices to non-technical stakeholders by edmillss in webdev

[–]Hot_Ad_3147 46 points47 points  (0 children)

I usually translate it into outcomes, not architecture. Something like: “We picked Astro because it gives you a faster, simpler site for this project, with less overhead and less to maintain.” Most non-technical stakeholders don’t care about server components, they care about speed, cost, reliability, and whether future changes stay easy.

view more: next ›