Concepts
Live projects
A live project is an ongoing build on Devmaniac. It shows what you are building right now, how the project is changing, and what progress you are making over time.
Live projects are one of the core ideas behind Devmaniac. They are built for developers who do not want to wait until everything is perfect before showing their work.
What is a live project?
A live project is a project that is still being planned, built, tested, improved, paused, or prepared for release.
It can be a serious product, a learning project, a hackathon build, an experiment, a side project, or a portfolio project that is still evolving.
The goal of a live project is not to say:
This project is finished and perfect.
The goal is to say:
This is what I am building, this is why I am building it, and this is how I am making progress.
Why Devmaniac focuses on live projects
Many developers only show finished projects. That sounds good, but it hides most of the real work.
Real development includes planning, building, debugging, changing ideas, making tradeoffs, failing, fixing, deploying, and improving. A finished screenshot does not show all of that.
Live projects make the building process visible.
That matters because consistency and problem-solving are often stronger signals than a polished final page.
What a live project can include
A strong live project can include:
- A clear title
- A project goal
- A short description
- The current status of the project
- The tech stack being used
- GitHub, live demo, or video links
- Screenshots or images
- Progress journals
- Bug fix updates
- Deployment notes
- Architecture decisions
- Lessons learned while building
You do not need all of these on day one. Start with the basics, then add more as the project grows.
Live projects vs finished projects
A finished project focuses on the final result.
A live project focuses on the process.
| Live project | Finished project |
|---|---|
| Still being built or improved | Already completed or shipped |
| Shows progress over time | Shows the final version |
| Useful for documenting learning | Useful for showcasing results |
| Can include bugs, blockers, and decisions | Usually shows polished outcomes |
| Best for build-in-public work | Best for portfolio presentation |
Both are useful. Devmaniac supports both because real developer growth includes the journey and the result.
Examples of good live projects
A live project does not have to be huge. It just has to be real.
Good live project examples:
- Building a FastAPI admin dashboard
- Creating a full-stack portfolio platform
- Learning Redis by adding notification features
- Building a mobile app prototype
- Creating a hackathon project with a team
- Rebuilding an old project with better architecture
- Experimenting with AI features in a web app
- Improving an open-source tool
Bad live project examples are usually vague:
- Test app
- Practice project
- Random coding
- Learning stuff
Those can still be real projects, but the title and description need more context.
What makes a live project strong?
A strong live project usually has three things:
- Clarity: People can understand what you are building.
- Progress: The project shows updates over time.
- Honesty: The project does not pretend to be bigger than it is.
You do not need to sound like a startup founder raising a $50 million round. You need to explain the actual work.
Use journals to keep a live project alive
A live project becomes more valuable when you post journals.
Journals are progress updates inside the project. They help you explain what changed, what you fixed, what you learned, and what you plan to do next.
Good journal topics include:
- Built the first backend route
- Fixed an authentication bug
- Changed the database schema
- Designed the first UI version
- Deployed the first version
- Paused the project to rethink the feature set
- Completed the MVP
A live project without journals can look abandoned. Journals show that the project is active and evolving.
When should you create a live project?
Create a live project when you have something you are actively building or seriously planning to build.
Good moments to create one:
- When you start a new side project
- When you join a hackathon
- When you begin learning a new stack through a real project
- When you restart an old unfinished project
- When you begin building a portfolio project
- When you want public accountability
Do not wait until the project is perfect. If it is perfect already, it is probably not a live project anymore.
When should a live project become finished?
A live project can become a finished project when it reaches a clear stopping point.
That could mean:
- The MVP is complete
- The app is deployed
- The main goal has been achieved
- The project is ready to be showcased as final work
- You are no longer actively building major changes
Finished does not always mean perfect. It means the project has reached a meaningful version that can stand as completed work.
Common mistakes with live projects
Avoid these mistakes:
- Creating too many live projects and updating none of them
- Writing a vague title with no clear goal
- Adding fake or exaggerated tech stacks
- Never posting journals
- Waiting for perfection before sharing progress
- Using live projects as a dumping ground for random ideas
One active live project with real updates is stronger than ten abandoned projects with shiny titles.
The core idea
A live project should answer:
What am I building, why does it matter, and how am I making progress?
If your live project answers that clearly, it becomes proof of work.
That is the point of Devmaniac live projects.