Software is sold on what you'll be able to do. But we really buy it for what we'll finally get to stop worrying about.
By Diony McPherson, co-founder of Paperform
There isn't a project I pick up where I don't think, fairly confidently, that I'll have it done in a day. Maybe two. Then I start pulling the thread and about a million other things come out of it. A billing update becomes a sales tax question, which then becomes a conversation with a government department that wants to verify our address by post, and somewhere in there I realise I've spent a week on something I'd scheduled for a Tuesday afternoon. It's exhausting, and I say that as someone who genuinely loves operations.
What I feel when one of those projects is finally done is rarely pride. Mostly, it's relief. And in my experience as a founder and operator, I've come to think relief is one of the most underrated emotional rewards in business, partly because the software industry is so badly set up to deliver it.
What gets sold and what gets bought
Seeing hundreds of software launches over the years, I've noticed almost every piece of software is pitched on capability. Launches and demos tell you what you'll now be able to do, and AI features have turned that up to eleven.
I understand why, and I'm not above it. When we launched Paperform in 2016, our launch was a two-minute video of a form being built, set to music, with nobody saying a word. People loved it. Capability is easy to show.
Dean described the pull of it well when we were talking about vibe coding recently: you go from nothing to something instantly and you get this lovely sense that you made it. That's a real feeling, and I've had it plenty of times.
Relief is much harder to show, because relief is mostly an absence. It's the Monday morning you didn't spend chasing a submission that never arrived, or the questionnaire that got answered without four days of back and forth. You can't screenshot something that didn't happen, and there's no row on a feature comparison table for "I stopped thinking about this."
So the industry touts what it can show. I suspect that's a big part of why so much software gets an enthusiastic first week and a quiet, slightly guilty month three.
Nobody arrives excited about forms
In ten years, I've met very few people who came to us because they were excited about forms. (Sorry, forms. You know I love you.) Unless someone is starting a business from scratch, they come looking for forms because something they already have has started to strain.
Sometimes it's an old payment setup built on PayPal forms that someone stitched together years ago and nobody wants to touch. Sometimes two departments have each digitised their own forms, differently, and suddenly there's no consistency across the company. Sometimes it's a compliance requirement the current system simply can't meet. And sometimes it's a quieter feeling that if they don't fix this now, they'll fall further behind.
Dean and I wrote a few weeks ago about what those operators are up against. What I want to add here is what that trigger tells you about what they're buying.
If the purchase starts with strain, then the thing they'll judge you on is whether the strain stops. They'll use the capability, and often they'll find far more of it than they came for. But the first question, the one underneath everything, is whether they can stop worrying about the thing that brought them to you.
The more interesting feelings tend to come after that. One of our customers, James Howes, went from using Paperform to fix a specific problem to feeling inspired to build something of his own. That's pride and empowerment, and it's one of my favourite things to watch. I just don't think anyone gets there while they're still half-expecting the old thing to fall over.
The requirement isn't the problem
Compliance is where I see this most clearly.
If you haven't met one in the wild, a vendor security questionnaire is the long document a larger client or partner sends before they'll sign anything. It asks how you store data, who can access it, where it lives, and what happens if something goes wrong. It's absolutely critical and nothing moves until it's answered.
When I started, I assumed the people sending us these understood every line. Over the years I've learned that most of them are relaying a question someone else wrote so a box can be ticked and the work can move. If we ask them to clarify a point, they often have to go back to their own technical team, because they're passing the document along rather than writing it.
So fulfilling the requirement itself is rarely the hardest part. Requirements have answers. The hard part is the unknown: having to produce an answer to something you don't fully understand and put your name next to it. When we can read that questionnaire and tell someone what their own team is actually asking for, the relief is enormous, and it has almost nothing to do with a feature.
Julie Winter, a real estate broker who works across several states, put it better than I can: "If I need to show proof, I can show the forms, the check-ins, the whole system. That's peace of mind."
She didn't describe what the software does, but rather, what she no longer has to worry about.
The day-ninety test
This is the part I think matters most right now, because it's where a lot of AI is being designed in the wrong direction.
Not too long ago Dean argued that with AI on the scene, the new bottleneck is trust: whether you can believe what just got built. I agree with him, and I'd put the feeling underneath it more simply.
Nobody relaxes around something they can't check.
An AI feature that impresses you on day one and leaves you unsure on day ninety whether it ran correctly hasn't given you relief. It's given you a new thing to worry about, with a nicer interface.
The worst version is an automation that handles the first item flawlessly, but then skips everything in between, and still reports success. You only find out something went wrong or was missed when someone else, sometimes a user, notices later on.
We know this one from our own experience: the AI usually gets the big picture right and can get caught on which items it should loop over.
We've felt this tension in our own product. Some of the AI we added over the last couple of years felt a bit like Frankenstein's monster to me: genuinely helpful, but stuck on. You could create a form with AI, but the moment you moved into the editor, it was gone. Great use of AI for users needing to spin up a form, but not so good once you need to edit. So you haven't actually fully solved for the user's relief or control.
So we've realised that making something powerful isn't the hardest design problem. We've learned that when we work out how to solve a problem under the hood, we also need to work out how to show it in a way that's logical and human.
No matter your feature, the best question you can ask is whether the person who's accountable for this system or platform can see what happened and fix it without asking anyone's permission.
If they can't, it doesn't matter how impressive the demo, app, or feature you've built is.
Relief is quiet
When we shipped PDF creation, something customers had asked us for over a long time, I was surprised by how quiet the response was. I'm sure part of it is that everyone is drowning in content at the moment, and replying to us is the last thing on anyone's list.
But I think part of it is that relief is quiet. People don't write to tell you they've stopped worrying about something. They just stop worrying.
That's an uncomfortable thing for founders to admit. The numbers that get celebrated are daily active users and time in app. Those metrics are for products that want your attention.
I know the argument for them, and it isn't a silly one. If people aren't in your product, how do you know they're getting value, and how do you know they won't leave? (As the person who also looks after our finances, I ask that question too.)
But, in the rapidly growing world of AI and automation, an operator who has to log in every morning to check the thing actually ran hasn't been given a tool. They've been given a daily to-do.
So here's where I've landed, and I know plenty of product people will disagree. For operator software, attention is a cost, not a metric. If your product needs someone to keep looking at it in order to keep trusting it, it isn't finished yet. The tools that win the next few years will be the ones the accountable person can stop thinking about by day ninety because they have their full trust.
It might never make a great screenshot, but that's what we're building for.
