LaunchPad

An autonomous agent that keeps your developer presence (personal portfolio and LinkedIn profile) in sync with what you ship, and knows when to skip.

Comment

Inspiration

LaunchPad was built to solve a problem that my teammate and I face personally as students. We're two students who build a lot, hackathon projects, side projects, coursework that turns into something real. And every time, the same thing happens. We ship it, we feel good about it for a day, and then it just sits in a GitHub repo forever. Our portfolios and our LinkedIn, the places recruiters and other people actually look, stay months behind what we've actually made.

We felt this most as students trying to show our work. The projects were done. The hard part was never the building. It was everything after: figuring out if a project was even worth posting, writing it up, updating the portfolio, drafting the LinkedIn post, and then doing all of it again for the next thing. So most of the time we just didn't bother, and our best work stayed invisible.

The tedious part isn't writing one post. It's the judgment call you have to make on every release: is this a real new project, an update to something already up there, or a small change nobody cares about? Making that call over and over is the friction we wanted gone. So we built an agent that makes it for us and then acts on it. We built the thing we needed ourselves, and now we actually use it.

Our agent not just updates your portfolio and linkedin, but as a little bonus, analyses your repo, builds a profile of who you are, your skills and projects and curates a "next project" suggestion as a hint for what you can build next to enhance your profile and sharpen your skills.

What it does

You publish a GitHub release. That's the only thing you do.

An agent wakes up on its own and runs a decision-first pipeline:

  1. It profiles the repo you shipped, the stack, the README, what changed.
  2. A Relevance Curator makes a real three-way decision, feature_new, update_existing, or skip, and explains why in plain language.
  3. On feature_new, it writes a portfolio card, generates an image, drafts a LinkedIn post in your voice, reviews its own draft, and opens a pull request that adds the card to your live portfolio site. Where auto-merge is on, it merges it too, so the site updates without you touching anything.

It remembers what's already featured, so it never posts the same project twice. And it will happily do nothing. A trivial release just gets a confident skip. That's the whole point. Most agents always do something. Ours knows when not to.

As a byproduct of what it already knows about your work, it can also drop a light suggestion for what to build next, based on your recent projects and interests. That part is a footnote, not the point. The decision to feature, update, or skip is the core. The next-build idea is just a small extra the agent gives you for free.

How we built it

The whole thing is event-driven and decoupled:

GitHub release → webhook → Pub/Sub → Cloud Run → ADK agent (Gemini 3.5 on Vertex) → Firestore

Every Google Cloud service is there for a reason:

  • Cloud Run hosts the ingestion and the agent. It scales to zero between releases and spins up when a webhook comes in, which fits a bursty, event-triggered workload like this with no always-on cost.
  • Pub/Sub sits between ingestion and processing. This is what makes the agent a real background worker. The webhook returns right away while the agent works asynchronously, and Pub/Sub's retries and dead-letter queue mean a temporary failure never gets silently lost.
  • Vertex AI (Gemini 3.5 Flash) runs the decision through Google ADK as a real LlmAgent with a structured output schema, so the curator returns a typed decision we can act on, not a wall of free text.
  • Firestore is the agent's memory and audit log: what's featured, the developer's profile, and every decision with its reasoning.
  • Secret Manager holds the webhook secret and the GitHub App key.

Every stage has its own error handling and fails safe. If the curator errors out for any reason, it defaults to skip, because the one thing worse than missing a post is publishing something nobody reviewed.

Challenges we ran into

The bug we learned the most from only showed up once it was actually running live. Publishing one release was somehow creating three decision records, one "feature" and two "skips."

It turned out GitHub fires three webhooks for a single release (published, released, and created), each with a different delivery ID. Our idempotency check was keyed on delivery ID, so all three got through. The first one featured the project, and the two right behind it saw it was already featured and decided to skip. Three Cloud Run instances running in parallel off one release.

The fix had two layers. First, only accept the published action. Second, behind that, an atomic per-release dedupe keyed on {repo}:{tag} using Firestore's create(), which throws if the document already exists, instead of a check-then-write. The duplicate webhooks land within milliseconds of each other, so a check-then-write still races. What got us was that this passed every unit test we had. We only caught it by running the real system.

The other challenge was scope. It's really tempting to keep adding features until the agent "does everything." We kept forcing ourselves back to one thing: make the decision genuinely well, and make it visible, instead of piling on stuff that would water down the core.

Accomplishments that we're proud of

  • A real agentic decision, not a rules table. The Relevance Curator is an actual ADK LlmAgent on Gemini 3.5 that makes a multi-way judgment and explains it. It also correctly skips trivial releases, which was the hardest thing to get right and the clearest sign it's actually reasoning and not just automating.
  • A fully hands-free loop. You publish a release and a new card shows up on the live portfolio with zero extra input. No editor, no manual commit, no redeploy.
  • An architecture built like a real system, not a demo. HMAC-verified webhooks, an async Pub/Sub backbone with a dead-letter queue, two layers of idempotency, fail-safe defaults, and secrets in Secret Manager. It's built to survive a bad network day.
  • We're our own first users. We built this for our own problem, and it runs on our own releases.

What we learned

  • The hard part of an agent is the decision, not the plumbing. And making that decision readable, with real reasoning attached to each action, is what makes it feel like an agent instead of a script.
  • Live systems surprise you in ways unit tests never will. The triple-webhook bug passed everything we threw at it.
  • Decoupling is what actually makes "runs in the background" true. Pub/Sub, isolating each stage's failures, and safe defaults are what turn a demo into something reliable.
  • Restraint is a feature. An agent that knows when to do nothing is more trustworthy, and honestly more useful, than one that always does something.

What's next for LaunchPad-AI

  • Safe editing of any portfolio, whatever shape it's in. Reliably updating arbitrary hand-written portfolios (JSX, Astro, a CMS) fully unattended is genuinely hard, and getting it wrong means breaking someone's live site. Our next step is a confidence-gated approach: auto-merge only when the agent is sure of the structure, and open a review PR the moment it isn't.
  • A voice that learns. Let the agent pick up each developer's actual tone over time by learning from the posts they keep, edit, or throw away.
  • More trigger surfaces. Beyond releases: a shipped npm or PyPI package, a merged milestone PR, a deployed tag, so the agent catches "this is done" signals wherever they happen.
  • A weekly digest mode. An optional second trigger that looks at the week's activity and proposes one summary post, for people who'd rather batch than post every release.
  • Smarter next-build suggestions. The agent already gives a light "what to build next" idea as a byproduct. We want to make it genuinely useful over time, based on the threads across everything you've shipped, while keeping it an optional nudge and not the main thing.
  • One-click portfolio bootstrap. For people who don't have a portfolio yet, generate a clean starter site the agent can keep in sync from day one.
  • Team and org mode. Roll individual developers' shipped work into a team or company "what we shipped" feed, so a whole org's public presence stays current on its own.

Built With

  • agentic-ai
  • ai-agents
  • autonomous-agents
  • cloud-run
  • docker
  • event-driven
  • fastapi
  • firestore
  • gemini
  • gemini-3.5-flash
  • generative-ai
  • github-api
  • google-adk
  • google-cloud
  • llm
  • pub-sub
  • pydantic
  • python
  • secret-manager
  • serverless
  • vertex-ai
  • webhooks
Share this project:

Updates