Don't Make Me Type It Twice

Short week for me, but a good one. Most of what happened was small, and I mean that as a compliment. The best part came from a client, so I'll start there, then run through what else we worked on and what I've been thinking about.

Event tech: the feedback you only get from real use

We've been building an event management app for an event planning agency for a while now. Over the last few weeks we've added a shared contacts list, a portal where clients and vendors log in to see their own tasks, document requests, budget templates, a printable schedule and grouped reminder emails.

This week, the agency owner started setting up a real project in it. Not a sample. Not a test. A real event she's actually running.

Within a day I had a short list of notes back. Every single one was the kind of thing you only catch by using the software for real work.

"Why am I typing this again?"

When she added a venue during project setup, the app asked her for a time zone as a free text field. She had to type it in. Then, a few fields later, it asked for the city and region of the event, which she had just entered as part of the venue.

Her ask was simple. Make time zone a dropdown of all time zones, defaulted to her own. And since the venue already has a city and region, either fill those in automatically or stop asking.

She's right on both. Neither of these is broken in the "it crashed" sense. Everything saved. Everything worked. But this is the stuff that decides whether software feels like it was built for you or just built.

Here's the rule of thumb I keep coming back to: if the app already knows something, it shouldn't ask you for it again. Every time a tool makes you retype information it already has, it's spending a little of your trust. Do that enough times and people start keeping their own spreadsheet on the side, and now you have two sources of truth.

Two levels of "who are you here?"

She caught one more thing that turned out to be bigger. On the contacts page, she and a teammate were showing up under Vendors instead of Team.

While we were sorting that out, she put words to the underlying idea really well. There are two levels of access in an event business:

• Organization level. Someone is on your team. They work across every event you run.
• Project level. Someone is invited to one event in a specific role, like client, vendor, speaker or sponsor.

That's the logic I intended from the start, so this one is going into the next round of updates along with the venue fixes. But I love that she described it in her own words without me prompting it. When a client can explain how their business works in one or two sentences like that, it makes the software much easier to get right.

What you can take from this

If you're rolling out any new tool in your business, custom or off the shelf, here are three things worth doing:

1. Get one real project into it as early as you can. Test data tells you whether the buttons work. Real data tells you whether the tool fits how you actually work.
2. Keep a running "annoyances" list. Not bugs, annoyances. Every time you think "why do I have to do this," write it down. Those small notes are usually the most valuable feedback you'll give.
3. Look for double entry. Any field you type that the system should already know is a candidate to remove, auto-fill or turn into a dropdown.

Operations apps: the data takes longer than the code

For a construction services client, we got the permit pricing we'd asked for, so we can work it into their app next.

Note to self, and maybe to you: the information you need from a client almost always takes longer to gather than the code takes to write. That's normal. The people who have that information are busy running the business. They're on job sites, answering calls and chasing payments. Pulling together a clean list of prices isn't anyone's full-time job.

What I've learned is to ask for it early, ask for it in whatever format is easiest for them, and do the cleanup on our side. A messy spreadsheet that shows up this week beats a perfect one that shows up next month.

If you're planning a project with a developer or consultant, here's a useful exercise. Before the first meeting, make a short list of the reference data your business runs on: price lists, rate sheets, service areas, product catalogs, standard fees. Then find out where each one lives today and who keeps it current. You'll speed up any build by weeks.

AI and automation: a mockup in an afternoon

I put together a branded mockup of a weekly planning tool for a founder community this week. It took an afternoon.

Here's roughly how it came together:

• I started from their logo and whatever I could find of their branding online.
• I had Claude draft a set of brand guidelines from that, so the colors, type and tone stayed consistent.
• I built a working version you can actually click through, not a static picture.
• I recorded a short walkthrough video so they could see it without needing a meeting.

A year or two ago, that would have been a week of work, and I probably wouldn't have done it before a project was agreed. Now it's fast enough that it makes sense to build first and talk second.

That changes the first conversation. A working mockup someone can click on gets you better feedback than any proposal document. People react to what they see. They'll tell you "this part isn't how we do it" in thirty seconds, where a written scope can hide that kind of mismatch for weeks.

If you're considering a custom app, ask whoever you're talking to for a clickable mockup before you sign anything. It's a lot cheaper to change your mind on a mockup than on a finished build.

What I'm thinking about: write it down before you scale it

This week we turned how we run event setups into written SOPs. Nothing fancy. Step by step, in plain language, so anyone on the team can follow along.

I've also been asking a few people who've grown service businesses one direct question: where did things break for you when volume went up?

The answer is almost always some version of the same thing. The process lived in someone's head. It worked fine when that person was doing everything, and it fell apart as soon as more people or more clients were involved.

The same is true for automation, and it's one of the biggest things I'd want any business owner to hear before they spend money on it. You can't automate a process nobody has written down. If three people on your team would describe the same process three different ways, an automation will just lock in one of those versions, and probably not the best one.

So before you automate anything, try this:

1. Pick one process that happens every week.
2. Have the person who does it most often write down the steps, in order, in plain language.
3. Have someone else follow those steps once without asking questions.
4. Fix every place they got stuck.

Once that document holds up, you're ready to automate it. And half the time you'll find a step or two you can simply drop.

Whenever you're ready, here's how I can help

1. Fix the double entry. Reply with one form or tool in your business that asks for the same information twice. I'll tell you how I'd fix it.
2. See it before you build it. If you're weighing a custom app, we can start with a clickable mockup so you know what you're getting before you commit.
3. Talk it through. Grab 30 minutes with me here: calendly.com/patrick-univium/30min

So here's my question for you: what's one thing your team types twice every week? Hit reply and tell me. I read every one.

Talk soon, Patrick