Features, not tiers: why almost everything can be switched off

KlipTrack started with a business owner complaining about software that did too much. They used less than half of what was there, and the extra menus buried what mattered. So one of the system’s basic rules became: if a feature is not needed, it should not show up.

What is always included

Four things are enabled for every company by default:

• Sites: where colleagues work and the radius around each site;
• Leave: who is away from work and on which days, in full or in part;
• Team: colleagues and their phones;
• Reports: attendance, work time and Excel exports.

That is enough for the system to do its job: show who worked where and for how long at the end of the day.

What has to be enabled separately

The other twelve modules are off by default. Each can be switched on separately for a company:

• leave requests from the phone and a shared calendar;
• clients, work orders and expenses;
• a daily schedule showing who is going to which site tomorrow, compared with what actually happened;
• office activities for time the map cannot explain, such as desk work, archiving or working from home;
• equipment tracking: where each tool is, who has it and how it gets returned;
• a live map for the office wall, a detailed office map, an equipment log and one-off location checks.

If a module is off, it does not appear in the menu or on colleagues’ phones. There is no greyed-out button or “upgrade to premium” message. It simply is not there.

Why features, not tiers?

The familiar way to price software is to offer three plans: basic, pro and enterprise. That is convenient for the vendor, but it makes customers buy nine features just to get the one they need. A maintenance company may need equipment tracking but not a daily schedule. An office with no field sites may need office activities without the site module. So this module depends on nothing else.

Some modules do have prerequisites, and the system says so: a live map is not useful without sites, and neither is a daily schedule.

A new module never turns itself on

When a new module is built, it arrives switched off for every existing company. The first client’s system therefore stays exactly as it was until someone decides the new feature is useful.

One example shows why this matters. When phone-based leave requests were ready, the obvious thing would have been to add them to the existing leave module. But then every company with leave enabled would suddenly have a new feature on its employees’ phones, without anyone asking for it. So it got its own switch.

The same thinking keeps the two maps separate. The live map on an office wall may be visible to anyone, so it shows neither full names nor hours. The detailed office map includes full names and working hours, and is never displayed on a wall. Same data, different audiences, so they are separate modules.

What can never be switched off

There is one part the switches cannot touch: tracking itself and the phones’ connection to the server. The reason is simple. If a company and its provider ever have a dispute over billing, that must not shut down the phones and erase attendance data—the very data the dispute may be about. Billing status never reaches the phones.

What I learned from what nobody asked for

A feature costs more than the time it takes to build. It also costs attention when it is in the menu for people who do not need it.

The office never asked for everything to be visible all the time. It asked for a system that worked the way they did. The switches make that possible: the same product can show only what a small maintenance company needs, or what an engineering firm needs.

In the final part of the series, I write about how one developer built all this in three months with help from AI: One developer, one product, three months.