I'm currently building ContentPulse a cross-platform content analytics aggregator, from architecture to MVP.

Creators managing multiple social platforms (Instagram, LinkedIn, Twitter) are stuck juggling 3–4 different analytics dashboards. Each platform uses different terminology, measures engagement differently, and presents data in its own format. The result? Creators spend 30+ minutes per week just trying to piece together how their content performed or they give up and fly blind.

Developers building social media tools face the same chaos from the API side. Twitter's API v2, Meta's Graph API, LinkedIn's Marketing API each has different auth flows, rate limits, pagination styles, and data formats. You integrate once per platform. Every time.

ContentPulse is my attempt to fix both problems.

It normalizes metrics from multiple social platforms into a single, unified API and real-time dashboard. One integration. One response. One coherent picture of your content performance.

But I'm not just building a dashboard.

𝗜'𝗺 𝗱𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗮 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗴𝗿𝗼𝘂𝗻𝗱 𝘂𝗽.

𝗧𝗵𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗜'𝘃𝗲 𝗗𝗲𝘀𝗶𝗴𝗻𝗲𝗱:

→ Dual REST + GraphQL API sharing a single service layer REST for simplicity and Zapier-style integrations, GraphQL for power users who want to query exactly what they need

→ Extensible Connector Pattern adding a new social platform requires zero API version changes. Each platform implements a standard interface for auth, metric collection, and normalization

→ Token bucket rate limiting with IETF-standard headers (60 req/min) so developers can build adaptive clients that respect limits without guessing

→ Dual authentication API keys for server-to-server, OAuth 2.0 for user-authorized access

→ Cursor-based pagination on all list endpoints – because offset pagination breaks with real-time data

→ Monorepo with npm workspaces, Docker Compose for local dev (MongoDB 7 + Redis 7), and a GitHub Actions CI/CD pipeline

𝗧𝗵𝗲 𝗙𝗲𝗮𝘁𝘂𝗿𝗲 𝗜'𝗺 𝗠𝗼𝘀𝘁 𝗘𝘅𝗰𝗶𝘁𝗲𝗱 𝗔𝗯𝗼𝘂𝘁 𝗔𝗜 𝗖𝗼𝗻𝘁𝗲𝗻𝘁 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝘀𝘁:

Most analytics tools show you what happened. They don't tell you what to do next.

I'm building a single endpoint that distills 30 days of cross-platform analytics into a 30-second content brief what worked, what to post next, and when to post it.

The key design decision: no LLM dependency. The value comes from aggregation logic and product framing, not the model. Every recommendation will be computed from real MongoDB aggregation pipelines – fully deterministic, zero hallucination risk, testable, and fast. It identifies best-performing content types, optimal posting times, and engagement trends, then generates natural language recommendations using template logic.

A nudge before creation is worth more than a report after the fact.

𝗪𝗵𝗮𝘁 𝗜'𝘃𝗲 𝗗𝗼𝗻𝗲 𝗦𝗼 𝗙𝗮𝗿:

→ Authored a full Business Requirements Document, Technical Design Document, and Product Specification from scratch

→ Defined 57 user stories with acceptance criteria and test cases

→ Designed 4 user personas (Creator, Business Owner, Agency Manager, Developer)

→ Architected 7 REST endpoints + a full GraphQL schema

→ Currently developing the MVP React SPA dashboard with KPI cards, engagement charts, platform breakdowns, channel comparison, and the AI strategist view

𝗧𝗵𝗲 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸:

Node.js · TypeScript · MongoDB · GraphQL (Apollo) · Express · React · Redis · Docker · Jest · GitHub Actions

𝗪𝗵𝘆 𝗜'𝗺 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗧𝗵𝗶𝘀:

The social media tooling space is at an inflection point. Tools like Buffer, Hootsuite, and Sprout Social are evolving from scheduling utilities into platforms and the vehicle for that transition is the public API.

The biggest challenge isn't just exposing endpoints. It's designing an API that developers actually want to build on with clean authentication, consistent pagination, predictable rate limiting, and normalized data models across platforms.

ContentPulse is my answer to: "What should a modern, developer-friendly social analytics API look like?"

Every design decision from the connector pattern for extensibility to the dual API interface to the pre-aggregated snapshot strategy is made by asking one question: what would a developer building on this API need?

𝗪𝗵𝗮𝘁 𝗜'𝘃𝗲 𝗟𝗲𝗮𝗿𝗻𝗲𝗱 𝗦𝗼 𝗙𝗮𝗿:

The hardest part of platform engineering isn't the code. It's the API design decisions that are nearly impossible to change later pagination strategy, auth model, versioning, error format, rate limit headers. These are the decisions that determine whether developers adopt your API or abandon it after day one.

I'm documenting every one of these decisions as I go. Will share the full technical write-up once the MVP is live.

Building in public because I believe the best way to learn platform engineering is to build a platform. More updates coming soon.

If you're building developer platforms, thinking about API design, or working on analytics aggregation I'd love to connect and exchange ideas.

#BackendEngineering #APIDesign #GraphQL #NodeJS #TypeScript #MongoDB #PlatformEngineering #SystemDesign #SoftwareArchitecture #ContentAnalytics #BuildInPublic #MVP