Built a LinkedIn Automation Tool and Survived 206 Commits Later 🫠

yo devs! 👋

so we just launched our first product (post0 - a LinkedIn automation tool) and honestly, the technical journey has been absolutely WILD. thought i'd share how we went from "let's just build a simple app" to accidentally creating a distributed nightmare that somehow actually works now lol

the "simple" beginning

started with what every student does - a good old monolith. one repo, one deployment, one massive headache waiting to happen. we were young, naive, and thought "microservices are just corporate overengineering" 🤡

post0-app/
├── frontend/
├── backend/
├── workers/
└── database/

seemed simple enough right? WRONG.

when everything went to sh*t

about 3 months in, our CI/CD started taking 20+ minutes. deployments were breaking constantly. one bug in the posting logic would take down the entire frontend. classic monolith problems hitting us like a truck.

the breaking point was when i pushed a "small fix" to the posting service and accidentally broke user authentication for 2 hours 💀

the great migration (aka going full microservices)

said f*ck it and decided to split everything up:

current architecture:

• posting-service (24 commits) - handles all the LinkedIn API magic
• notification-service (7 commits) - push notifications and email stuff
• frontend (162 commits) - next.js app that looks decent
• prisma-service (13 commits) - shared database schemas

event-driven with pub-sub model:

// when user schedules a post
await pubsub.publish('post.scheduled', {
  userId,
  postContent,
  scheduledTime,
  platform: 'linkedin'
});

// posting service picks it up
pubsub.subscribe('post.scheduled', async (data) => {
  await scheduleLinkedInPost(data);
  await pubsub.publish('post.status.updated', { ... });
});

the pain points (aka where we cried)

prisma schema syncing nightmare

sharing prisma schemas across services is... interesting. we tried:

• git submodules (hell no)
• npm packages (version hell)
• monorepo (back where we started?)

ended up with a separate prisma-service repo that publishes schema updates. not perfect but works.

vercel + github orgs = 💸

vercel doesn't deploy org repos on free tier. had to setup github actions to build and deploy:

name: Deploy Frontend
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v20
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID }}

azure deployment chaos

deploying 4 separate services to azure container instances while maintaining secrets, environment variables, and not going broke as students = pure chaos

what we learned (the hard way)

1. start simple, split when it hurts - monolith wasn't wrong initially, we just grew out of it
2. event-driven architecture is beautiful but debugging async flows at 3am is not
3. shared schemas are hard - there's no perfect solution, pick your poison
4. free tiers have limits but github actions + some creativity goes far
5. commit often - 162 commits in frontend repo saved our ass multiple times

current status: somehow working ✨

• all services deployed on azure
• frontend on vercel (through our CI/CD hack)
• pub-sub events flowing smoothly
• users actually scheduling LinkedIn posts without everything exploding

the real talk

was it overengineered for a student project? probably.
did we learn a ton about distributed systems, event-driven architecture, and deployment hell? absolutely.
would we do it again? honestly... yeah, but with better planning 😅

if you're building something similar, my advice: start with the monolith, split when you feel the pain, and don't be afraid to make mistakes. that's literally how you learn this stuff.

anyway, we're live on product hunt today if you want to check out what came out of this beautiful disaster: [link]

what's your biggest architecture fail? drop it in the comments, let's suffer together 🫡

tech stack for the curious:

• next.js + typescript (frontend)
• node.js + express (services)
• prisma + postgresql
• azure pub/sub + container instances
• github actions (CI/CD)
• vercel (frontend hosting)

Post0

ps: if you're also a student dealing with deployment nightmares, my dms are open. let's cry together 😭