I’ve launched Pathfinder Analytics, a planning, time tracking and budgeting application I’ve spent the last three to four months designing and building. The whole company I work for is now using it. Our clients, projects, budgets and time sit together, and it has become the place we use to plan the week and talk about the work ahead.
I built Pathfinder in my own time. It is my own product, and I own all the rights to the system. Seeing it become useful in the business has been particularly rewarding because I’ve been responsible for the journey from the initial idea and Figma designs through to the application people use each day.
Starting with the work people actually do
A business can have plenty of information and still struggle to see what is happening. A project has a budget, someone has a list of tasks, and a manager has an idea of what the team will be doing next week. Those pieces only help if they can be brought together without someone spending hours reconstructing them.
I wanted a system where planning and recorded time could be considered alongside the client and project they belong to. What have we committed to? Who has room to take it on? How much of the budget have we used? Has the work changed since we planned it? These are ordinary questions, but getting a clear answer makes a considerable difference.
Pathfinder gives us a shared overview to review each week. It also gives us a consistent set of information for monthly reports to the directors, so those conversations can start with how the business is operating rather than a scramble to collect the figures.
Bringing experience from application design
I’ve been designing and building applications since 2015, including project management software for banking organisations and bespoke systems for smaller companies. That experience has taught me to pay attention to what happens between the obvious features. How does someone get back to the task they were doing? What happens when a plan changes? Can they understand the state of a project without opening five different screens?
Watching people use systems has been as useful as writing them. An interface can make sense to the developer and still be awkward for the person who needs it throughout the day. That informed Pathfinder’s structure from the beginning, especially how planning, projects and personal schedules connect.
I did the planning, application structure, design and Figma work myself. Before implementing a screen, I worked through what someone needed to see, what they could change and where the next action should take them. There were plenty of decisions about dropdowns, labels, spacing and how much information to show at once. Small details become very noticeable when you use the same interface every day.
Using AI with responsibility for the result
AI assisted with the build. It helped me work through implementation tasks and move more quickly, but I remained responsible for the architecture, the design decisions and the code that went into the application. Years of building systems gave me the context to decide what to ask for and whether the result fitted.
That review mattered. A change can look convincing on screen while making the underlying behaviour harder to maintain. I needed to understand how it handled data, how it fitted the existing code and what happened outside the simplest example. AI-assisted changes and code releases were closely monitored and reviewed before I accepted them.
The application uses Laravel with a React interface through Inertia. Having a structure I understood meant I could judge each change against the whole product. I could follow a planning action through to the server and back again, rather than accepting a working-looking component without understanding what it had changed.
This has been a useful way to bring my experience together. AI helped with implementation, while the decisions about the product and responsibility for its behaviour stayed with me.
Planning that can move with the week
One of the most involved parts was the relationship between planning and time tracking. A project manager can allocate time to other employees and build a picture of the coming week. Employees can then see their own schedule, record what they have worked on and adjust the work they are responsible for.
Dragging an allocation to another day sounds like a small feature until you work through all the expectations around it. Moving work, resizing an allocation, editing hours and carrying something into a later week all need to behave consistently. The interaction should make a change easy while leaving the resulting schedule understandable.
I spent a lot of time on that behaviour. The team view needs to make it easy to plan across people and projects. The personal view needs to let someone manage their day without wading through everyone else’s workload. Planned work and recorded time also need to remain distinguishable, so a schedule does not become a misleading record of what has actually been done.
A week rarely follows the original plan exactly. A task can take longer than expected, a new requirement can arrive, or something may simply remain unfinished. People need to be able to move their work and make those changes visible. That gives us something useful to discuss at the next catch-up, rather than treating the first estimate as a promise that cannot change.
Connecting time to budgets
Recorded time becomes more useful when it is connected to the project and the cost of delivering that work. Pathfinder brings time, rates and budgets together so we can see where the budget is going and where a project needs attention.
An allocation tells us what we intend to spend time on. Recorded time tells us what happened. Looking at both helps us spot a gap between the plan and the work, and gives project managers a better starting point for decisions about remaining scope and capacity.
The system flags missing time and projects that are over budget, bringing those issues into view before a monthly report. Missing entries can make a project appear healthier than it is. An overrun can also be a sign that the scope or estimate needs another conversation. I wanted these alerts to help us ask the right questions, rather than jump to a conclusion about the person doing the work.
Giving people the right level of access
Permissions needed the same care as the interface. A workspace administrator needs control of the system, while a manager needs a wider operational and commercial view. Project managers need to work with projects and team time. Other people may only need to schedule their department or manage their own time.
Pathfinder has five access levels covering those responsibilities: Workspace Admin, Manager, Project Manager, Department Schedule and Own Schedule Only. The permissions govern what someone can access and change on the server as well as what the interface presents to them. That keeps the everyday screens relevant while protecting actions and information that belong to a different role.
Testing beyond the everyday workload
During testing, we loaded around eight million records to expose performance problems that would be easy to miss with a small demonstration dataset. It gave me a much better view of which parts of the system were doing too much work and where the approach needed to change.
A schedule should load the people, dates and projects needed for the view in front of you. It should not try to bring the whole company’s history into the browser. I worked on keeping queries focused, loading related data together, using pagination where appropriate and adding indexes for the ways the application actually looks up information.
Automated tests cover scheduling behaviour, permissions, reporting and the boundaries between workspaces, alongside checks for larger schedules. Those tests help catch a change that makes a common action work but breaks a less obvious case. After addressing the bottlenecks, the system remained quick to use under the heavy test data load.
That test does not tell me how every future workload will behave. It does give me more confidence than testing with a handful of clients and projects, and a way to revisit performance as the application grows.
Getting it into everyday use
The rollout involved talking through how people planned their work, showing how that fitted into Pathfinder and listening to what felt awkward. Getting everyone into the system mattered, but the better sign was seeing it become something people found useful themselves.
We now use it for weekly catch-ups, monthly reporting and day-to-day time tracking. It gives us a place to discuss upcoming work and how it can be scheduled between the team. Moving employees’ planning into the same system has made those conversations much clearer because we can look at the same picture.
The application is hosted on DigitalOcean. That gives me room to increase server resources and storage as usage grows, with backups forming part of looking after the system. Deployment and ongoing maintenance are part of the product too. It needs to be dependable once people are using it to organise their working week.
Making room for people to do good work
The purpose of Pathfinder is to help the health and operation of the whole business. I did not build it to monitor employees or accuse anyone of wasting time. A time entry cannot explain everything about someone’s day, and a full calendar is not proof that a team is working well.
I would rather someone be a little underscheduled, with room to think and do their best work, than have every available hour allocated. Projects have unexpected demands. People need time to resolve problems, help one another and deal with work that was not in the original plan.
Being able to see capacity helps us avoid repeatedly loading the same people with too much work. Giving employees control of their own schedules helps them raise a change early, move unfinished work and show when something has taken longer. The aim is to make realistic planning easier and reduce avoidable pressure.
For a growing business, that shared view is valuable. It connects the work being sold, the work being planned and the work being delivered, while leaving room to discuss the reasons when those things differ.
I’m proud of what Pathfinder has become. There have been months of small decisions, testing and revisiting parts that did not feel right. Watching the company use it to organise real work has made that effort worthwhile. It has also reminded me how much I enjoy application design: taking a complicated set of needs and building something people can understand and use.