Developer stories Field note 01

Why I built Kmlog around real support work

The most useful features started with the paperwork at the end of my own shifts.

Independent developer6+ months on the frontlineBrisbane, Australia

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.

A finished trip record, ready to share

The workflow I wanted was simple. While parked, tap Start a trip. Let Kmlog record the journey using GPS. At the destination, park and tap Stop trip. Then check the departure and destination, review the recorded distance and timing, and save the trip.

The recorded information should be brought together rather than typed again. Selected vehicle details or registration and optional odometer readings can provide additional context where included in the chosen output. GPS distance and odometer readings remain separate measurements; the record still needs a final check.

From that completed journey, Kmlog can generate a detailed trip image to save on the phone or share. I could upload the generated image through our shift-note process, instead of taking a screenshot and editing it to fit. For a reporting period, there is also the option to create a PDF.

I wanted to finish the journey with a useful record, rather than another piece of admin to assemble.

In my own work, this made the mileage submission process quicker and reduced the amount of manual preparation I had to do. It helped me present clearer supporting records for reimbursement review.

This describes uploading a file through the workplace's existing process. It is not a direct integration with, or endorsement by, Connecteam. You can see the report example and sharing checklist to understand the output and what to review before sending it.

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.

Share a workday problemExplore multi-stop recording

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.