If you don't meet people where they actually are, you're not building for most people. You're building for nerds.
By Dean and Diony McPherson, co-founders of Paperform
Earlier this year we took a call with an enterprise customer whose primary goal was simply to digitise their PDF forms - hundreds of them. In 2026, tech innovators would assume this customer would be more concerned with combining three systems together or automating a critical approval chain. But no, it was business critical for them to just get their forms off paper.
The immediate temptation for many in the tech industry is to file that under laggards - businesses who took too long to catch up to the tech. But in our experience, we file it under most businesses. We've been building forms for ten years, and had enough of these conversations to know that this is much closer to the middle of the market than many realise.
There's an assumption running through tech at the moment that AI lifted everyone's technical ability. But we believe all it did was widen the gap that already existed. The people who were already comfortable building things are now dramatically more capable (this is the nimblest the Paperform team has been). But the people who were intimidated by new tech are even more intimidated with the onset of AI capabilities, and the distance between them and everyone else is much greater now - and much more obvious. Their compliance teams are also more cautious than ever of new tech.
That gap is the interesting problem, and hardly anyone is building for it. It's much easier to build for the people who already know what they're doing. But if you don't meet people where they actually are, you're not building for everyone. You're building for nerds. (And that's a self-own by the way).
Most of the people we talk to don't want to be impressed by what's under the hood and endless potential. They have a clear problem to solve, and want to feel in control of something they're accountable for. Those are not the same feeling. And at the heart of our mission is a desire to help these people the most.
The promise that got delivered to the wrong people
When we launched Paperform in 2016, "no-code" was a fledgling concept. It came with a big promise: configure your way into software instead of writing it.
As a market experiment, we don't think it delivered. Don't get us wrong, it was a valuable leap for the way we approach apps and building systems, but it was never truly no-code, at its best it was low-code. But ten years on, and AI has fully delivered on that original promise.
What gets missed is that the fully no-code crowd was never the average business. It was a specific kind of person who enjoys building their own solution and has the time to do it. Vibe coding inherited that group, but it didn't create a new one.
The average operator in a team or business didn't want to build a no-code system for themselves, and they likely don't want to vibe code one either. They just want the "thing" to work, and they want good support when it doesn't.
Building was never the expensive part
We have thought about replacing nearly every piece of our own stack at some point. Subscription management, billing, Slack, Notion; any system or tool you could think of, with our knowhow, we could build them. And like every developer, we love building solutions to a problem.
But what stops you isn't the difficulty. It's that on the other side of building something you're now running a production system that pulls you away from your business. Only you understand it, and when it breaks at 2am you're the one who gets alerted. When you need new features, you have to build it, and you have to ensure compliance is considered at every step.
Ain't no body got time for that.
To add to all that, people talk about AI removing the cost of building software. But the build was never where the bulk of the cost sat. The old joke among developers is the ninety-ninety rule: the first 90% of the code takes 90% of the time, and the last 10% takes the other 90%. Honestly, now, it feels closer to 98% of the work being in the last 5%, and that's before you've maintained anything.
So the useful question was never could we build this, but rather, do we want to maintain this forever?
The Hidden Variable with AI
As CTO, Dean spends about a thousand dollars a month on AI. He calculates that $1K buys somewhere north of twenty grand of actual compute. It's a solid value-add, particularly because it multiplies Dean's output enormously. But there's strong reason to believe that will change.
Harvard Business Review published an analysis in August arguing that the era of vendor-subsidised AI pricing is ending, and that organisations are currently, in effect, being paid to adopt AI while vendors absorb the cost of GPUs, inference, and tokens. That's not sustainable. It's worth noting that GitHub Copilot moved from request-based to usage-based billing on 1 June.
If you decided to build something in-house this year because the tooling made it cheap, you made that call on subsidised pricing. When the subsidy goes, the maths changes, and the thing that was cheap to maintain is now a liability because your token bill went up.
We're not predicting a cliff. Nobody knows what inference costs at scale in two years. But the reality is we are assuming AI token prices won't change. We'd argue it's worth keeping an eye on these costs as you consider your AI-powered workflows for the future.
The choice we don't think you should have to make
Here's what we believe matters, and it's the reason we will continue to double-down on Paperform.
You shouldn't have to choose between a tool that's powerful and one you actually own.
Simple tools or vibe-coded stacks look cheap now because the cost is deferred. They work beautifully until you add a second brand, or payments, or a compliance requirement. And because the tool is not built to scale or can manage data securely, and you end up attempting to stitch things together or call a developer. Now you're paying the price, and sometimes you are paying it in your evenings when you'd rather be at your family get-together.
Powerful tools go the other way. They're built by developers, for developers, which means owning one turns into depending on someone else to change it. The thing we hear most from larger customers isn't that their system can't do what they need, it's that they're tired of relying on a dev shop to make small changes.
In the end, you're given two bad options and the industry calls it "choice" (picture us doing sarcastic air-quotes). Do it yourself and you're exhausted as you become the integration between your own tools. Hand it off and you're roadblocked, watching costs climb for changes that should take an afternoon. Either way, you don't own your own operation. You've just replaced the complexity of needing something done with the complexity of managing someone else doing it.
We don't think that trade-off is useful, and we don't think it's sustainable. But the good news is that it isn't an immutable law like the law of physics.
Implementation takes time
When a new AI-built form tool shows up, it's easy to be excited. Everyone is excited about the 'unlock' for their team or workflow and are ready to pull the trigger on getting it implemented. But in the mix of excitement, we can lose sight of the two most important factors in adding any new tool: compliance and data.
Because with true implementation, that's the bit that takes years. While building and growing Paperform, we've seen ten years of compliance changes in SaaS. We've seen the industry deal with data leaks and huge outages, and we've safeguarded against these. And the thing you learn fast is you don't "clear the bar" for either of these once. There's a reason SOC 2 requires regular audit renewals. Laws change and your documentation and compliance has to change with them. There's a cost to scaling data and handling it correctly.
And for most teams or businesses, the person who has to deal with security or compliance in a cross-team system usually isn't an expert. They're a capable operator who's been asked to find the best solution for the team. They are handed a document full of words nobody taught them so that they can research tools they don't fully understand. When asked follow up questions from vendors, half the time they can't answer because they're relaying everything between various stakeholders. Now they have to chase answers out of IT, legal, and finance who all expect them to understand ever-shifting compliance needs. And for that operator this now feels like a mountain that's too hard to climb.
Experience as Service
That's why we believe we need to put an emphasis on service. To be able to meet those operators, read their documents, and tell them what their own team is actually asking for in plain language. To understand how their tools can solve the problems they don't see and help them avoid becoming the integration. That's why it's called SaaS: Software as a SERVICE. And good service requires clear experience and years of doing.
None of this is theoretical. We've worked with our customers hand-in-hand. José Vitor, who runs DZB, described his self-built "before state" as a nightmare, with information stored in one place and dependent on one person, and the "after" as a process that starts and ends with one Paperform. Luiz Sifuentes at Vidalyon Studios located the value of Paperform in the joins rather than the parts: each app solves a real problem, but talked seamlessly to each other. Starlight Mundy at Bottled Lightning wanted to take payments without integrating another tool she would have to manage and setting up a separate sales page and checkout to do it.
None of them were really describing a feature. Rather, they're describing not being the integration any more.
Where we draw the line
And we know that some will disagree with this.
Some say that serious workflows belong in internal engineered systems, and no-code and vibe-coded tools held together by integrations are just toys. We agree that some things should be built by your own engineers, and a tool that pretends to be something it's not will hurt you. We are arguing that that particular category is much smaller than the industry thinks. Most of what gets sent to a dev shop is sent there because the alternative options were capped, not because the work required a developer.
Conversely, some say most businesses' needs really are simple, and paying for power you won't use is the real trap. This can also be true. If you need one contact form, go and use Google Forms instead of Paperform. We mean that sincerely. The tools are good and the people building with them are doing well. But realistically, almost no growing business stays at one form for long.
The Real Question
Here is the most important thing we have noticed in talking to our users. Most operators are rarely saying I need a form builder, let me shop. No, most operators start by asking my current system can't handle what this business now needs.
They are looking to manage multiple brands, payments, and records that have to be retained and then properly deleted. They need to mark off a compliance checklist they didn't design and can't ignore. The things the operators are currently holding together manually. And often they are the things that are mostly invisible until it fails.
So they need a system that they can understand and own, but that won't throw them under the bus when it breaks because it has their name on it.
That's why we don't accept that you have to trade away control to get it handled. That's the false choice that is holding back these operators, and it's the one we've spent ten years building against.
So we've decided to tell our customers to bring us the hard part. Whatever you're on the hook for, that's the bit we want. And if someone tells you the only way to get power is to give up ownership, ask them who that arrangement is actually built for (and rub Paperform in their face!).
We're going to share our proof that you don't have to choose between control and power in the coming months, so keep your eyes peeled.
