When you can't cut the audit trail.

Strategy · 5 min read

I have the same conversation with every client. What's in the MVP and what's in phase two. We go through the feature list, and I push back on anything that isn't essential to proving the app works. International expansion? Phase two. Multi-language support? Phase two. Advanced reporting? Phase two. That conversation is normal. It's necessary. It's how you keep costs down and get to market quickly.

But sometimes the client says no. And they're right.

I was working on a safety compliance app and I asked the client about the audit trail. "Is this essential for MVP, or can we add it later?" His answer was immediate. "If we can't do that, the system doesn't work." That was it. No negotiation. No weighing it up. The audit trail wasn't a feature. It was the reason the app existed.

Not every feature can be deferred

The MVP conversation works because most features aren't essential to proving the core idea. You don't need five permit types to prove the system works. You need two. You don't need international expansion to test product market fit. You need one country. You don't need SMS notifications to validate the workflow. Push notifications can do the same job for now.

But some features are load-bearing. They're structural. Remove them and the whole thing falls over. In our case, the app was designed to give insurers and site managers a verifiable record of every safety check, every timestamp, every photo, every missed inspection. Without the audit trail, the app was just a fancy checklist. It offered nothing over the paper forms it was replacing.

The client knew that because he'd been in the industry for decades. He understood that the entire value proposition was accountability. The app didn't just track permits. It proved that permits were followed. Without the trail, there's no proof. Without proof, there's no product.

How to tell the difference

So how do you know when a feature is genuinely essential and not just something the client is attached to? I use a simple test. Can someone use the app without this feature and still get the core value? If the answer is yes, it can wait. If the answer is no, it's in the MVP.

Multi-site management? Someone can use the app with one site. It can wait. Export to CSV? Someone can view the data on screen. It can wait. The audit trail that proves compliance to an insurer? Without it, nobody would pay for the app. It stays.

The hard part is that these load-bearing features are often the most expensive to build. An audit trail isn't a button and a screen. It's a database structure, a logging system, timestamped records on every action, and an interface to view and export it all. That's real development work. But there's no shortcut. If the feature is the product, you build it first.

Trust the person who knows the industry

When a client pushes back on cutting a feature, listen carefully. If they're saying "I just really want this" then it's probably a nice to have. If they're saying "the system doesn't work without it" then they're telling you something critical about the industry, the customer, and the product. The client in this case had spent years in industrial safety. He knew what insurers look for. He knew what site managers need. He knew that a permit system without an audit trail is worthless. That knowledge saved us from building the wrong MVP.

Cut everything you can. But know which pieces hold the building up.

Sources
How to Manage Work Health and Safety Risks (Safe Work Australia) - Model code of practice including documentation and record-keeping requirements.
The Definition of User Experience (Nielsen Norman Group) - Why user experience extends beyond the interface to include the entire system of value delivery.

Related blog posts:

Compliance isn't a feature →

Phase two is not a graveyard →

The difference between a feature and a solution →