This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 3 (theme: Slow and Steady).
Sloths move slowly, conserve energy, and let the world come to them. Starting a new software project is the opposite: write the plan, the requirements, the architecture, the design spec, the backend, the frontend, the tests, the Docker files. Every time. Before the fun part even begins.
So for International Sloth Day week, I built SoftwareUnit: a virtual software team of 8 AI agents. I type one project idea, and the team hands me back a full project to review.
Repo: https://github.com/madhumitha-r26/SoftwareUnit_CrewAI
What I Built
SoftwareUnit is an automated software delivery workflow built on the open-source CrewAI framework, with Gemma running through Ollama. You give it a project idea, and it produces:
- planning and design documents
- a working application scaffold
- QA artifacts
- deployment files
All of it lands in an output/ folder.
Generated apps follow one fixed stack, so every agent works from the same technical contract:
- Frontend: React.js + Tailwind CSS
- Backend: Node.js + Express.js
- Database: MongoDB
- Deployment: Docker + Docker Compose
That stack requirement flows through architecture, implementation, QA, and deployment, so the frontend, backend, tests, and Docker files all agree with each other.
Meet the Crew
When started, the app asks for a project idea and runs these stages:
| # | Agent | What it delivers |
|---|---|---|
| 1 | Project Manager | Project plan |
| 2 | Business Analyst | Requirements and user stories |
| 3 | Solution Architect | MERN architecture and API contract |
| 4 | UI/UX Designer | Written design specification |
| 5 | Backend Developer | Node.js/Express API with MongoDB integration |
| 6 | Frontend Developer | React app styled with Tailwind CSS |
| 7 | QA Engineer | QA documentation and test artifacts |
| 8 | DevOps Engineer | Dockerfiles and Compose for frontend, backend, and MongoDB |
The backend and frontend tasks run asynchronously, so they build in parallel. QA and DevOps then take both outputs as context. Like a real team, the later roles build on what the earlier ones decided.
What Comes Out
output/
documentation/
01_project_plan.md
02_requirements.md
03_architecture.md
04_ui_design.md
05_qa_report.md
06_deployment.md
backend/ # Node.js/Express.js app + MongoDB integration
frontend/ # React.js + Tailwind CSS app
tests/ # QA and automated test artifacts
deployment/ # Dockerfiles, Docker Compose, related assets
A small file-writing tool in tools.py is scoped to output/, so the agents can only write inside that folder and not elsewhere on my machine.
Try It
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install crewai crewai-tools
python .\main.py
Enter a project idea when prompted, then check output/.
Demo
The Lazy Payoff
- By hand: It may take more than 2 days
- With SoftwareUnit: The Project will be done within 2-5 minutes
- Net: More hours will be saved for the project development
The honest framing: the output is scaffolding. It still needs review, configuration, and testing before production. But getting from a blank folder to a reviewable project in one prompt is exactly the kind of laziness I was after.
To run the generated application, update your credentials in both the frontend and backend code the agents generated.
Why Open Innovation Matters Here
-
CrewAI is open source. I can read how agents, tasks, and crews are wired and shape the workflow. Each role's goals and prompts live in plain Python (
agents.py,tasks.py), so changing how the team behaves means editing a file, not waiting on a vendor. - Gemma is an open-weight model, served through Ollama. The model is a single config line, so I can swap in another open model without rewriting the project.
- No per-token API bill to a closed provider, which matters when one run fires 8 agents and a lot of generation.
- The shared stack contract is mine to change. Swap MERN for another stack by editing the task prompts, and the same crew builds something different.
What I Learned
- Giving each agent one narrow role, with clear hand-offs, produced more coherent output than one do-everything prompt.
- Passing one stack requirement through every stage is what keeps generated code, tests, and Docker files consistent.
- Using the local LLM helps to execute the program with zero rate limits.
- A user interface will be created for this application that includes an input field for entering the project idea for making the output folder to get downloaded.
Clone it, give it your own project idea, and let the crew do the heavy lifting. Issues and PRs are welcome. Happy Hacktoberfest! 🦥
Top comments (0)