SYNAPSE: an AI SaaS product prototype for LinkedIn personal branding

Built May–June 2026

SYNAPSE is a web app for LinkedIn personal branding. It surfaces trending topics filtered to a professional niche, generates three post variations in the user’s voice with OpenAI, Gemini or Claude models, and learns the user’s writing style over time.

My role: built the SYNAPSE prototype hands-on, using Claude Code as an AI coding assistant. The first commit is dated 29 May 2026 and the last 20 June 2026.

Showing up on LinkedIn consistently, without hours of content work

The landing page states the problem from the user’s side: SYNAPSE “tracks what’s trending in your niche, writes posts in your voice, and helps you show up consistently — without spending hours on content.”

Its FAQ separates it from a general chatbot: “ChatGPT is a blank canvas… It’s a workflow, not just a prompt.”

Both are the product’s own framing. The problem has not been tested with users.

Ten supported niches, no users

SYNAPSE supports these niches, and trend discovery is filtered to the niche(s) the user selects:

• AI/ML Engineer
• Product Manager
• Software Engineer
• Founder
• Marketer
• Designer
• Data Scientist
• Consultant
• Recruiter
• Educator

SYNAPSE has no users and no user feedback. A landing page with a waitlist exists, but the product has not launched.

A workflow, not a blank prompt

The product is a sequence of steps, with the user’s approval as a hard stop before anything reaches LinkedIn.

1. Find trendsFiltered by niche
2. Generate 3 variationsIn the user’s voice
3. User edits3+ edits feed a style profile
4. User approvesNothing posts without it
5. Publish now or scheduleImplemented — not verified live

The last step depends on a LinkedIn posting permission that the committed code does not request (see the publishing gap).

What exists in the code, and what does not

Architecture

• Web appNext.js 16, React 19 and Tailwind 4
• APINestJS 11, documented with Swagger
• DatabasePostgreSQL 16, accessed through Prisma
• Queue and cacheRedis with Bull for scheduled jobs; trend caching
• AI providersOpenAI, Gemini (default) and Claude; gpt-image-1 for images
• PaymentsRazorpay subscriptions (not verified live); Stripe backend only

Feature status

Each feature is placed in one of four groups, based on what the committed code shows. The diagram uses the same four styles, and names the status in words.

• Implemented
• Implemented — not verified live
• Incomplete
• Not built

Five behaviours the code enforces

This section describes what the code does. Whether each behaviour was planned up front is not recorded.

1. Approval first. Every post needs an explicit action: publish now or schedule. The daily digest emails a draft (not verified live) and never posts.
2. Voice from settings and from edits. Alongside explicit tone and style settings, SYNAPSE records what users change in AI drafts. After at least three edits, the AI summarises them into a style profile that later prompts use.
3. An AI key per user. Users must provide their own AI API key unless an administrator grants access. SYNAPSE works with OpenAI, Gemini or Claude, and each plan has a monthly token limit.
4. Scheduled posts in a job queue. Scheduled posts wait in a Redis-backed queue (Bull delayed jobs) with three retries; not verified live.
5. Credentials encrypted at rest. LinkedIn tokens and user API keys are stored encrypted (AES-256-CBC).

A monorepo with a web app, an API and a job queue

The web app and the API live in one repository, organised as a monorepo (pnpm and Turborepo). There are Dockerfiles for both, and an automated pipeline (GitHub Actions) checks types, validates the database schema (Prisma) and runs a build; it has no test step.

Implementation details

• Sessions: after a user signs in with LinkedIn (OAuth), their session token (a JWT) is kept in an HttpOnly cookie, out of reach of page scripts.
• Token storage: LinkedIn tokens are encrypted (AES-256-CBC) before they are saved.
• Scheduling: scheduled posts wait in a Redis-backed job queue (Bull delayed jobs) with three retries; not verified live.
• AI output: generated posts are checked against a fixed schema (zod), and each request must return exactly three variations.
• Trend refresh: Hacker News and Google News are re-read every 6 hours and LinkedIn hashtag feeds every 8 hours, with Google News as the fallback for LinkedIn. Trends pass a heuristic relevance filter, then get AI scores for trend, saturation and opportunity.
• Brand DNA: once a user has made at least three edits to AI drafts, the AI summarises them into a stored style profile that later prompts use.

How the implementation changed, and what is still open

1. 29 May 2026: first commit. The README at the time said “You always approve and post manually — no auto-posting”, and the project’s CLAUDE.md said never to implement scheduled or automatic posting.
2. 4 June 2026: commits titled “admin page and few other changes” and “adding web files”.
3. 7 June 2026: a commit titled “major fixes” adds publish-now and user-scheduled publishing.
4. 20 June 2026: last commits. From here, users must provide their own AI API key unless an administrator grants access.

The documented implementation changed from manual posting to publish-now/schedule. Reason not recorded. Every post still needs an explicit publish or schedule action.

Known issues

• No automated tests.
• Documentation has drifted from the code. The project’s CLAUDE.md still says never to implement scheduled or automatic posting, although the code implements user-scheduled publishing; the README says Next.js 14, but the code uses 16.

No external impact: a portfolio prototype

SYNAPSE has no users, there is no evidence it has published a post, and it is not deployed.

What exists is the codebase: the features marked Implemented above, plus a landing page and waitlist that have not been launched.

SYNAPSE is kept as a portfolio prototype.

The content loop is built; reaching LinkedIn is not proven

What exists

• The core loop (trends, three variations, drafts, and edits feeding a style profile) is implemented in code.
• The build also includes long-form articles, image generation, plans, an admin panel, team invites and a leaderboard.

Not proven

• The step that would reach LinkedIn is implemented but not verified: the committed code never requests LinkedIn’s posting permission, and there is no evidence any post has been published.
• The payment and email features are either not verified live (Razorpay, the daily digest) or incomplete (Stripe).
• None of the features has had a real user.
• There are no automated tests, and the documentation no longer matches the code.

Check the riskiest dependency first

1. Check the riskiest dependency early. The trend-to-draft loop is implemented, but publishing to LinkedIn depends on a separate LinkedIn posting permission that the committed code never requested. Until that step is verified, no part of the product that reaches LinkedIn has been shown to work.
2. Validate the core loop before the layers around it. Plans, payments, an admin area and team features were built around a core flow of topic → draft → post, even though there were no users or user research to validate that flow.
3. Keep the documentation in step with the code. The project’s CLAUDE.md still says scheduled posting should never be implemented, while the code implements user-scheduled publishing, and there are no automated tests.