Here's a preview of the desktop experience.

My goal wasn't to create another generic restaurant website—I wanted it to feel like a premium ordering app with an Apple-inspired aesthetic: clean, modern, fast, and designed to make ordering effortless.

I'd love to hear your thoughts. What would you improve?

🚀 Just launched Sanad AI!

A Next.js boilerplate to launch your AI copywriting SaaS in minutes.

✨ Features: • AI Sandbox • Bilingual tools • Responsive design

🌐 Live:https://sanad-ai1.vercel.app📦 Get Code:https://mohamedhorizon2.gumroad.com/l/sanad-ai

#BuildInPublic #Nextjs

Cryptinotes is a fully encrypted, self-destructing note-sharing application inspired by Privnote - a legacy tool for sending sensitive text that disappears after being read. Cryptinotes takes that same core idea and modernizes it: markdown formatting, encrypted file attachments, and granular controls over exactly how and when a note destroys itself.

Every note is encrypted client-side before it ever touches the server, and only decrypted client-side once the recipient opens the link. The server never has access to plaintext content - not the note body, not attachments, not even the note's contents at rest in the database.

Every note can be tuned to the sensitivity of what's being shared:

• Markdown support — format notes with headers, lists, code blocks, and other rich text instead of plain strings
• File attachments — attach one or more files, encrypted alongside the note body
• Read limits — configure how many times a note can be opened before it self-destructs
• Expiration windows — set a custom self-destruct timer independent of the read count
• Password protection — require a password (on top of the link's own key) before a note can be decrypted

Cryptinotes runs on Railway across three services:

• Application server — the Next.js app handling note creation, retrieval, and the client-side encryption flow
• Postgres database — stores encrypted note metadata and ciphertext
• Cron worker — handles scheduled cleanup independently of the main app

The cron worker enforces two cleanup rules. Attachments are deleted shortly after a note is opened rather than instantly, giving the recipient a window to actually download files before they're purged. Separately, any note that goes unopened for 30 days is automatically destroyed, regardless of its configured read limit or expiration settings.

File storage runs on Cloudflare R2 (S3-compatible), holding only encrypted attachment blobs that are meaningless without the client-side key.

I have been building this project for some time for myself. It is for mundane tasks, not an IDE and there are no extensions to install.

The tools included are a mock data factory, code analysis, code converter, code refactor, code generator, css framework converter, sql builder, regex generator, and a json formatter, self explamatory if you think about it. Specialized tools in there wn domain

The app uses firebase anonymous auth for some features that use redis for device sync and work with databses. The anonymous auth is also used for saving work to the firestore only if the you wants to. All the preferences are saved to localstorage and work drafts are saved to indexDB on the user's devices. I use free AI models from the Vercel AI Gateway and the Groq API, but i consider adding better models later.

Of course, for vibe coders this tool is useless. But for people who still code manually and would like to do things faster, it serves a purpose. Would you even consider using it?

We're building a multi-tenant B2B app on Next.js (App Router + Turbopack). We need to split it into a core + optional features, where each feature can be turned on/off per tenant from an admin panel via API (no redeploy) and tenants ideally shouldn't download code for features they don't have.

Hard constraint: it has to stay one deployment on DigitalOcean App Platform (one build, one container). No multi-app / droplet fleet.

What we've ruled out so far:

- Module Federation — effectively dead under App Router + Turbopack.

- Vercel Microfrontends / Remote Components — need multiple deployments + Vercel's platform, and don't actually solve per-tenant gating anyway (they split by team/route, not by tenant entitlement).

So we're leaning toward keeping it in-app:

- next/dynamic for code-splitting each feature into its own chunk

- a static plugin registry + slot/fill pattern so core never imports a feature directly

- server-side route denial (real 404) for tenants that don't own a feature

- reusing our existing tenant-config flags + policy guards for the runtime gating

Roughly 8–12 features would become "plugins," the rest stays core.

Questions for anyone who's done this:

1. Did you keep per-tenant feature toggling in a single app, or did you actually split deployments? Any regrets?

2. Any gotchas with dynamic Redux reducer injection / lazy slices per feature?

3. Is the "code-split but still in the build" reality good enough, or did stakeholders push for true isolation?

4. Better patterns I'm missing?

   Appreciate any war stories. Thanks!