Setting Up Your First Project Without Overthinking It

Oct 5, 2026

The blank state of a new time tracker is an invitation to design a system. Resist it. The first project should take ten minutes, and the only thing it needs to do is survive contact with a real week of work.

Here is a setup that holds up.

Pick a project that is already running

Not the one you are about to start — one that is halfway through, with real work happening this week. You will get usable entries immediately, and you will discover the awkward cases (the meeting that belongs to two projects, the half-hour of unplanned support) while they are in front of you rather than in theory.

Decision one: what counts as this project

Write the boundary down in the project description, in one sentence. “Everything billed to Acme under the Q4 statement of work.” “All work on the internal design system, including review time.”

This sounds trivially obvious and it is the single thing that makes reports trustworthy six months later. Without it, the boundary drifts: someone logs a sales call against the project one week, someone leaves it out the next, and the total becomes a number nobody will defend in a meeting.

Decision two: four or five tasks, no more

Tasks are the breakdown inside the project. Start with the coarse ones:

• Development (or design, or writing — whatever the core work is)
• Review and revisions
• Meetings and calls
• Admin and coordination

That is enough to answer “where did this project’s hours actually go?”, which is the question you will ask. You can split a task later if a total turns out to hide something interesting; you cannot usefully merge a taxonomy you already logged against.

If a fifth task is obviously necessary for your work — testing, deployment, client support — add it. If you are reaching for a seventh, you are describing a workflow rather than a reporting structure.

Decision three: billable or not

Set this at the project level if the whole project is one or the other, which it usually is. Mixed projects are the exception and they need the flag per entry, so the default matters: pick the one that is true more often, so a forgotten flag is right rather than wrong.

For internal projects, mark them non-billable and leave them that way. The point of tracking internal work is not to bill it; it is to see how much capacity it consumes.

Then log a week before you change anything

The instinct after two days is to reorganise. Don’t. A week gives you five working days of entries and, more importantly, one bad day where everything went sideways — that is the day that tells you whether the structure works.

At the end of the week, open the report and look for two things:

An entry you did not know where to put. That is a missing task, or a boundary that needs a clearer sentence.

A task with almost nothing in it. That is a category you invented rather than observed. Delete it.

What not to do on day one

Do not back-fill three months of history. Reconstructed time is guesswork with a decimal point on it. If you need a starting baseline, write the estimate down as an estimate, somewhere other than the time log.

Do not create every project you will ever have. Ten empty projects make the dropdown slow and the right choice harder to find. Add each one when work starts on it.

Do not build a naming convention yet. You need three or four projects before you can see what the convention should be, and renaming a handful later takes minutes.

After the first project

The second project takes two minutes, because you are copying the first. By the fourth you will have opinions about names and tasks that are grounded in actual reports rather than imagination — that is the right moment to tidy up.

The time tracking guide walks through the mechanics in Timecrack, and the demo instance is there if you want to try the structure before committing to it.