The App Worked. The Launch Wasn't Ready. So I Built LaunchLazy

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

You know that moment when your project finally runs and you immediately feel like:

“Okay. Done.”

Then five minutes later:

• Did I leave a localhost URL somewhere?
• Is .env ignored?
• Did I document Python dependencies?
• Is there a build script?
• Is CORS too open?
• Did I actually explain how to run this project?

That was the problem I wanted to solve.

So I built LaunchLazy — a local launch-readiness auditor that checks a software project before deployment and tells you what deserves attention first.

The flow is simple:

Project Folder
     ↓
Deterministic Checks
     ↓
Score + Risks
     ↓
Qwen 2.5 via Ollama
     ↓
Explanation + Next Actions

LaunchLazy checks things like README quality, environment files, .gitignore, build scripts, tests, dependency files, localhost URLs, CORS settings, basic secret patterns, and deployment configuration.

It then gives a readiness score, priority level, affected files, recommended fixes, and a downloadable report.

The idea is not to replace a real security review.

It is simply to catch the boring things developers often forget before launch.

---

Demo

For the demo, I scanned another project instead of only testing LaunchLazy on itself.

It found:

• 28/100 readiness score
• High priority
• 7 automated risks

including missing build/test setup, undocumented Python dependencies, a hard-coded localhost URL, and missing deployment configuration.

---

Code

R-iddhi / launchlazy

Build LaunchLazy AI-assisted launch readiness auditor

LaunchLazy

LaunchLazy is an AI-assisted software launch-readiness auditor.

It scans a local software project, detects common launch risks, calculates a readiness score, and uses a local open-weight model through Ollama to explain what should be fixed next.

What LaunchLazy Does

LaunchLazy checks project structure and configuration for issues such as:

• missing README documentation
• missing environment variable templates
• missing or weak .gitignore
• missing build scripts
• missing test scripts
• missing Node lockfiles
• undocumented Python dependencies
• hard-coded localhost URLs
• risky wildcard CORS configuration
• possible hard-coded secrets
• missing deployment configuration

It then generates:

• detected technology stack
• frontend/backend component breakdown
• launch-readiness score
• prioritized risk list
• AI-assisted explanation
• downloadable Markdown launch report

Tech Stack

Frontend

• React
• Vite
• Axios

Backend

• Python
• FastAPI
• Uvicorn
• Requests

Local AI

• Ollama
• Qwen 2.5 3B

Project Structure

launchlazy/
├── backend/
│   ├── main.py
│   └── requirements.txt
├── frontend/
│   ├── src/
│   ├── package.json
│   ├── package-lock.json
│   ├── .env.example
│   └──

…

View on GitHub

---

How I Built It

The most important design decision was actually deciding what the AI should NOT do.

I did not want to send a project to an LLM and ask:

“Tell me everything wrong with this.”

That can easily become guesswork.

So LaunchLazy separates facts from reasoning.

Part	Job
Python scanner	Find what actually exists
Risk engine	Score verified findings
Qwen 2.5	Explain and prioritize
React dashboard	Show everything clearly

If requirements.txt is missing, normal code can detect that.

If CORS is set to *, normal code can detect that.

The AI only gets the findings after they are verified.

That became my favourite rule from this project:

Code finds the facts. AI explains why they matter.

I also optimized the scanner so the project filesystem is walked once instead of repeatedly searching the same folders for every check.

And I separated scanning from AI generation, so the user sees the score and risks first while Qwen prepares the explanation.

---

Why Does Open Innovation Matter?

LaunchLazy uses Qwen 2.5 3B through Ollama, locally.

That matters because project structure and configuration can contain information I would rather keep on the developer's machine.

Using a local open-weight model means:

• project evidence can stay local
• there is no per-scan hosted API cost
• the reasoning model can be replaced later without rebuilding the scanner

More importantly, it pushed me to think about where AI was genuinely useful instead of using it for every step.

---

The Lazy Payoff

Without LaunchLazy, the workflow is basically:

README → package.json → .gitignore → env files
→ source code → backend config → deployment files

With LaunchLazy:

Paste path → Inspect → Fix the important things first

I am not claiming it magically makes a project production-ready.

It just removes a lot of repetitive checking and gives the developer a much clearer starting point.

That is my version of Slow and Steady.

---

One slightly funny part of building this:

I eventually made LaunchLazy audit LaunchLazy.

And yes, it complained about my own project.

Which is probably a good sign. 😅

---

The biggest thing I learned was this:

An AI project does not become better by giving more work to the AI.

Sometimes the better design is:

Let software establish what is true.

Let AI help decide what to do about it.

And if that lets me be a little lazier before deployment, even better. 🦥