How to Track a Day Job, Startup, and Side Project Without Mixing Them

If you have a day job and build something on the side, your work can blur together fast. The same GitHub account may hold company and personal projects. The same Drive account may hold work plans, startup notes, and private files. That becomes a problem when you need a review for your manager or a progress update for your cofounder. This guide shows you how to keep each part of your work life separate without keeping three different journals. Each one can stay useful and private.

One giant work log causes real problems

Imagine opening a report for your manager and seeing a note about your startup's pricing test. Or imagine sending a founder update that includes a private project from your employer. The work may be real, but it is in the wrong place.

Mixing work also makes your story harder to understand. At your day job, success may mean leading a team, improving a product, or meeting your level's goals. At a startup, success may mean finding users, shipping faster, or learning which idea to stop. A side project may be about craft, curiosity, or a small group of users. Those are different stories for different people.

Start with a separate Role for each work life

In Bloomly, a Role is a boundary around one part of your work. You might create Roles called “Day Job — Northstar,” “Startup — Pine Labs,” and “Side Project — Focus Timer.” Use names that make the choice obvious at a glance.

• Your day-job Role holds work for your manager, review, and promotion case.
• Your startup Role holds product choices, customer learning, launches, and business progress.
• Your side-project Role holds releases, user feedback, experiments, and lessons from building on your own.

The same skill can appear in more than one Role. You may show leadership at work and in your startup. That does not mean the private source material should move between them. Keep the work where it happened.

Connect GitHub with care

After you connect GitHub, choose which repositories Bloomly can use. Then choose the Role for each one. A company repository should go to your day-job Role. Your startup repository should go to the startup Role. A personal app should go to its own Role.

The “Use all repositories” option is helpful only when every repository available to Bloomly belongs to the same Role. If one GitHub account holds both work and personal code, choose repositories one at a time. That takes a little longer during setup, but it prevents a much bigger privacy mistake later.

• Use all repositories when the whole account belongs to one work life.
• Choose repositories one by one when the account mixes company and personal work.
• For a public project, pick the Role that owned your actual contribution.
• Check your employer's rules before saving any work-related information outside company systems.

Bloomly uses read-only GitHub access and does not read source code or diff patches. It can still use the pull requests, reviews, and closed issues tied to you to help you remember meaningful work.

Use the same rule for Google Drive

A Drive account may contain work from several contexts. Choose the specific files you are allowed to import through the iPhone's Files picker, then check that each imported artifact is in the correct Role.

Drive imports are selected files, not an all-account or background activity feed. Import an employer's permitted launch document into the day-job Role and a startup planning document into the startup Role. Do not assume that selecting a file also connects its folder or future edits.

Choosing a Drive file gives Bloomly a copy to process as an artifact. Its contents are read for that processing; this is not a metadata-only import. Check your employer's rules before sharing a file, and add the context needed to explain your own contribution.

Forwarded emails and shared files still need a home

You may forward a praise email, share a screenshot, or add a useful link. These items do not come from a repository or Drive folder that already has a Role. Check where they landed and move them if needed.

• Forward the useful message, not a long email chain full of private details.
• Give the email a clear subject when you can, such as “Pine Labs launch feedback.”
• Put screenshots and files in the Role where the work happened.
• Before using an item in a report, open it and confirm that it belongs there.

For example, a customer email about your startup belongs in the startup Role. A note from your manager about a company launch belongs in the day-job Role. The compliment may sound similar, but the audience and privacy needs are different.

Choose the Role before you type or speak

Some important details will live only in your head. You may want to save why you made a choice, what you learned from a hard conversation, or how a launch felt. Before you type or record a voice note, look at the Role shown in Bloomly.

• Day job: “I cut two features after Design and Engineering raised launch risk. We shipped the core flow on time.”
• Startup: “Three trial users asked for the same import tool. We moved it ahead of the dashboard work.”
• Side project: “The new setup screen confused first-time users. I will test a shorter version this weekend.”

These notes may use the same skill, such as planning or customer research. The Role keeps the people, goals, and source details from being mixed together.

Ask BloomBar from the right Role

“What did I ship this month?” should have a different answer for your job, startup, and side project. Open the Role you want before you ask BloomBar or create a report.

For your day job, you might ask which work best shows growth toward your next level. In your startup Role, you might ask what you learned from customer calls. In your side-project Role, you might ask what changed between two releases.

Check the sources before you copy an answer into an email, review, or update. If something appears in the wrong Role, fix the source mapping first. That helps future records go to the right place too.

A simple setup you can copy

• Create one Role for your employer, one for your startup, and one for your side project.
• Connect GitHub. Use the all-repositories choice only if every available repository belongs to one Role.
• Otherwise, choose each repository and its Role. Your choices save automatically.
• Import selected, permitted Drive files and check the destination Role for each artifact.
• Forward one test email and share one test screenshot. Confirm where both appear.
• Create one short note in each Role so the choices feel familiar.
• Ask one question in BloomBar and open the sources in its answer.

You do not need to set up everything on the first day. Start with the sources you use most. Add more only when they clearly help.

What about shared projects?

Sometimes a public library or shared project touches more than one part of your life. Put the original work in the Role that owned the contribution. If you later use the lesson somewhere else, write a new note about that new result.

For example, you may learn a better way to test prompts while working on a personal app. Months later, you may use the same method at your job. The personal project stays in its own Role. The day-job Role gets a separate note about the result at work. The skill can travel; the private work does not.

Keep employment rules in mind

Separate Roles help with organization, but they do not replace your employment agreement. Do not move company secrets, customer information, or private documents into a personal system if your employer does not allow it. Do not work on a side project with company devices or during company time when the rules forbid it.

When you are unsure, save less. A safe career note can still describe the skill you used and the result at a high level. You rarely need private code or a full internal document to remember what you accomplished.

A quick weekly check keeps the lines clean

Once a week, open each Role for a few minutes. Check new items, fix anything in the wrong place, and add a result that the original source could not know. You do not need to rewrite the week.

• Day job: check work you may use in a review or promotion case.
• Startup: check launches, customer lessons, and business decisions.
• Side project: check releases, feedback, and what you want to try next.
• Before sharing: make sure every source belongs to the audience that will see it.

The same month can tell three different stories

Suppose you had a busy May. At your day job, you helped recover a late launch. In your startup, you learned that customers wanted an import tool before a dashboard. In your side project, you shipped a smaller update and gained 200 users. All three are worth saving, but they should not appear in the same report.

Your day-job review might focus on how you aligned teams and protected the deadline. Your founder note might focus on the customer choice that changed the roadmap. Your side-project history might focus on the release, new users, and what you want to build next.

Keeping those records apart does not make your career story smaller. It makes each version clearer. When you later want to think about your growth across all three, you can compare the skills in private without copying the sources into the wrong place.

This is especially useful for founders with a full-time job. You can learn from both worlds while still respecting the line between them. The skill may be shared. The customers, coworkers, code, and private plans are not.

You can keep one private career record without turning every part of your work into one story. Give each job, company, or project its own Role. Send each source to the right place, and check the Role before you create or share anything. That small habit protects private work and gives every audience a clearer story. Your manager sees your employee work. Your startup keeps its own history. Your side project stays yours.