Where the margin goes in client development work
A development company rarely loses money on the code. It loses it around the code: the fixed-price build that took a third longer, the support hours that ran past the retainer, the change agreed in a chat thread and never priced, the estimate made without looking at what the last similar project really took.
The issue tracker cannot answer those questions, because it counts tickets and story points, not money. Accounting cannot answer them either, because it sees invoices, not hours. The answer sits between the two, and in most companies it lives in a spreadsheet someone updates at month end.
What to track outside the backlog
- The fee or budget of each client project, fixed or time and materials.
- Hours by person against the estimate, at the level you estimated: phases or features, not every ticket.
- Change requests with a decision: included, billed as extra, or declined.
- Support retainers: hours used against the hours sold each month.
- Invoices and receivables on the same client, so a late payment is visible next to the work that caused it.
How it works in PLYNTUM
- Projects per client and phase. A build, a second phase and a support contract can each be a project under the same client. See client and project management.
- Tasks at the level you estimate. Keep tickets in your issue tracker and create PLYNTUM tasks for the phases or features you priced. Board, list and timeline views show the plan.
- Time on the task. Developers record hours against those tasks with a manual timer or a timesheet. From Core, managers approve timesheets. See time tracking.
- Change requests. Requests and approvals give each change an owner and a recorded decision before work starts.
- Retainers and invoices. From Core, recurring invoices bill support contracts; one-off invoices, payments and receivables sit on the same client.
- Profitability. From Core, approved hours become cost at each person’s loaded rate and are set against the project’s value and direct costs. See project budgets, costs and profitability.
A fixed-price build, worked through
A client web platform is sold at 30,000. The estimate is 400 hours at a blended cost rate of 38, plus 2,000 of third-party costs such as licences and hosting during the build. Planned cost is 17,200 and the margin is 43%.
Integration work runs long and the project takes 520 hours. Cost rises to 21,760 and the margin falls to 27%. The price could carry up to 736 hours before the project stopped making money: (30,000 − 2,000) ÷ 38.
| Estimate | Actual | |
|---|---|---|
| Price | 30,000 | 30,000 |
| Hours | 400 | 520 |
| Cost at 38 an hour | 15,200 | 19,760 |
| Third-party costs | 2,000 | 2,000 |
| Margin | 43% | 27% |
The figures illustrate the method. The useful part is seeing the drift at 300 hours, while there is still time to raise a change request, rather than at 520. Fixed price or hourly covers how to choose the model per project.
Support retainers
A support contract sells, say, 40 hours a month for 2,400. In a busy month the team uses 55. Without a written rule, those 15 hours are simply absorbed, and the retainer’s real rate drops from 60 to about 44 an hour.
Agree the rule before the first month: extra hours billed at the contract rate, rolled into next month within a limit, or declined. Then record support work against the retainer project every day, so the overrun shows up in week three, not on the invoice.
Choosing software for a development company
- Does it replace your dev tools? It should not have to. Keep the issue tracker; choose a business layer that works at the level you estimate and invoice.
- Integrations. PLYNTUM has no Jira, GitHub or GitLab integration today, and its API and webhooks are planned for the Scale plan. If hours must sync automatically from tickets, check this first.
- Time that developers will actually record. A timer on the task they are working on beats a Friday timesheet.
- Change control. A request with a decision, next to the project, not in chat.
- Price for the whole team. PLYNTUM prices a workspace: $55 a month for 5 members, $150 for 10, $450 for 25 (monthly billing). See pricing.
What PLYNTUM does not do
- It is not an issue tracker: no sprints, story points, velocity charts or code links.
- It has no integrations with Jira, GitHub, GitLab or Slack today; API and webhooks are planned.
- It does not quote yet; quoting and a sales CRM are planned.
- It is not accounting software and does not calculate payroll.
Getting started
- Pick one fixed-price project and one support client. They show the two ways margin leaks.
- Create tasks for the phases or features you estimated, with the estimate in hours, and keep tickets where they are.
- Add each person’s loaded hourly cost and each project’s value. Salaries are visible to management only.
- Ask the team to record time daily for two weeks, then compare hours against the estimate per phase.
- Move change requests out of chat into requests with a decision, and invoice the extras that were agreed.
Start on Launch’s 7-day trial; timesheet approval, recurring invoices and profitability need Core. Questions about your set-up? Write to us.
