I've always cared about two things in software engineering: the experience of the people using an application, and the experience of the developers building it. I've always believed there should be a reasonable balance between the two.
But after years of building software across different industries, I've noticed a recurring problem. As applications become more sophisticated, they often become harder to use for the very people they're built to serve.
That usually isn't because the software is poorly built. It's simply how software evolves.
The Problem with Growing Software
Imagine a healthcare application used by doctors, nurses and administrative staff.
At launch, it might have a handful of features: patient records, appointments, consultations and billing. Over time, customers request more. The engineering team responds with new pages, menus, settings and workflows. An application that started with five major features can quickly grow to fifty, and it certainly doesn't stop there.
From the engineering team's perspective, the product has improved considerably. But a doctor who only wants to review a patient's history now goes through several pages. A receptionist trying to reschedule an appointment might need several clicks to carry out what they consider a simple, routine task.
The functionality exists. Reaching it has become unnecessarily complicated.
My brother and I have run into versions of this problem while working on applications in property management, human healthcare and veterinary healthcare. We've heard it in feedback from users and in conversations with product and customer success teams. The complaints come down to the same things: too many clicks, too many screens and too much navigation for relatively simple tasks.
None of this means developers aren't doing their jobs. They're responding to legitimate customer requests while keeping one application that works for everyone.
The industry has been working on this. Companies like Pendo and WalkMe help users through complex applications with in-app guides, walkthroughs and contextual assistance, and those tools have an important place.
But I've often wondered whether we could approach the problem from another angle.
Instead of helping users figure out where to go and what to click, what if we reduced the need for that navigation altogether?
One Application, Different Users, Different Needs
Most applications are built around predefined interfaces and workflows. Product managers, designers and developers decide how information is presented, how features are organised and how users navigate between them. That's necessary: an application needs structure.
Modern applications already accommodate different users in some ways. Role-Based Access Control decides which pages, features and actions each role can reach. Some applications add custom dashboards, saved views and configurable workflows.
But controlling what a user is allowed to access isn't the same as letting them decide how they work with what they can access.
Consider two doctors in the same hospital with identical roles and permissions. One spends most of the day reviewing patient histories; the other works mostly with prescriptions and treatment plans. Same functionality, very different routines.
Where customisation exists, it's limited to what the developers anticipated, and using it often means finding the right settings page and working out which option affects which part of the application. Some preferences, such as themes or font sizes, apply everywhere even when a user only wants a change on one page.
So when a user wants something slightly different, they adapt to the interface, request a feature or find a workaround.
Why must users always be the ones adapting?
What If Users Could Simply Ask?
For decades we've used graphical software through menus, buttons and links. Need something? Navigate to it. Want to change something? Find the setting. Need to do something? Follow the sequence of clicks.
Click, click, click.
Those methods have served us well, and they aren't going anywhere. But why should they be the only practical way to use increasingly sophisticated applications?
We're already seeing approaches that let AI interact with existing software. The Model Context Protocol (MCP), for example, allows applications to expose tools and functionality to AI assistants. That's useful, and it opens up interesting possibilities. But I've also wondered why users should have to rely on a separate assistant when they could interact just as intelligently within the applications they already use every day.
What if users could also tell the software what they want, in ordinary text or speech, without leaving the interface they're already familiar with?
"Put today's appointments first."
"Hide these columns. I don't need them."
"Show me all outstanding invoices from last month."
The application understands the request and carries it out, provided the user has the permissions to do so. Users could rearrange their dashboard, resize sections and change how information is displayed, without the development team building a feature specifically for them. And tomorrow, their layout is still there.
This isn't about replacing buttons with a chatbot. Sometimes clicking a button is much faster than typing a sentence. The point is choice: navigate the interface yourself, or say what you want done.
Most of the functionality users want already exists in their applications. The problem is how they reach it.
But Should Everyone Be Able to Redesign Their Application?
Giving users more control sounds appealing, but without boundaries it creates a different problem.
Imagine a support agent helping a customer. Ordinarily they'd say "open this page, find this section, click this button." But if every user can generate entirely new interfaces, introduce arbitrary components or change how the application works, support faces countless variations nobody else has seen. What works for one customer may not resemble what another sees.
Some newer approaches even allow AI to generate new interface code dynamically. That's powerful, but it can also introduce interface variations and code paths developers haven't individually reviewed.
I don't think the answer is to make every user a software designer. What users need is a contract, not source code.
Developers declare which existing components can be personalised and which existing actions can be performed. Users rearrange approved sections, hide columns they don't need or change how supported information is displayed. They never generate application code, invent backend functionality or bypass their permissions.
That keeps the variations knowable. Every change is one of a small set of known operations, so it can be reset, restored to defaults or undone. A support agent may still need to know which layout a customer is using, but that's a far more manageable problem than supporting an unlimited number of generated interfaces.
Greater flexibility, without sacrificing predictability.
What About the Developers?
As much as I want users to have more control, it shouldn't come at the cost of developers building and maintaining a whole new interaction system.
Making these interactions possible is one thing, making them reliable enough for everyday use is another. There are existing permissions to respect, user preferences to save, actions to validate, changes to confirm and interfaces to integrate with. And all of that needs to keep working as the application evolves.
Should every software company build and maintain that infrastructure itself?
We've faced this choice before with cloud infrastructure, authentication, version control, feature flags and in-app guidances. Some companies build their own, for good reasons. Many rely on specialised solutions because that's not where they want their engineering effort to go.
What We're Building
These questions led my brother and I to build ClickLess, an SDK that helps software companies give their users more control over how they use existing applications.
Developers wrap their existing components and declare what may change: which sections can move, resize or hide, which settings users can adjust and within what limits, and which existing actions users can perform. Users then ask, by typing or speaking.
The AI never gets unrestricted control. The model only proposes changes from a small, fixed set of operations, and ordinary code checks every one against what the developer declared before anything appears on screen. Users preview a change before keeping it, can undo it later, and their layout is saved for them alone. When the application ships a new release, their changes carry over to the sections that are still there. New sections appear as the developers designed them, and a section that has been rebuilt starts fresh. Actions run through the application's own code with the user's own sign-in, so existing permissions apply unchanged, and anything that modifies data asks for confirmation first.
A few safeguards matter as much as the features:
- ClickLess checks every request, typed or spoken, for anything that looks like a password, PIN, card number or key. A request that seems to contain one is turned away: it isn't used to plan a change, and it isn't stored.
- If ClickLess goes down, the application keeps working. Users still see their saved layout, and the application's own buttons and menus still respond. Only requests to ClickLess have to wait until it's back.
We've built the engine, a React SDK, a demo application and an administration dashboard.
How much work is it to integrate? We tested ClickLess on five open-source admin templates using different frameworks and UI libraries, including Next.js with Material UI, Bootstrap, react-admin, Ant Design Pro and plain Tailwind. We integrated ClickLess without replacing or maintaining separate versions of the existing UI components. The first working change took between two and six minutes, and covering the main pages took between sixteen and thirty-eight minutes. Across these tests, ClickLess handled about 950 requests.
These were internal trials using an AI coding agent following our integration guide, not independent developer benchmarks. But they gave us an encouraging starting point.
We've also integrated it into selected pages of a clinic application built on Medplum, an open-source healthcare platform, to see how it holds up in a realistic product.
You can learn more about what we're building at clicklessapp.com. We also have a working demo, with access currently limited while we gather feedback and prepare for wider testing.
An Unexpected Benefit: Understanding What Users Actually Want
Product teams learn what users want through interviews, support tickets, usage analytics and feature requests. All useful, all limited.
A user can be frustrated every day without raising a ticket. They might navigate through several screens without knowing there's a better way, or never request a change, because it seems too small.
In an application where users can simply say what they want, those preferences surface:
"Keep my upcoming appointments visible."
"I wish I could see patient history and previous treatments together."
Even when the application can't do something, the request itself is useful.
What if product teams could learn not only how people use their software, but how they wish they could use it?
ClickLess's administration dashboard records the changes users make and keep, and the requests the application couldn't fulfil, grouped by screen. A team might find many users asking to see information from two pages together, which points to a workflow worth improving. Or they might find a section users often hide, which is worth a closer look.
These signals need careful interpretation. Hiding a section doesn't mean a feature is unnecessary, and requests aren't a substitute for research. But alongside analytics and customer feedback, they show what users are actively trying to accomplish.
Could Developers Just Build This Themselves?
Absolutely. Developers can build most of the tools they currently rely on others to maintain.
The question is whether it makes sense for the company. If a team can build exactly what it needs quickly and maintain it cheaply, building it in-house might be the right choice. If another team would rather integrate something and focus on its core product, that should be an option too.
The value isn't just in the technology we've built, but in what it makes possible: less complexity for developers, better experiences for users, and deeper insights for product teams. Those are things we still need to prove beyond our own testing.
Putting the Idea Out There
You can spend an enormous amount of time trying to get everything right before showing anyone. There's always another feature, another improvement, another edge case. You never reach a point where everything is completely ready.
We've seen this usability problem repeatedly, built a first approach to it, and the next step is to put it in front of developers and software companies outside our own circle.
Some will think it's unnecessary. Some will prefer to build their own. Some may have solved this internally already. Hopefully, some will find it useful enough to try. I want to hear from all of them.
Identifying a problem doesn't mean you've found the right solution, and a working solution doesn't mean companies will adopt it. The only way to find out is to let people try it, challenge it and tell us what we're missing.
Final Thoughts
Traditional interfaces aren't going away, and not every interaction needs AI. Buttons, menus, forms and carefully designed workflows still serve important purposes.
But there's an opportunity to make software less rigid:
- For users, less time navigating and more time getting things done.
- For developers, delivering that without building the infrastructure themselves.
- For support teams, more control for users without unpredictable, AI-generated applications to troubleshoot.
- For product teams, a clearer picture of what users want, including what their applications don't yet do.
I believe software should become more powerful without becoming more difficult to use.
If you build or maintain a SaaS application, I'd love to hear your thoughts. Would you give your users this level of control? Have you tried building something similar? And what would concern you most about integrating an SDK like ClickLess into your application?
Top comments (0)