To understand the work, I went and did it
I am an independent developer. I wanted Kmlog to fit the daily work of a support worker, so I completed a Certificate III and spent more than six months working on the frontline with a support provider in Brisbane. My role was in mental health disability support.
During that time, the app became part of my own working day. I used it for my journeys, noticed where the process was awkward, and adjusted the design and features around what I actually needed. It was a daily cycle of doing the work, reviewing the record and improving the app.
That experience gave me a clearer priority: useful software should make the work easier. It should not turn a straightforward task into another complicated system to manage.
The problem waiting at the end of a shift
The company I worked with used Connecteam. At the end of each shift, we wrote a shift note as part of the provider's NDIS record-keeping process and included a screenshot of our mileage evidence.
There was no single format for that mileage image. Management sent several reminders asking staff to record their kilometres correctly, accurately and in line with the organisation's requirements. I could see the difficulty from both sides: workers needed a simple way to prepare a record, and the people reviewing it needed something clear and consistent.
I started thinking about the work we could remove. Why keep creating tables in a phone's notes app, entering trip details by hand, and then taking, cropping and adjusting screenshots? The phone was already able to record location and time. Those details could form the basis of a much more useful trip record.
Real outings rarely stop at one destination
Another problem emerged when I was out with a participant: a journey often involved more than one destination. Ending a trip at every stop and creating a separate record for each leg meant more work for me. It also gave the office more individual records to check and reconcile.
That led to the original idea for multi-stop recording. Where the whole outing belongs in one work record, leave the trip recording running between stops and end it once the journey is finished. During review, add the stops that matter to that journey.
Those stops should reflect the route actually recorded. Kmlog checks a proposed stop against nearby recorded GPS points. A place within the supported proximity can be added and placed along the recorded route; an address too far from that route is rejected.
The aim is to make the record easier to understand while keeping it connected to the journey captured by the phone. Selecting an address should not turn a place the phone never recorded nearby into a stop on that trip.
Keeping several legs together is useful only when it fits the work. If the journey includes private travel, different purposes or a provider requirement for separate legs, those records still need to be separated appropriately. GPS can also be incomplete or inaccurate, so I still review the result rather than treating a map as unquestionable proof.
Thinking about the person checking the record
I also began looking at the workflow from the provider administrator's perspective. A consistent format makes it easier to find the route, times, locations and kilometres, instead of working out how each staff member has put their evidence together.
Route-linked stops can help that review, but they do not independently prove that a service was delivered, identify who was in the car, or determine whether a journey is claimable. The worker and provider still need to check the purpose, supporting service records and the rules that apply.
For me, the value is practical: a clearer record for the worker to submit and a more consistent starting point for the person checking it. The support-worker mileage checklist covers the details worth checking together.
Keep building around the working day
Those everyday problems shaped Kmlog's trip images, PDF reporting and multi-stop records. The current iPhone workflow also lets you plan stops and open a supported navigation app while Kmlog records the active journey. Navigation helps you get there; the recorded journey is what you review afterwards.
I will use this space to share more of that development process: the needs behind a feature, what I learn when using it, and the decisions that keep the app useful without making it unnecessarily complicated.
If your working day exposes a problem I have not considered, I would like to hear about it. Please describe the workflow without sharing client names, addresses or other confidential information.
This is my personal development story. Features and report fields vary by platform, version and selected options. Check the release notes and current features for availability. Kmlog provides supporting records; it does not certify NDIS compliance or replace required shift notes.