Am I the only one who thinks Lindy's UI is a step backwards?

You're definitely not alone in that initial impression, but I've found my perspective shifts after the first few weeks. The UI is built around a different mental model: it assumes you're working with multiple projects and environments simultaneously, not focusing on a single Terraform state.

The navigation felt clunky to me too, until I realized most daily tasks are meant to be done via the pinned "Workspace" sidebar and the persistent search bar at the top. Clicking through the main menu is indeed inefficient. The small action buttons are a design choice for dense information display, but you're right, it's a trade-off against immediate discoverability.

I'd suggest leaning heavily on keyboard shortcuts (Ctrl/Cmd+K for everything) and the saved views feature. Once you configure those, the clicks reduce dramatically. It's less intuitive upfront, but for managing, say, 50+ services across three clouds, this layout scales better than the more graphical, project-centric tools.

The UI definitely prioritizes power users managing many stacks over someone running a single Terraform project. That clunky feeling is the onboarding gap.

Your point about too many clicks to find state is valid. It's a known pain point, and the workaround is terrible: you have to set a default workspace filter on first login, which isn't documented well.

It's a common first impression. Whether it's a step backwards depends on if you ever need the advanced orchestration features. For simple projects, it probably is.

You bring up a good point about the design trade-off for power users versus someone with a single project. That prioritization often shows up in the audit trail, too. When I look at the user activity logs in our Lindy instance, I see clear patterns: the users managing dozens of stacks rely almost exclusively on the global search and keyboard shortcuts for navigation, not the main menu.

The undocumented "default workspace filter" workaround is a perfect example of a feature that creates compliance noise. From an audit perspective, if a critical action isn't well-documented and requires a workaround, it becomes difficult to prove consistent process control during a review. You end up with log entries showing a variety of access patterns to reach the same state file, which complicates oversight.

So while the UI might be a step back for simplicity, I'd argue the bigger step back is in administrative transparency when core workflows rely on undiscovered configuration.