The Feature Nobody Wrote Down

One of my favorite calls this week was a regular check-in with a field services company we built a custom operations app for. The app has been live for a few weeks now, and you can feel the team settling in. Contracts with no issues flagged went from 32 to 41, and they've already picked a date to retire their old schedule spreadsheet for good.

That last part is the real milestone for any new system. Launch day is easy to celebrate. The day a team stops opening the old spreadsheet "just to double-check" is the one that tells you it worked.

Then, partway through the call, someone on their team shared their screen and showed me something that had never come up in any of our conversations.

The rule that lived in blue text

On their old schedule, any job postponed because of bad weather was typed in blue.

That was the whole system. There was no "postponed" column, no status dropdown, no note. The crews looked at the schedule, saw blue, and knew the job had moved. Installs and removals had their own colors too, so the whole week could be read at a glance.

None of this was in our requirements. It wasn't in the documents they sent over at the start, and it didn't come up in the kickoff questions. Nobody was holding it back. It was just how they'd always worked, and when something is that normal, you don't think to mention it.

So we're adding a small formatting toolbar to job notes, with bold and text color, and bringing back green and red badges on the schedule for installs and removals. We're also adding a fail-safe so colored text stays readable in both light and dark mode, because the last thing you want is a weather delay that turns invisible.

On the same call, the team asked for a master search bar so they can find a contract without checking three separate tabs, and a way to sort comments so the newest shows up first. None of these are big builds. All of them came from watching real people do real work in the app.

Why unwritten rules matter when you replace a spreadsheet

If you run a small or mid-sized business, I'd bet your operations depend on a handful of rules just like that blue text. A color that means something. An abbreviation only two people understand. A row that always gets checked twice before an invoice goes out. A sticky note on someone's monitor.

Spreadsheets are great at holding these, because a spreadsheet lets you do almost anything. You can color a cell, add a symbol, leave a comment, or create a new tab whenever you need to. Over a few years, those small habits pile up into a real system, even if nobody designed it on purpose.

A custom app or automation is more structured, and that's a big part of why it saves time. But structure means every rule has to be built in on purpose. If nobody knows a rule exists, it doesn't get built, and the team quietly loses something they relied on.

That's usually when you hear "the old way was easier," even when the new tool is better in almost every other way. It's rarely about the whole app. It's about one or two missing habits.

The good news is that these rules are easy to protect once you know to look for them. Here are three ways we do it, and how you can too.

1. Ask about what the spreadsheet can't show

This same week, we kicked off a new platform for an event production company that runs multi-day corporate events. Before the kickoff, we spent time going through their planning workbooks: the schedules, rooming lists, contacts and budget estimates. Those told us a lot about how their data is structured.

What they couldn't tell us was how information actually moves. So our discovery questions focused on that: how things travel between them, their clients, the venue and their vendors, and how decisions get made along the way. I rewrote that list a few times to keep it short, and asked them to answer whatever was clearest and save the nuanced parts for our call.

On the call, one priority came through loud and clear: enter something once, and have it update everywhere it shows up. That's a rule a spreadsheet can't enforce on its own, and it's exactly the kind of thing that shapes how we build.

Try this: Before you scope any new tool, sit down with the people who use the current one and write down three things they do that aren't documented anywhere. Ask about colors, symbols, abbreviations, and anything they check twice. Hand that list to whoever is building.

2. Watch someone use it after launch

If you ask a team "how's the new system going?" you'll usually hear "good" or "fine." That's honest, but it's not very useful.

When someone shares their screen and walks through a normal task, you see everything. On our check-in, that's how the blue text came up. It's also how we noticed that the quantity field on a line item took one more keystroke than the old system did. Not a big deal once, but a team that enters line items all day feels it.

We've been holding weekly check-ins with this client since launch for exactly this reason. Some of the best improvements come from those calls, not from the original spec.

Try this: Two weeks after any new tool goes live, ask one person to share their screen and complete a task they do every day. Stay quiet and take notes. Then ask, "What did you used to do here that you can't do now?"

3. Knock out the small asks fast

Earlier in the week, someone on the same team emailed a quick question: if the lights on a job are already installed, where should they enter the install date? It was a great question, and I hadn't accounted for it. So I added an install date field to the contract page Monday morning, and they confirmed it was working about half an hour later.

Later that day, another team member asked about uploading signed contracts after the fact. We added a manual upload option that evening, and they let us know it was working first thing the next morning.

Neither change was complicated. What they did was show the team that the new system will bend to how they actually work. That trust is what gets people to stop keeping the old spreadsheet open in another tab.

Try this: Keep one running list of small requests from your team. Anything that takes under an hour, handle within a day, and then close the loop with the person who asked. A quick "done, give it a try" goes a long way.

The same idea applies before you build anything

You don't need to be replacing a whole system for this to matter. On a discovery call with a real estate team this week, the first thing I noticed was how many good processes they already had in place. So our recommendation wasn't to start building. It was to start with a few working sessions to map how things run today, then put together a plan with options, tradeoffs and timelines.

Whether you're automating one follow-up reminder or replacing your whole operations stack, the starting point is the same: understand the habits before you change the tools.

The lesson

The old way of doing things is full of features nobody wrote down. Find them before you replace it, and the new tool feels like an upgrade instead of a loss.

What's one rule your team follows that only lives in a spreadsheet or someone's head? Reply and tell me, I'd love to hear it. And if you're thinking about moving off spreadsheets and want a second set of eyes on it, you can grab 30 minutes with me here: calendly.com/patrick-univium/30min

Talk soon,

Patrick