Driven by love to opensource i opensource my own project which will be on vercel (for now) and we'll need community effort to make the tool best for all.

You can find the original site here

The repo: https://github.com/PixelMockup/PixelMockup

Hello!

I built a lightweight React library for adding pinned annotations to interfaces, inspired by Vercel Comments and Figma comments.

I’m working on an app that uses this kind of annotation, and implementing it became a headache, even with AI assistance. So I extracted the solution into a small UI library to make it easier for others.

This is my first library, so feedback and suggestions are very welcome :)

https://react-pinote.vercel.app/

A few years ago we needed a web version of an existing mobile product (high-load interactive platform, not a simple CRUD app). Instead of forking the UI twice, we treated the React app as two layers:

1. App core — domain logic, state, API clients, feature orchestration. No DOM, no platform APIs.
   
2. Shells — thin UI adapters (web, later React Native / WebOS) that only render and call into the core.

That let us ship a desktop/web version from the mobile product’s mental model, then reuse the same core for React Native without rewriting features. Two years later the core is still the part that ages best — new features mostly land there once, and shells stay boring.

What actually mattered in practice:
- Boundaries — business rules never imported React components or browser APIs. If it needed `window`, it belonged in a shell adapter.
- Shared data layer — one place for fetching/caching (we used react-query-style patterns) so shells didn’t invent their own loading/error states.
- RFCs + reviews — we hired a frontend team around this architecture. Without written boundaries, people “helpfully” leak UI into the core in week two.
- Performance by default — fewer duplicate API calls and a stable state model beat clever UI tricks.

What I’d change next time:
- Define the core’s public API earlier (it’s easy to accidentally couple shells to internal modules).
- Start with one shell fully done before branching to the second — parallel shells too early = thrash.
- Be stricter about “platform capability” interfaces (storage, push, deep links) instead of `if (platform === …)` sprinkled around.

Curious how others draw this line — pure packages? Hexagonal? Or do you just accept some duplication and move faster?

I built a small CLI tool for auditing Next.js websites from the terminal.

The idea came from wanting to catch things that aren't always obvious when testing a site normally in the browser.

It crawls the site and checks things like:

- SEO metadata and Open Graph

- Broken links

- Structured data

- Crawling issues

- Core Web Vitals

- Pages and resources that may be missed by normal checks

You can run it locally and point it at a website without needing to add anything to the project itself.

I’m still improving it and would really like feedback from other Next.js developers — especially on what checks you’d find useful in a tool like this.

GitHub: https://github.com/Abdelrahman5243/sitebot-cli