Marketing and Business Process Articles
Need help? Browse our articles or navigate to Search and Filter page to find specific information. Use shortcuts to these articles by product (Agilebars, Timebars and Costbars) from the Main Menu above..
Knowlegebase Home PageCopyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Project Portfolio Management is a strategic approach to managing multiple projects as a unified portfolio, ensuring they align with organizational goals and available resources. Think of it like managing an investment portfolio, but with projects instead of stocks.
Key reasons organizations invest in PPM:
- Strategic Alignment - Ensures projects support business objectives
- Resource Optimization - Better allocation of limited resources (people, money, equipment)
- Risk Balance - Maintains a healthy mix of high-risk/high-reward and safer projects
- Project Prioritization - Focuses resources on the most valuable initiatives
- Improved ROI - Better project selection and execution leads to higher returns
Basic steps to implement PPM:
Project Inventory
- List all current and proposed projects
- Gather key data (costs, resources, timelines, objectives)
Strategic Alignment
- Define organizational goals
- Score projects based on strategic fit
- Eliminate or defer misaligned projects
Resource Assessment
- Document available resources
- Map resource requirements
- Identify constraints and conflicts
Portfolio Selection
- Prioritize projects using consistent criteria
- Balance the portfolio for risk/reward
- Select the optimal mix of projects
Governance Structure
- Establish clear decision-making processes
- Define roles and responsibilities
- Create reporting frameworks
Costbars PPM Process - Get Started
After establishing your governance structure, you can follow the Costbars PPM process within the application to establish the Project Inventory, Resource Pool, Strategic Alignment Values, and associated metadata. It can take weeks or months to establish this data and achieve resource-loaded projects to run through the PPM process. For a detailed introduction to this process, see Introduction to Costbars Product Guide.
Steps to run through the Costbars PPM Process
When ready to begin using the PPM process in Costbars, see the Product Help Section.
Prioritize Projects (SV Score): Calculate Strategic Priority based on your Strategic Alignment Values and Order of Importance. SV Score ranges from 0-100, where 100 indicates perfect alignment with operational strategy.
Score Projects (Costbars): Evaluate projects using multiple data points including health indicators, costs, hours, Size vs Complexity metrics, and additional project metadata.
Level Resources: Optimize resource allocation by adjusting project start and finish dates. View resource demand changes across the timeline as projects are rescheduled.
Select Projects: Utilize the bubble chart visualization to filter projects based on SV Score and AE Score ranges. Run selection analysis to identify optimal project combinations.
Review Resource Demand: Analyze resource requirements for selected projects and make scheduling adjustments as necessary to optimize resource utilization.
Finalize Selection: Make final project selections or eliminations to achieve desired strategic outcomes and resource balance.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Timebars-Specific Functionality
Timebars is the resource scheduling and traditional project management application in the Timebars Ltd. suite. While it shares a common platform with Agilebars and Costbars — including the canvas, spreadsheet sync, cloud publishing, and data management features covered in Common Functionality Across All Products
Timebars adds a distinct set of capabilities built for Waterfall and traditional project management practitioners. This page covers those unique features: the flexible multi-level project hierarchy, the report-date-driven scheduling engine, the resource pool and allocator, resource supply and demand analysis, and task relationship and constraint management.
Table of Contents
- What Makes Timebars Different
- The Timebars Hierarchy
- The Timebars Scheduling Engine
- The Resource Pool
- The Resource Allocator
- Resource Supply and Demand Analysis
- Task Relationships and Constraints
What Makes Timebars Different
Timebars answers the questions that project managers live with every day: How do I allocate the right people across multiple concurrent projects? Which resources are over-committed and by how much? What happens to dependent tasks when I slip a deadline? Can I take on a new project given current capacity? It delivers a time-phased canvas where every bar is connected to a resource, a rate, and a schedule — and where the scheduling engine silently maintains the relationships between them as you work.
Where Agilebars uses lane-based Kanban progress to drive its calculations, Timebars uses the Report Date as its reference point: the engine knows which tasks are in the future (forecast), which straddle today (in progress with actuals accumulating), and which are done (fully closed out) — and it calculates dates, hours, costs, and percent complete accordingly across up to five levels of project hierarchy.
The Timebars Hierarchy
Configurable Hierarchy Depth
Timebars supports three hierarchy configurations, chosen to match the complexity of the work being managed. All three use the same colour-coded bar levels and enforce structural rules — you cannot place a Task directly under a Portfolio, or an Allocation anywhere except under a Task — so the hierarchy remains consistent regardless of which configuration is in use.
- 3-Level (Project → Task → Allocation): For simple or single-project scheduling where portfolio grouping is not needed.
- 4-Level (Portfolio → Project → Task → Allocation): The most common configuration, grouping multiple projects under a portfolio without the additional sub-project layer.
- 5-Level (Portfolio → Project → Sub-Project → Task → Allocation): For large, complex programmes where projects contain distinct work packages or phases that benefit from their own intermediate level.
Switching between configurations is a matter of whether Orange (L3) and/or Dark Grey (L1) bars are used — the underlying rules, colours, and rollup logic remain identical.
The Five Levels Explained
| Level | Colour | Role | Notes |
|---|---|---|---|
| L1 | Dark Grey | Portfolio | Groups related programmes and projects; not used in 3-level hierarchy |
| L2 | Green | Project / Programme | Present in all configurations; always represents a project |
| L3 | Orange | Sub-Project / Work Package | Optional; used in 5-level hierarchy for complex projects |
| L4 | Blue | Task | Present in all configurations; always represents a task or milestone |
| L5 | Gold | Allocation | Present in all configurations; always represents a resource assignment |
Costs and hours roll up automatically from L5 to L1 as allocations are created or modified, keeping every level of the hierarchy financially and temporally accurate without manual recalculation.
Allocation Bars: Scheduling Resources at the Work Level
The gold Allocation bar (L5) is the fundamental unit of resource scheduling in Timebars. Each Allocation sits directly under a Task and represents a single resource assigned to that work — carrying the resource name, percent allocation, pay rate, and calculated hours and costs. A single Task can have multiple Allocation bars, one per resource assigned, and each can span a different portion of the task's timeframe to model how resource effort is distributed across the work.
Allocation bars are created by dragging a resource from the Resource Allocator and dropping it onto a Task bar. Once placed, they can be repositioned and resized on the canvas independently of the parent Task, enabling front-loading and back-loading of effort within the task window without changing the task's start or finish dates.
The Timebars Scheduling Engine
How It Differs from Agilebars
The Agilebars scheduling engine is designed around workflow stages — progress is earned as tasks move through Kanban lanes, and the engine converts those stage transitions into burndown data. The Timebars engine works on a fundamentally different principle: it uses the position of each bar on the timeline relative to the Report Date to determine whether work is forecast, in progress, or complete, and it calculates planned, forecast, and actual values for dates, hours, and costs accordingly. This makes it suited to traditional project management where tasks have resource assignments, durations, and budgets that need to be tracked precisely over time — not just whether something has started, is in review, or is done.
The Report Date: The Engine's Reference Point
The Report Date (also called the Status Date) is the single most important parameter in the Timebars scheduling engine. Set once in Canvas Settings, it represents the point in time at which project status is considered current. The engine uses it to classify every bar into one of three states — future, in progress, or complete — and applies a different calculation model to each. Keeping the Report Date current as the project progresses is what keeps forecasts, actuals, and percent-complete values accurate throughout the project lifecycle.
Future Tasks: Forecast Mode
A task whose start date falls entirely to the right of the Report Date is a future task. The engine calculates forecast dates, forecast duration, forecast hours based on resource allocations and percent allocation, and forecast cost based on hours multiplied by pay rates. All values are projections — nothing has been incurred yet. Moving the bar left or right on the canvas immediately updates all forecast values, making it simple to model schedule changes and see their cost and effort implications before committing to them.
In-Progress Tasks: Actuals Plus Remaining Work
When a bar is positioned so that it straddles the Report Date — its start date is in the past and its finish date is in the future — the engine enters its most powerful mode. The start date is locked as an actual date (work has genuinely begun), while the finish date remains a forecast. The engine calculates actual hours and actual cost for the portion of work completed before the Report Date, remaining hours and remaining cost for the work still to be done, and percent complete as the ratio of actual to total work. This split between what has happened and what is still planned is what enables meaningful earned value analysis without any manual data entry.
Completed Tasks: Full Actuals
A task whose finish date falls entirely to the left of the Report Date is complete. Both start and finish dates are recorded as actuals, remaining duration and remaining work become zero, and percent complete is set to 100%. Actual hours and costs are calculated from the full task duration and resource allocation, providing a closed financial record for the work that flows up through the hierarchy into project and portfolio totals.
Hours and Cost Calculation
The engine derives hours from a straightforward formula applied to each Allocation bar:
Hours = Percent Allocated × Work Day Hours × Duration
For example, a resource allocated at 50% to an 8-hour workday for a 10-day task contributes 40 hours. Cost is then Hours × Pay Rate, where the pay rate is sourced from the resource's entry in the Resource Pool. Both values are recalculated automatically whenever the allocation bar is moved, resized, or its percent allocation is changed via the Hours Calculator — there is no separate step to trigger the update.
Front-Loading and Back-Loading Resources
Because Allocation bars can be positioned and resized independently within their parent Task's timeframe, resource effort can be deliberately concentrated at the start or end of a task rather than distributed evenly across it. A resource who does the bulk of the design work in the first week of a three-week task can be represented with a short, high-allocation bar at the beginning; a reviewer who provides sign-off at the end can have a brief Allocation bar at the task's conclusion. This granularity allows project managers to model how effort actually flows through a task, producing more accurate cost and schedule forecasts than tools that assume uniform resource distribution.
The Resource Pool
Named Resources
Named resources represent individual people — specific members of staff or contractors — identified by name and assigned a primary role and skill. Each named resource carries a workday calendar (hours per day), a default percent availability, and a pay rate. When allocated to tasks, the engine uses these values to calculate hours and costs for that individual's contribution. Over time, the collection of named resource allocations across all projects forms a complete picture of who is doing what and when — the foundation of reliable utilisation reporting.
Generic Resources
Generic resources represent pools of capacity rather than specific individuals: "Developer", "Infrastructure Engineer", "Finance SME". They carry a quantity value (e.g., 3.0 FTE of Developer capacity) rather than a single person's allocation, and their monthly availability values reflect the total FTE available from that pool. Generic resources are particularly valuable in the early planning stages of a project, before specific people have been assigned, and for modelling contractor or offshore capacity where individual identities are less important than the role and volume of work.
Why Both Matter
The combination of named and generic resources is what makes the Supply vs. Demand grids meaningful across the full project lifecycle. In early planning, generic resources define what capacity is needed by role and skill. As projects move into execution, named resources replace generic placeholders at the allocation level. The grids can show either view — individual utilisation or role-based capacity — by changing the Group By setting, giving resource managers and project managers the level of detail they need at any stage.
The Resource Allocator
Assigning Resources to Tasks
The Resource Allocator is a movable popup panel that lists every resource in the Resource Pool, with columns for name, role, skill, pay rate, and availability. Finding the right resource is a matter of typing in the search box or sorting by any column — by role to find all available developers, by skill to find a specific competency, or by default percent available to identify who has capacity. Once located, the resource is dragged from the Allocator and dropped onto any Task bar on the canvas, creating a new Gold Allocation bar beneath it instantly.
The Allocator also supports filtering by labour type — showing only named human resources, only generic pool resources, or both — and an expandable metadata view that reveals additional columns such as department, location, and secondary skills when needed.
Checking Individual Availability
Before committing a resource to a new task, double-clicking a resource row in the Resource Allocator overlays a row of yellow vertical bars at the top of the canvas, one per week in the current timescale view. The height of each bar represents that resource's percent allocation for that week across all current assignments — a bar at 50% means the resource is already half-committed, a bar at or above 100% means they are over-allocated. This visual check takes two seconds and prevents over-commitment without requiring a separate report or system.
For a more comprehensive view across all resources simultaneously, the Resource Allocator's Usage icon opens the full Supply vs. Demand grid — the same view accessible from the Reports menu.
Resource Supply and Demand Analysis
The Supply vs. Demand grids are the strategic resource management capability that sets Timebars apart from basic scheduling tools. Where most tools can show you what is scheduled, Timebars compares what is scheduled (demand) against what is actually available (supply) — month by month, role by role, person by person — and surfaces the variance in a format that is immediately actionable for resource managers, project managers, and executive leadership.
Supply, Demand, and the Variance Row
The grid is anchored by three summary rows at the top. The Supply row (blue) shows total available FTE from the Resource Pool, factoring in each resource's monthly availability values and their start and finish dates — so planned new hires contribute supply from the month they join, and departing resources drop off in the month they leave. The Demand row (green) shows total FTE required by all project allocations across the same time period. The Variance row (yellow) shows the difference: positive values (green text) indicate spare capacity, negative values (red text) indicate over-commitment.
The variance row is where resource decisions get made. A small negative variance for one month may be manageable with overtime; a persistent large negative variance across multiple months signals a structural capacity problem that requires hiring, descoping, or timeline adjustment. A consistently positive variance across several months is equally actionable — it points to headcount that could be redeployed, or capacity to take on additional project demand.
FTE vs Hours
The grids can be viewed in either FTE (Full-Time Equivalent) or hours. FTE is the default and preferred mode for strategic planning and executive communication — "we have a shortfall of 1.5 FTE developers in Q3" is a clearer message than a raw hours deficit. The hours view is useful for detailed tactical scheduling and billing analysis, where actual time values matter. Switching between the two is a single toggle; the underlying data is the same.
Monthly vs Weekly Views
The monthly view covers up to 24 months and is the right tool for portfolio planning, hiring decisions, and quarterly reviews — it smooths out short-term variation and aligns with the financial planning cycle. The weekly view shows demand at a granular level for the near term, identifying specific bottleneck weeks where a resource is briefly over-committed even if their monthly average looks healthy. Resource managers typically use the monthly view for strategic decisions and the weekly view for short-term levelling before a project milestone or phase kick-off.
Group By: Project, Resource Name, and Role
The Group By setting controls how demand rows are displayed below the summary rows, without affecting the supply totals. Three views serve different management needs:
- Group by Project — one demand row per project, showing how much resource capacity each project is consuming month by month. This is the right view for asking "which projects are driving our capacity crunch?" and "can we take on a new project given current commitments?"
- Group by Resource Name — one demand row per named individual, showing each person's project allocations across the timeline. This is the right view for workload balancing — identifying who is over-committed and who has capacity to absorb additional work.
- Group by Role — one demand row per role (Developer, Infrastructure Engineer, Finance SME, etc.), aggregating named and generic resources of the same function. This is the right view for skills-based hiring decisions: "we need an additional 0.5 FTE Developer from April through September."
Named and Generic Resources in the Grid
When viewing by Role, the grid combines both named resources assigned to that role and any generic resource pool entries of the same role into a single demand row. This gives a complete picture of role-based capacity — actual named individuals plus contractor or unassigned capacity — without requiring separate analysis. Supply totals always include both named and generic resources regardless of the Group By setting, ensuring the variance calculation reflects total organisational capacity.
Task Relationships and Constraints
Predecessor-Successor Relationships
Task relationships tell the scheduling engine that when a predecessor task moves, all of its successors must move by the same amount. A relationship is created by dragging the beginning of a task bar over the end of another and dropping when the red dashed box appears — the same gesture used to resize a bar, but directed at another bar. A connecting line between the two tasks appears on canvas when relationship lines are enabled via the Shortcut Menu.
The power of relationships is in cascading changes. Moving a predecessor task two weeks to the right automatically reschedules all successors — and their successors — by two weeks, propagating the change through the entire dependency chain without any manual adjustment. Hours and costs on affected tasks recalculate automatically based on their new positions relative to the Report Date. This makes Timebars behave like a real scheduling engine rather than a drawing tool: the plan stays internally consistent as changes are made.
Constraints: Pinning Tasks to Fixed Dates
A constraint overrides the relationship logic for a specific task, locking it to a date that must not change regardless of what happens to its predecessors. Constraints are created by dragging the red push pin from the canvas edge and dropping it onto a task; removing a constraint is a double-click on the pin. They are the right tool for tasks that are anchored to external realities — a regulatory deadline, a vendor delivery date, a go-live window that cannot move — where the scheduling flexibility that relationships provide should not apply.
When a constrained task's predecessors slip and the relationship would normally push the constrained task forward, the constraint holds. The resulting schedule shows the gap between where the predecessor ends and where the constrained task must begin, making the squeeze immediately visible on the canvas. Used sparingly and intentionally, constraints are a powerful way to model real-world scheduling boundaries without losing the benefits of relationship-driven planning everywhere else.
See the Timebars User Guide for detailed instructions on every feature covered on this page.
Copyright © 2025 Timebars Ltd. All rights reserved.
AI-Assisted Content Management Workflow
This guide is for customers who "Own theCode", explains how to manage and update the marketing and help article content on the Timebars website using the workflow established by Timebars Ltd. It is written for developers and content owners who have acquired the source code and want to continue maintaining and evolving the site's content with the same tools and process used to build it.
The workflow combines Claude Code (AI-assisted editing), Git branching, VS Code with GitHub integration, pull requests for review, and a deliberate manual step before production — giving you full creative leverage without sacrificing control over the live site.
Table of Contents
- How Content Is Organized
- The Content Management Workflow
- The edit-docsother Skill
- Registering a New Article
- Tips and Best Practices
How Content Is Organized
The site has two content layers, stored as Markdown files in the public/ directory and served through Strapi CMS. The files in public/ are the source of truth — Strapi is populated from them, not the other way around.
Marketing Articles (docsOther)
Location: public/docsOther/
These are buyer-facing articles: product feature pages, comparison guides, benefit explainers, FAQs, and blog posts. They are displayed in the /articles/ and /knowledgebase/ sections of the site. Filenames use lowercase kebab-case and the filename (without .md) is the Strapi slug.
Examples:
public/docsOther/common-functionality-across-all-products.md
public/docsOther/agilebars-specific-functionality.md
public/docsOther/costbars-specific-functionality.md
Help Articles (docsHelp)
Location: public/docsHelp/
These are user-facing guides: product user guides, reference documents, and how-to articles. Filenames use PascalCase with underscores. The Strapi slug is the lowercase kebab-case equivalent of the filename without the extension.
Examples:
public/docsHelp/Agilebars_User_Guide.md
public/docsHelp/Common_07_Cloud_Publishing_Guide.md
public/docsHelp/Costbars_PPM_Project_Assessment_Tool.md
The Slug Registry
Every article that appears in the Knowledge Base section must be registered in the slug registry at:
app/knowledgebase/page.jsx
This file contains arrays for each content category — commonFiles, agilebarsFiles, timebarsFiles, costbarsFiles, marketingCommonFiles, marketingAgilebarsFiles, marketingTimebarsFiles, marketingCostbarsFiles, and marketingBlogFiles. Each entry is an object with a name (display label) and slug (matches the Strapi slug):
const marketingCostbarsFiles = [
{ name: 'Costbars Benefits and Features', slug: 'costbars-benefits-and-features' },
{ name: 'Costbars Specific Functionality', slug: 'costbars-specific-functionality' },
// ...
]
When you create a new article, you add an entry here as part of the same commit. When you delete or rename one, you update or remove its entry here too.
The Content Management Workflow
The full workflow from idea to published article has seven steps. Steps 1–5 happen in your development environment; steps 6–7 are the production deployment.
Step 1: Open a Claude Code Session
Open the project in Claude Code — either the web app at claude.ai/code or the Claude Code CLI in your terminal. The project's CLAUDE.md file provides Claude with complete context about the codebase architecture, conventions, and content structure, so it understands the project immediately without needing a briefing.
For content work, the web app is often the most convenient: you can describe what you want written, review the output in conversation, iterate on tone and structure, and approve the final version before any file is touched.
Step 2: Work on a Feature Branch
All content changes should be made on a dedicated feature branch, not directly on main. Claude Code will create the branch for you if you ask, or you can create it yourself:
git checkout -b content/update-costbars-features
Working on a branch means the main branch always reflects the last reviewed, approved content state. It also means you can have multiple content work streams in progress simultaneously — one branch for a marketing update, another for a new help article — without them interfering with each other.
Step 3: Edit or Create Content with Claude Code
This is where Claude Code does the heavy lifting. Describe what you want — the topic, the audience (buyer vs. user), the source material to draw from, the level of detail — and Claude will draft the Markdown, edit an existing file, restructure a document, or fix a specific section.
For marketing articles, good prompts describe the business purpose: "Write a buyer-focused explainer for the Costbars PPM process, no step-by-step instructions, focus on the strategic value." For help articles, you can provide the technical content and ask Claude to turn it into clear user documentation with consistent structure.
Claude Code also handles the mechanical tasks: creating the file in the right location with the right filename, registering the slug in page.jsx, and writing a clear commit message. You review and approve each step.
The edit-docsother skill (see below) is a pre-configured context specifically for editing files in public/docsOther/. Invoke it with /edit-docsother in Claude Code to get the right conventions and link verification applied automatically.
Step 4: Review in VS Code with GitHub Integration
Once Claude Code has made the changes and committed them to the feature branch, open VS Code. The GitHub integration (GitHub Pull Requests and Issues extension, or the built-in Source Control view) lets you:
- Review the diff for every changed file before it leaves your machine — seeing exactly what was added, removed, or restructured
- Stage and unstage individual changes if you want to split a batch of edits across multiple commits
- Open a GitHub Pull Request directly from VS Code without switching to the browser
This review step is where you read the content as a human, check the links, verify the tone is right for the audience, and catch anything that needs adjustment before it goes through the PR process.
Step 5: Create a Pull Request
Push the feature branch and open a Pull Request against main. Claude Code creates draft PRs automatically when it pushes a branch; you can also create them from VS Code or the GitHub web interface.
The PR is your quality gate. It provides:
- A permanent record of what changed and why (the PR description captures the intent)
- A place to request review from a colleague or content approver before anything merges
- A diff view where reviewers can leave line-level comments
- CI checks (linting, build verification) that run automatically and catch any technical issues before merge
For solo content work you may self-review and merge quickly; for team content work the PR is where editorial review happens. Either way, nothing reaches main without passing through the PR.
Step 6: Merge and Copy to Production Manually
Once the PR is approved and merged to main, the Markdown files are correct in the repository. The production deployment step is deliberately manual for the website content: rather than having a CI pipeline push directly to the live site, you copy the updated .md files to the production server yourself.
Why manual? Because the production Next.js build is a running Docker container that you do not want to restart automatically every time a content file changes. A manual copy lets you:
- Choose exactly when the new content goes live (e.g., not mid-day on a busy trading day)
- Copy only the specific files that changed, with no risk of an unintended full redeploy
- Verify the files landed correctly before syncing to Strapi
- Keep the production build stable and under your control at all times
The typical approach is to scp or rsync just the changed .md files to the corresponding directory on the production server, or to SSH in and git pull the public/ directory from your repository if the server has a git checkout.
Step 7: Sync to Strapi via the Admin Panel
Once the .md files are on the production server, the final step is syncing them into Strapi CMS so the Next.js frontend can serve them. Log into the site as an administrator and navigate to the /sysadmin route. This admin panel provides file-by-file sync controls that read each Markdown file, create or update the corresponding Strapi record, and make the content available to the frontend immediately — no server restart required.
Sync only the files you changed in this deployment. The sync is idempotent: running it again on an unchanged file has no effect, but syncing a file that did not change is a harmless no-op.
The edit-docsother Skill
Claude Code supports skills — pre-configured instruction sets that give Claude the right context for a specific category of task. The edit-docsother skill is specifically for editing files in public/docsOther/ and encodes the conventions for that content type:
- Buyer-focused language (not step-by-step user instructions)
- Correct link format for help articles:
https://www.timebars.com/knowledgebase/helparticles/{slug} - Correct link format for marketing articles:
https://www.timebars.com/articles/{slug} - Slug verification against
app/knowledgebase/page.jsxbefore any link is written - Consistent heading structure and Markdown formatting
Invoke it at the start of a marketing content session:
/edit-docsother
You do not need the skill for docsHelp files — those are technical user guides where step-by-step content is appropriate and the conventions are straightforward.
Registering a New Article
When you create a new Markdown file, it will not appear in the Knowledge Base until its slug is registered. The process is:
- Create the file in
public/docsOther/orpublic/docsHelp/ - Note the slug: for
docsOther, the slug is the filename without.md; fordocsHelp, it is the lowercase kebab-case of the filename without.md(e.g.,Own_The_Code_Content_Management_Guide.md→own-the-code-content-management-guide) - Open
app/knowledgebase/page.jsx - Add an entry to the appropriate array:
{ name: 'Display Name for the Article', slug: 'the-slug-from-step-2' }
- Include this change in the same commit as the new file
Claude Code handles this automatically when creating new marketing articles. For help articles, you may need to prompt it explicitly: "Also register the slug in page.jsx."
Tips and Best Practices
Use the source files as the source of truth. Never edit content directly in the Strapi admin interface — those edits will be overwritten the next time a sync runs from the Markdown files. The .md files are canonical; Strapi is the delivery layer.
Keep commits focused. A commit that creates one new article and registers its slug is easy to review and easy to revert if something is wrong. A commit that updates fifteen articles is hard to review and a debugging problem if one of them has an issue.
Write for the audience, not the tool. docsOther is for buyers who are evaluating whether to purchase — they want to understand value and capability, not how to click through a UI. docsHelp is for users who already have the product — they want clear, accurate instructions. Claude Code will apply the right tone if you specify the audience clearly in your prompt.
Let Claude verify the links. Before asking Claude to write an article with links to other help or marketing articles, ask it to check app/knowledgebase/page.jsx first to confirm the slugs exist. A link to a non-existent slug produces a 404; verifying before writing avoids the problem entirely.
Draft PRs are your safety net. Claude Code opens PRs as drafts by default. A draft PR triggers CI and allows review but cannot be accidentally merged. Promote it to a regular PR only when you are satisfied with the content.
The manual production copy is a feature, not a limitation. The deliberate gap between merging to main and content going live means you always have a window to catch a problem that made it through review. A broken production deploy is recovered by reverting the file copy and re-syncing — no rollback of a container build required.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Download PDF Version of this Guide
Executive Summary
Timebars Ltd. is offering something most software companies never do: the full source code of a proven, production-ready project management suite.
The Timebars suite — Timebars, Agilebars, and Costbars — covers three disciplines that every project-driven organization needs: resource scheduling, Agile sprint planning, and project portfolio management. These are not prototypes or starter templates. They are running production applications, used in real businesses, built on a modern web stack.
We are now licensing the complete codebase, Docker container workflow, and the AI Integration workflow to organizations that want to own their planning infrastructure, customize it to their exact workflows, and hand it to their development team to shape around their business — without starting from scratch.
The Problem This Solves
Most businesses in professional services, engineering, and operations have gone through the same frustrating cycle:
- They try a generic SaaS tool. It works for simple use cases but can't accommodate their specific workflows, reporting needs, or data structures.
- They customize it — up to the limits it allows. Then they hit a wall. The tool wasn't designed for their niche. Workarounds multiply. Staff adapt their processes to fit the software, rather than the other way around.
- They evaluate enterprise alternatives. These are expensive, slow to implement, require specialist consultants, and still don't fit perfectly.
- They end up paying forever — for something that never quite works.
The result: they rent software indefinitely, accumulating subscription fees year after year, while the tool continues to dictate how their business must operate.
The source code licensing model breaks this cycle entirely.
The Solution
Buy the codebase. Own it. Deploy it. Customize it.
When a business acquires the Timebars suite source code, they receive:
- A working, deployable application — not a prototype, not a starter kit
- The full source code of three interconnected tools: Timebars, Agilebars, Costbars
- A containerized deployment pipeline that any competent DevOps team can run immediately
- The freedom to modify, extend, rebrand, and integrate the software as they see fit
- A codebase that any developer — aided by Claude Code — can navigate and reshape in days, not months
What's Included
The Three Applications
| Application | Discipline | Core Capability |
|---|---|---|
| Agilebars | Agile Sprint Planning | Backlog management, burndown charts, sprint scheduling, spreadsheet sync |
| Timebars | Resource Scheduling | Drag-and-drop resource allocation, multi-project scheduling, spreadsheet sync |
| Costbars | Project Portfolio Management | Business driver prioritization, portfolio analytics, project pipeline scheduling |
The Technical Foundation
The hard architecture work is already done. What a buyer inherits:
- Battle-tested data models — resource scheduling, sprint management, and portfolio structures designed for real-world production use
- Drag-and-drop scheduling engine — the most complex and time-consuming part of any scheduling tool; built and working across all three applications
- Two-way spreadsheet sync — deep integration that typically takes months to build correctly; included from day one
- Reporting and analytics layer — burndown charts, resource demand analytics, portfolio prioritization dashboards — all built out
- Modern web stack — Next.js 14, React, Tailwind CSS, MongoDB, Strapi CMS; a stack any competent developer will be productive in immediately
- Containerized deployment — Docker-based, CI/CD-ready, deployable to any cloud provider or VPS
Why Claude Code Changes the Economics
This is the factor that makes source code licensing viable for organizations that previously couldn't justify the cost of custom software development.
The traditional calculation: Custom software from scratch → senior full-stack team → six to twelve months → very high cost → still needs ongoing maintenance
The new calculation: Proven codebase + Claude Code → small development team → days to first customization → one-time acquisition cost → your team maintains it going forward
Claude Code can navigate an unfamiliar codebase, explain its structure, propose targeted changes, write tests, and accelerate feature development to a degree that was not possible with previous tooling. A small team — even one that isn't expert in every layer of the stack — can reshape a working application around their exact business requirements faster and more cheaply than has ever been possible before.
The practical result: Organizations that previously could not afford custom software can now make a one-time acquisition of a proven codebase and have it tailored to their needs for a fraction of what a build-from-scratch engagement would cost.
The Deployment Pipeline
The codebase ships with a professional, documented deployment architecture across three zones:
Zone 1 — Customer Development Environment
The buyer's development team starts with the source code. They use Claude Code to build custom features, modify workflows, and adapt the product to their specific requirements. Changes are committed to their own Git repository (GitHub or Bitbucket) and validated against a local staging environment before anything moves to production.
Zone 2 — CI Pipeline to Docker Hub
Every push to the repository triggers the CI pipeline — GitHub Actions or Bitbucket Pipelines. The pipeline builds the Docker image, runs automated tests and linting, then pushes the tagged, versioned image to Docker Hub. This is the clean handoff point between development and production. Nothing reaches the server without passing the pipeline.
Zone 3 — Production Environment
The production server pulls the latest image from Docker Hub and runs the three applications — Timebars, Agilebars, and Costbars — as separate containers. A reverse proxy (Nginx or Traefik) handles routing and SSL termination. A database (typically Postgres) persists data. The entire stack runs on whatever cloud host or VPS the buyer prefers: AWS, GCP, Azure, Hetzner, DigitalOcean, or on-premises bare metal.
This is a standard, recognizable architecture that any professional developer will understand immediately. There are no proprietary lock-in mechanisms, no exotic dependencies, no vendor-controlled infrastructure.
Key Benefits
1. Complete Control
The buyer owns the code outright. They can modify any aspect of the product — the data models, the scheduling logic, the UI, the reporting, the integrations. There are no API rate limits, no feature flags controlled by a vendor, no roadmap dependency.
2. One-Time Acquisition Cost
No per-seat fees. No monthly subscriptions that compound year after year. The acquisition is a capital expense, not an operating expense that grows indefinitely with headcount.
3. Data Sovereignty
The application runs on the buyer's own infrastructure. Their data never touches a third-party SaaS platform. This is significant for organizations with compliance requirements, data residency obligations, or simply a preference for keeping operational data in-house.
4. A Proven Foundation
The most common failure mode in custom software projects is underestimating the complexity of the core domain problems. The scheduling engine, the data structures, the spreadsheet sync — these are solved. The buyer is customizing a working product, not speculating about whether it can be built.
5. Fast Time-to-Value
Because the foundation is complete, the development effort is focused on customization, not construction. A small team with Claude Code can typically have a working customized version in days to a few weeks — depending on the depth of modification required.
6. White-Label and Rebrand Ready
The codebase can be rebranded for internal deployment, client-facing use, or as a component of a broader product offering. There are no licence constraints preventing this.
7. No Vendor Risk
SaaS tools can change their pricing, discontinue features, be acquired, or shut down. Owning the source code eliminates vendor dependency entirely. The product exists independently of Timebars Ltd.'s ongoing business decisions.
Who Should Buy
Professional Services Organizations
Consultancies, agencies, and managed service providers who run projects in ways that generic tools don't support. Typically these organizations have unusual billing models, client-specific reporting requirements, or project structures that force constant workarounds in standard SaaS tools.
The fit: They need a scheduling and planning foundation they can extend to match client requirements — and the ability to white-label or integrate it into their service delivery platform.
Engineering and Technical Operations Teams
Engineering firms, infrastructure teams, and specialist operations groups whose domain-specific requirements (resource classification, scheduling constraints, approval workflows) are never adequately served by horizontal SaaS products.
The fit: They want on-premises or private cloud deployment, custom scheduling rules specific to their domain, and integration with their existing operational toolchain.
Organizations Seeking to Exit the Subscription Treadmill
Companies that have calculated the long-term cost of per-seat SaaS subscriptions across their project management toolstack and determined that a one-time acquisition is economically superior — especially as headcount grows.
The fit: The economics become particularly compelling for organizations above a certain team size where per-seat costs are substantial and growing.
Organizations with Compliance or Data Residency Requirements
Industries or jurisdictions where data cannot reside on third-party platforms. Healthcare, legal, government, and financial services organizations frequently face constraints that make standard cloud SaaS unsuitable.
The fit: Self-hosted deployment on controlled infrastructure, with full visibility into the codebase and no hidden data flows.
Comparison: Subscription vs. Source Code
| Factor | SaaS Subscription | Source Code Licence |
|---|---|---|
| Upfront cost | Low | One-time acquisition fee |
| Ongoing cost | Per-seat, every month | Development team only |
| Customization | Limited to vendor-permitted features | Unlimited |
| Data location | Vendor's infrastructure | Your infrastructure |
| Vendor dependency | High | None after acquisition |
| Integration depth | Via available APIs only | Full codebase access |
| Branding | Vendor brand | Full white-label capability |
| Long-term economics | Costs grow with headcount forever | Fixed after acquisition |
| Compliance control | Depends on vendor certifications | Full control |
| Roadmap dependency | Entirely on vendor priorities | Your priorities |
Common Questions
Do we need to be expert Next.js developers? No. Claude Code significantly lowers the expertise barrier. A developer who understands JavaScript and is willing to work with AI tooling can navigate and modify the codebase effectively. Senior full-stack expertise accelerates the process but is not a prerequisite.
What support is included? The acquisition includes the codebase and documentation. Ongoing development support, onboarding assistance, and technical consulting are available — contact us to discuss.
Can we use it commercially or with clients? Yes. The licence permits commercial deployment and client-facing use. Talk to us about your specific use case.
What's the stack, and can we swap components? Next.js 14 frontend, Strapi CMS backend, MongoDB for application data, Postgres for production. Developers are free to adapt or replace components as their requirements dictate.
Is the deployment really as described? Yes. The Docker-based pipeline is the same infrastructure used in production. There is no gap between what is described and what is delivered.
What if we need help getting started? We are available by phone and email to discuss onboarding, technical questions, and custom implementation support.
The Investment Rationale in Plain Language
Most project management tools make you adapt your business to fit their software. The source code licence inverts that relationship entirely.
You get a working product. Your team — with Claude Code alongside them — shapes it to your exact workflows. You own it. You control it. You stop paying per-seat fees indefinitely.
The economics work because:
- The hard foundational work is already done — you're not paying to build from scratch
- Claude Code compresses the customization timeline dramatically
- One-time acquisition converts an open-ended operating expense into a bounded capital cost
- The productivity gains from a tool that actually fits your processes compound over time
The question is not whether this is cheaper than a SaaS subscription in year one. It is whether it is cheaper over three to five years — and whether a tool you own and control delivers more value than a tool you rent and cannot change. For the right organizations, the answer to both is clearly yes.
Contact
Jim Cox Timebars Ltd.
Phone: (613) 255-5374 Email: [email protected] Website: www.timebars.com/sales/ownthecode
We are available by phone or email to discuss your specific requirements, walk through the codebase, and provide a pricing proposal tailored to your organization.
Timebars Ltd. — Timebars · Agilebars · Costbars Resource Scheduling · Sprint Planning · Portfolio Management
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.
Copyright © 2025 Timebars Ltd. All rights reserved.