About LaunchKit

Inspiration for LaunchKit

I've competed in — and won — multiple hackathons, and the part that always hooked me was blitz-building: shipping something real in a compressed window. But every time, the same bottleneck showed up. I'd burn hours decoding judging criteria, researching what past winners submitted, and rewriting my pitch deck and Devpost copy while my repo sat half-finished at 2am.

Advice out there says teams should spend most of their hackathon on ideation and presentation. That never sat right with me. I feel like the build should be the hard part, not the submission paperwork.

I built LaunchKit for UiPath AgentHack because I wanted a repeatable launch pipeline: point it at a GitHub repo and a hackathon URL, and let automation handle the intel, analysis, and multi-channel docs so teams can stay focused on the product. With it, hackathon participants, software developers, and product teams can complete the paperwork and the hard work simultaneously, without any disruption.

What it does

LaunchKit takes two inputs — a GitHub repository URL and a hackathon event URL — and runs a full submission pipeline:

  1. Intel — scrapes the hackathon page and researches winner patterns to produce a structured judging brief.
  2. Code analysis — analyzes the target repo via server-side LLM or a UiPath coded agent that invokes an external coding CLI (Cursor, Claude Code, Codex, or Gemini CLI).
  3. Artifact generation — produces a readme, Devpost copy, demo script, social content, and blog draft, each quality-scored.
  4. Human review — a single approval gate in Maestro before anything is published.
  5. Publish — pushes approved artifacts to GitHub and prepares hackathon-ready output.

The whole flow is orchestrated end-to-end by UiPath Maestro BPMN — API Workflows for backend calls, coded agents for repo analysis, and Action Center for human sign-off.

How I built it

The architecture splits cleanly into three layers.

Backend (FastAPI on Render) — I built a REST API that owns pipeline state, LLM calls, and persistence. Intel gathering and artifact generation run through a unified LLM service that supports NVIDIA NIM and Google Gemini. Run state, artifacts, revisions, and quality scores are stored in Supabase as JSONB. The API exposes async endpoints (/intel?async=true) so Maestro doesn't block on long-running LLM work.

UiPath coded agents (uipath_coded_process/) — I developed the coding agent locally in Cursor using the UiPath Python SDK, tested it against the FastAPI backend, then deployed it into UiPath Automation Cloud. The analyze_with_coding_agent entry point shallow-clones the target repo, shells out to the Cursor CLI (or another supported coding tool), normalizes the response into structured CodeIntelligence, and POSTs it back to /analyze/submit. Separate coded agents proxy the generate step.

Maestro BPMN orchestration — In UiPath Labs, I wired a Maestro workflow that coordinates the full journey: create run → intel → analyze (coded agent) → generate → human review → publish. API Workflows handle the HTTP integration; coded agents handle repo analysis; Action Center is the only place a human needs to step in.

I also built scripts/pipeline.sh as a curl-based smoke test so the pipeline can be validated without Maestro during development.

Challenges I ran into

Orchestration vs. latency — LLM calls for intel and generation can take minutes. Maestro workflows time out if you block on them synchronously. I had to design async intel endpoints and polling patterns so Maestro could kick off work and check status without hanging.

Bridging external coding CLIs into UiPath — Getting Cursor, Claude Code, and other CLIs to run inside a UiPath coded agent — parse their varied output formats, normalize into a strict schema, and submit back to the API — took real iteration. Each CLI returns JSON differently; building a normalization layer that handles fenced markdown, envelope wrappers, and partial responses was one of the harder pieces.

Local dev vs. cloud runtime — The coded agent is built and tested locally, but production runs entirely inside UiPath Labs. Keeping api_url, secrets, and run state consistent across local uipath run, Render deployment, and Maestro invocations required careful environment management and clear documentation.

Supabase permissions — PostgREST returned permission-denied errors until the schema grants were applied correctly. A small thing, but it blocked the entire pipeline until fixed.

Scope control — Hackathons tempt you to build everything. I had to keep the pipeline focused: intel → analyze → generate → approve → publish. Not a general-purpose agent platform — a launch pipeline for one specific, painful workflow.

Accomplishments that I'm proud of

  • Full E2E orchestration in Maestro — one BPMN workflow from repo URL to publish-ready artifacts, with a single human approval step.
  • External coding agent integration — LaunchKit doesn't just call an LLM API for code analysis; it invokes real developer CLIs through UiPath coded agents, wired to the same tools I already use day-to-day.
  • Self-documenting demo — the pipeline can analyze its own repository with Cursor and generate Devpost copy that describes the coding-agent orchestration it just ran.
  • Provider flexibility — the LLM layer supports NVIDIA NIM and Gemini with a single abstraction, so the backend isn't locked to one vendor.
  • Quality-scored artifacts — every generated output gets a score and feedback before it reaches human review, so the approval gate is reviewing ranked work, not raw drafts.

What I learned

  • Maestro is the glue, not the brain — the real intelligence lives in the FastAPI backend and the coding agents. Maestro's job is to coordinate HTTP calls, invoke agents, and hold the human gate. Keeping that separation clean made the system easier to debug and demo.
  • Async-first for agent pipelines — any workflow that chains LLM calls needs non-blocking triggers and explicit status polling. Designing the API around Maestro's constraints from the start saved a lot of rework.
  • Coded agents are a deployment boundary — building the agent locally in Cursor and migrating it into UiPath Labs is a real workflow. The UiPath SDK and CLI (uipath init, uipath run) make that loop tractable, but you have to treat local and cloud as two environments with one codebase.
  • The best automation targets repetitive judgment calls — decoding hackathon criteria, matching tone to past winners, and reformatting the same project story across five channels is exactly the kind of work LLMs plus orchestration should own.

What's next for LaunchKit

  • Richer hackathon intel — deeper Devpost integration and track-specific brief generation so artifacts are tuned to individual judging rubrics, not just the event page.
  • Revision loop in Maestro — wire the existing /artifacts/{type}/revise endpoint into the BPMN workflow so judges' feedback triggers a re-generation step without leaving the orchestration.
  • Multi-repo and team support — handle monorepos, multiple contributors, and team-specific artifact variants (e.g. technical readme vs. judge-facing summary).
  • Analytics and retrospective — the schema already supports metrics and retrospectives; the next step is closing the loop post-publish with engagement data and a generated "what worked" report.
  • Broader launch contexts — the pipeline is hackathon-focused today, but the same pattern — requirements, competitive intel, multi-channel docs — applies to product launches, open-source releases, and internal innovation programs.

Built With

Share this project:

Updates

Submission history