Professional services
Tells a services business which projects are actually profitable, using effective-dated cost rates and allocation that accounts for who is already booked.
Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.
Interface built in code for this case study — not a client screen capture.
01Business problem
Agencies and consultancies know their revenue and their payroll but not which projects made money, so they keep selling the work that loses it.
Who feels it
A services business bills either by time or by a fixed fee. Revenue is visible in invoices and cost is visible in payroll, but the join between them — which person spent how many hours on which project at what cost — usually does not exist in a usable form. Timesheets arrive late, at the end of the month, filled in from memory, and by then the project is finished and the number is only a post-mortem.
The result is a business that cannot tell a good client from a bad one. A fixed-fee project that ran forty percent over looks the same in the bank as one that came in under, and the same scope gets quoted at the same price again. Meanwhile the team feels overloaded and nobody can say by how much, because allocation lives in a spreadsheet showing who is on what project but not how many hours that leaves.
The technically interesting part is that cost rates change. A person gets a raise in April, and a project that ran from January to June has hours at two different cost rates. Systems that store a single current rate silently rewrite the history of every past project every time someone is promoted.
02Product overview
A project and workforce system with effective-dated cost and bill rates, allocation that computes real remaining capacity, timesheets locked by period after approval, and margin per project computed from the hours as they were actually costed.
Engineering notes
Rates are effective-dated. Every person has a series of cost rates and bill rates with start dates, and an hour is costed at the rate in force on the date it was worked. A raise in April changes the cost of May’s hours and leaves March alone, so historical project margin stays comparable and no past number gets rewritten behind anyone’s back.
Allocation is computed against capacity, never declared. A person’s available hours in a period are their working hours less leave less existing allocations, so booking someone at fifty percent when they are already at eighty is a visible conflict with the specific overlapping assignments named. The planning view answers "who can take this" instead of "who is nominally free".
Timesheets are entered against project phases and tasks with a weekly cadence, and approval locks the period. A locked period cannot be edited without a reopening action that is recorded, because a margin figure that can change after the fact is not a figure anyone can plan against.
Margin is computed per project, phase and person from the costed hours plus recorded expenses, against either time-and-materials billing or fixed-fee revenue recognised on progress. Budget consumption is tracked against the phase budget with a projection based on the current burn rate, so an overrun is visible while there is still time to act.
03Key features
10 capabilities. Every one of them is deterministic software — there is no model in this build, and nothing here is described as AI.
Cost and bill rates are held as dated series, so an hour is always costed at the rate in force on the day it was worked.
Projects break into phases and tasks, each with an hours or fee budget that consumption is tracked against.
Available hours are working hours less leave less existing allocations, so overbooking surfaces as a named conflict, not a surprise.
Overlapping assignments are detected across date ranges and reported with the specific projects causing the overload.
Time entered against phases and tasks with a weekly rhythm, submitted for approval and never accumulated silently.
Approval locks the period; reopening is an explicit, recorded action, because margin figures must stop moving.
Revenue against costed hours and expenses per project, phase and person, computed from the rates actually applied.
Billable against non-billable against available hours per person and team, with the definition of billable stated.
Scope changes are recorded against the project with their hours and fee impact, so overruns separate from scope growth.
Project expenses with billable flags and markup, included in margin and not parked separately in accounting.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Project, phases and budgets defined with a billing model.
Capacity computed; assignments checked for overlapping conflicts.
Weekly time entered against phase and task.
Submission approved and the period locked.
Hours costed at effective-dated rates; expenses included.
Margin, burn projection and utilisation derived from costed hours.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
A single current rate rewrites the cost of every past hour whenever someone is promoted. Dated series mean an hour worked in March keeps March’s cost. Without that, comparing project margin across time is meaningless.
Trade-off
Every cost calculation needs a date-aware lookup in place of a simple join, and rate changes need careful handling around already-approved periods.
Why
Recomputing cost at report time makes yesterday’s margin figure change today if a rate is backdated. Freezing at approval makes reported margin stable, and a genuine correction becomes an explicit recost action with an audit entry.
Trade-off
A backdated rate correction requires deliberately recosting affected entries, which is more work than a silent recalculation and considerably safer.
Why
Availability is a function of several things that all change independently. Deriving it means the planning grid is right the moment leave is booked, without a synchronisation step that can fail.
Trade-off
The planning grid runs a real computation per person per period, so the interval arithmetic is kept efficient and the grid is paginated by team.
Why
Margin that can move retroactively cannot be acted on. Enforcing the lock server-side means no route — interface, import, or job — can edit an approved period without the recorded reopening.
Trade-off
Legitimate corrections need a reopening request, which adds friction. The friction is the feature.
Why
Invoicing milestones rarely align with delivered effort, so margin computed against invoices swings wildly month to month and says nothing about the project. Progress-based recognition produces a margin figure that tracks reality.
Trade-off
Progress needs a defensible measure — hours against budget, or a stated percent complete — and both need review to avoid optimistic reporting.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Rates became effective-dated series with a resolver that takes a work date, and the resolved cost is written onto the time entry when the period is approved. A backdated rate change no longer touches approved entries; it requires an explicit recost that records what changed and why.
Outcome
Historical project margin became stable and comparable — a precondition for using it to price the next piece of work.
Approach
Allocations are decomposed onto a weekly grid at write time, so conflict detection becomes a sum per person per week and no interval overlap search is needed. The grid stores allocated hours, and the planning view compares it against computed capacity in one pass per team.
Outcome
The planning grid renders quickly and conflicts name the specific overlapping projects — the detail a delivery manager needs in order to resolve one.
Approach
Entry was rebuilt around a weekly grid pre-populated from allocations, so a person confirms and adjusts instead of recalling. Submission reminders are tied to the person’s own unsubmitted weeks, and the approval queue shows managers what is missing, not only what has arrived.
Outcome
Time got entered close to when it was worked. None of the downstream numbers are worth computing without that.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Capacity grid
People by week with allocated against available hours, and overallocated cells naming the conflicting projects.
Weekly timesheet
Rows pre-populated from allocations, entered against phase and task, with the submission state visible.
Project margin
Revenue, costed hours, expenses and margin by phase, with budget burn and a projection to completion.
Utilisation
Billable, non-billable and available hours per person with the billable definition stated on the report.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.