How is task duration calculated?

Duration is the number of calendar days between the start and end dates, inclusive of both. The builder parses the two dates, computes the difference, and shows the result in days for every task.

Can I show dependencies?

Yes. Each task has a 'depends on' field where you name the predecessor task. The outline prints the dependency next to the task so reviewers can see the critical path at a glance.

What is a milestone in this tool?

A milestone is a zero-duration checkpoint marking a key deliverable, like a launch or sign-off. Tick the milestone box and the task is rendered with a marker so it stands out in the timeline.

Does it sort tasks by date?

Yes. The generated outline sorts tasks by start date so the timeline reads top-to-bottom in chronological order, even if you entered them out of sequence.

Is this a real Gantt chart?

It is a text-based Gantt outline — phases, tasks, dates, durations, and dependencies in copy-friendly form. It is ideal for plans, emails, and tickets where an image chart would be overkill.

What is the Project Timeline / Gantt Outline Builder?

Creates a structured project timeline with phases, tasks, owners, start and end dates, computed durations, dependencies, and milestone markers — formatted as a clean text outline you can copy into any tool. It runs free in your browser on Gera Tools, with nothing uploaded.

Project Timeline / Gantt Outline Builder

Name: Project Timeline / Gantt Outline Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A project timeline you can paste anywhere

Heavyweight Gantt tools are overkill for many plans. This builder turns a list of tasks — with owners, dates, dependencies, and milestones — into a clean, chronological text outline that drops straight into a doc, ticket, or status email, with durations computed for you.

How it works

Each task records a name, owner, start date, end date, an optional dependency, and a milestone flag. The tool parses the start and end dates and computes the inclusive duration in calendar days. It then sorts all tasks by start date so the timeline reads in order, and renders each line with its dates, duration, owner, and any dependency. Milestones are marked distinctly because they represent checkpoints rather than work spans. The output is plain text, so it survives copy-paste into any tool without formatting loss.

What belongs in a project timeline

A useful timeline distinguishes between four types of entries:

Tasks are the work items that consume calendar time — design, build, test, write, configure. Each task should have a clear start and end date and a single owner. If a task has no owner, it will not get done.

Milestones are zero-duration checkpoints that mark the completion of a phase or the delivery of a key output: “requirements signed off”, “staging deployment complete”, “go/no-go decision”, “public launch”. Milestones make the critical path visible in a timeline and give stakeholders unambiguous checkpoints to discuss in status meetings.

Dependencies link tasks to their predecessors. A dependency is what makes a timeline a plan rather than just a list of dates. When a dependency is visible in the timeline, teams can immediately see whether a slip in an early task threatens a later milestone without having to trace the logic themselves.

Phases group related tasks under a label — Discovery, Design, Build, Test, Launch. Breaking a long timeline into phases makes it easier to read at a glance and to communicate status to stakeholders who do not need task-level detail.

Building a realistic timeline

The most common timeline failure is entering optimistic estimates for every individual task without accounting for the sequential dependencies between them. A few disciplines that help:

Add buffer at phase boundaries. If Design is scheduled to end on a Friday and Build starts Monday, any overrun in Design compresses Build by exactly the number of days it runs over. Adding a two- to three-day buffer between phases absorbs minor overruns without cascading into the next phase.

Front-load the long-lead items. Legal review, procurement, stakeholder approvals, and external dependencies (third-party integrations, vendor deliverables) all have lead times that the team cannot compress. Put them as early tasks so they run in parallel with work the team controls, not as prerequisites that block the final stretch.

Schedule the milestones first. Before entering tasks, enter the milestones that are non-negotiable — a launch date, a board presentation, a regulatory deadline. Then work backward to find what each preceding phase needs to deliver and when it needs to start. This reveals timeline feasibility before you commit to anything publicly.

Illustrative example structure

For a simple software feature launch:

Phase 1: Discovery (2026-07-01 → 2026-07-10, 10 days)
  Task: Requirements definition   | Owner: PM     | 2026-07-01 → 2026-07-05
  Task: UX wireframes             | Owner: Design | 2026-07-06 → 2026-07-10
  ★ MILESTONE: Requirements signed off | 2026-07-10

Phase 2: Build (2026-07-13 → 2026-08-01, 20 days)
  Task: Backend API               | Owner: Eng    | 2026-07-13 → 2026-07-22 | Depends on: Requirements
  Task: Frontend integration      | Owner: Eng    | 2026-07-23 → 2026-08-01 | Depends on: Backend API

Phase 3: Launch (2026-08-04 → 2026-08-08)
  Task: QA sign-off               | Owner: QA     | 2026-08-04 → 2026-08-06
  Task: Staging deployment        | Owner: Eng    | 2026-08-07 → 2026-08-07
  ★ MILESTONE: Production launch  | 2026-08-08

Practical tips

Use ISO dates (YYYY-MM-DD) for unambiguous parsing across locales.
Name the dependency exactly as the predecessor task name so the critical path is easy to trace.
Include a named owner on every task — shared ownership defaults to no ownership when things get busy.
A task running 2026-07-01 to 2026-07-05 shows a duration of 5 days (both ends counted inclusively).
The plain-text output is safe to paste into email, Slack, Confluence, Notion, or a GitHub issue without losing formatting.