Getting Started
Post your first journal
A journal is a progress update inside a live project. It helps you document what you worked on, what changed, what broke, what you learned, and what you plan to do next.
Your first journal does not need to be perfect. It only needs to be real. Devmaniac is built around visible progress, and journals are the main way to show that progress over time.
What is a project journal?
A project journal is a written update attached to a live project. Instead of letting your work disappear into private notes, commit messages, or memory, a journal keeps the story of your project organized in one place.
A journal can explain:
- What you built today
- What problem you solved
- What bug you found
- What feature you started
- What technical decision you made
- What you learned while building
- What you plan to work on next
Why journals matter
A finished project can show the result, but journals show the process. That process is often where the strongest proof of skill lives.
When someone reads your project journals, they can see how you think, how you solve problems, how consistent you are, and how your project improves over time.
This is useful for students, self-taught developers, hackathon builders, indie hackers, and anyone who wants to prove skill through real work.
Step 1: Open your live project
First, go to the live project where you want to post an update. Journals belong inside live projects, so make sure you already created a live project before writing your first journal.
If you have not created one yet, start with the previous guide: Add your first live project.
Step 2: Find the journal section
Inside your live project page, look for the journal or progress update section. This is where your updates will appear over time.
Think of this section as the timeline of your project. Every useful update you post makes the project easier to understand.
Step 3: Choose the journal type
Pick the type that best describes your update. This helps readers quickly understand what kind of progress you made.
- Progress: A general update about what you worked on.
- Milestone: A meaningful achievement or completed step.
- Bug fix: A bug you found and fixed.
- Deployment: A release, deploy, or production update.
- Architecture: A technical structure or system decision.
- Announcement: A public update or important notice.
- Failure: Something that did not work and what you learned.
Do not overthink the type. Choose the closest match and keep writing. The goal is to document progress, not freeze for ten minutes choosing a label. Classic developer trap. 😭
Step 4: Write a clear title
Your journal title should explain the update quickly. A good title makes your project timeline easier to scan.
Good examples:
- Set up the FastAPI backend structure
- Added Clerk authentication to the app
- Fixed profile image sync issue
- Deployed the first version to production
- Redesigned the live project page
- Connected PostgreSQL models for project journals
Avoid vague titles like:
- Update
- Day 1
- Worked on stuff
- Fixed things
Those titles do not help anyone understand the project.
Step 5: Explain what changed
In the journal body, explain what you actually did. Keep it simple, but include enough context that someone else can understand the update.
A strong journal usually answers:
- What did I work on?
- Why did I work on it?
- What changed after this update?
- What problem did I face?
- What am I doing next?
Today I added the first version of the live project journal system. The goal was to let users document progress inside each live project. I created the backend model, connected the create endpoint, and started building the frontend form. Next, I need to improve validation and show entries in a timeline.
That is enough. You do not need to write a novel. Clear beats fancy.
Step 6: Add images if helpful
If you have screenshots, diagrams, UI previews, bug screenshots, or architecture notes, add them to your journal.
Images make progress easier to understand. They are especially useful when you are documenting UI changes, bugs, deployment issues, or before and after improvements.
Step 7: Add code or technical notes when useful
If your update is technical, include a short explanation of the code or decision. You do not need to paste huge files. Focus on the important part.
Useful technical notes can include:
- Why you chose a database structure
- Why you changed an API route
- How you fixed a bug
- What caused a deployment issue
- What tradeoff you made
This makes your journal stronger because it shows your thinking, not only the final result.
Step 8: Publish the journal
After writing your update, publish it. Your journal will become part of the live project timeline and help visitors understand how the project is evolving.
Once published, the journal becomes another piece of your proof of work. One update may look small, but many updates over time create a strong public record of consistency.
What should your first journal be?
Your first journal can be simple. Do not wait for a huge breakthrough. Start by documenting the beginning.
Good first journal ideas:
- Why I started this project
- What I want to build first
- Initial tech stack and plan
- First backend setup
- First UI draft
- Project architecture plan
- Authentication setup
- First deployment attempt
Simple first journal template
Use this structure if you do not know what to write:
Today I worked on [feature or task]. I did this because [reason]. The main progress was [what changed]. I struggled with [problem], and I learned [lesson]. Next, I plan to work on [next step].
Example:
Today I worked on the project setup for my FastAPI admin dashboard. I did this because I need a clean backend structure before adding features. The main progress was creating the project folders, installing dependencies, and connecting PostgreSQL. I struggled with environment variables, and I learned why config files should be separated properly. Next, I plan to create the first user model.
Common mistakes
Avoid these mistakes when posting journals:
- Waiting until the update is huge
- Writing only “worked on project” with no context
- Posting once and never updating again
- Trying to sound smarter than the actual work
- Hiding bugs and failures completely
- Writing updates that nobody can understand
Bugs, blockers, and failures are not embarrassing when documented honestly. They show that you are actually building, not just collecting tech stack names like Pokémon cards.
How often should you post journals?
You do not need to post every hour. That becomes noise. A good rhythm is to post when something meaningful happens.
Post a journal when you:
- Build a feature
- Fix a bug
- Deploy a version
- Make a technical decision
- Change direction
- Learn something important
- Hit or solve a blocker
If you are actively building, a few useful updates per week is much stronger than one massive update every few months.
The goal
Your journal should answer one simple question:
What changed in this project, and what does that show about my progress?
If your journal answers that, it is useful.
Start small. Post your first update. Then keep building.