We launched the Letswork beta with a small group of operators in Dubai Internet City in mid-2025. Not a public launch. Not a press release. A handful of spaces who agreed to try the platform in exchange for no fees, direct feedback sessions, and our commitment to actually change things when something did not work.
Six months later, I want to write down what we learned. Some of it confirms what we hypothesized when we started. Some of it contradicts it directly. All of it is now baked into how we build the product, and writing it out publicly feels more honest than the usual "things are going great" update that most companies post at this stage.
What we got wrong: operator attention is extremely limited
Before the beta, we designed the dashboard assuming operators would check it several times a day. We built real-time alerts, hourly occupancy charts, and a notification feed that updated frequently. In the first two weeks of beta, almost none of the operators checked the dashboard more than once a day. Some checked it once a week.
This was not lack of interest. It was the reality of running a coworking space with a small team. The operator who manages front desk, member onboarding, maintenance requests, and the monthly invoice cycle does not have a workflow that includes "review utilization dashboard" on a Tuesday morning. Our assumption that they would naturally adopt a new monitoring habit was wrong.
What we changed: we reduced the dashboard's default view from a detailed multi-chart interface to a single daily summary. The summary shows three numbers: how many desks are empty right now, how today's fill rate compares to the same day last week, and how many bookings came through the platform today. That is the information most operators can act on in under 30 seconds. The detailed charts are still there for operators who want them, but they are not the first thing you see.
What we got wrong: operators want control over same-day availability
We assumed operators would want to expose all their available inventory to same-day booking. Our reasoning was straightforward: empty desks are perishable, same-day demand exists, put them together. What we found in the beta is that operators have legitimate reasons to hold some inventory back from same-day booking, and they need the ability to make that distinction themselves.
One operator runs a quiet-focused environment where they want to control the ambient density of the space. Filling every desk via last-minute booking would compromise the experience they have built for their members. Another operator holds a few desks each morning for walk-ins from their building who do not book online but do pay when they arrive. Exposing those desks on the platform meant they were sometimes already booked when the walk-in arrived, which created friction with their longest-standing relationship type.
We now let operators designate specific desks or a percentage of their inventory as platform-bookable versus operator-reserved. This is a small change in the UI but a significant one in operator trust: it means they can participate in the distribution network without giving up control over how their space feels on any given day.
What we got right: the no-show alert is the highest-value feature
In the pre-beta conversations, most operators listed real-time availability as their highest-priority need. In the beta itself, the feature operators mentioned most often in feedback sessions was the no-show alert. When a booked desk has no check-in logged within 25 minutes of the booking start time, the system flags it and optionally opens it for same-day booking automatically.
One of the beta operators described it as "the feature I did not know I needed." They had not quantified the no-show problem before the beta. Once the system started flagging it, they could see that a meaningful portion of their booked morning inventory was regularly sitting empty well past the booking start time. The alert gave them a chance to recover revenue they had been losing invisibly.
The lesson for us was that operators often do not know which specific losses to prioritize before they have data. We had spent months talking to operators about what they wanted in a platform, and no-show recovery never came up as a primary request. It came up when the data made the pattern visible.
What we got right: pricing flexibility matters more than pricing recommendations
We built a pricing recommendation engine that suggests adjustments based on occupancy patterns. It was a feature we were proud of. In practice, operators ignored it almost entirely, not because the recommendations were bad, but because operators do not trust an algorithm to set their prices without understanding how it arrived at its suggestions.
What they did use heavily was the rule-based pricing tool: a simple interface where an operator can say "if it is Monday before noon and fewer than 60 percent of desks are occupied, apply a 15 percent discount." That is a decision the operator made, not a recommendation they accepted from an opaque system. The difference in adoption was dramatic. Operators who never touched the recommendation feed built five or six pricing rules within the first month of having the rule interface available.
The meta-lesson: operators want to be the author of their pricing decisions, even when the decisions are automated. A system that helps you implement a rule you set is very different from a system that tells you what to do. We removed the recommendation feed from the default view and replaced it with the rule builder as the primary pricing surface.
What we did not anticipate: member behavior data is valuable to operators in ways we had not designed for
We built the platform primarily around operators managing their space. Members would search, find spaces, and book. What we did not fully anticipate was how much operators wanted visibility into member booking patterns, not just their own occupancy.
Specifically, operators wanted to know which members were booking infrequently (potential churn signal), which members tended to book at the last minute (a different service need than advance planners), and which members were consistently no-shows. These are not inputs into a utilization algorithm. They are inputs into the operator's member relationship management. Several beta operators told us they used this data to proactively reach out to members showing booking pattern changes, before the churn happened rather than after.
We are still building out this part of the platform. But the direction it has taken, toward giving operators better signal on member behavior rather than just desk occupancy, was driven entirely by what operators told us they were doing with the data we had not originally designed for that purpose.
Where we are now
The beta ran longer than planned because we kept finding things to change. That is both good and uncomfortable. It means the product is better. It also means we deferred a broader launch several times to make sure the core experience was right for the operators who trusted us with their data and their spaces during the beta period.
We did not solve everything. The member-facing search experience still has rough edges for users booking from a mobile device under time pressure. The calendar sync integration with some older coworking management software is more manual than it should be. We know where the friction is. The beta made that clear in ways that months of internal testing would not have.
What we know with more confidence than when we started: the core value hypothesis holds. Operators who have visibility into real-time occupancy and can act on it through automated pricing and availability rules recover revenue that was previously invisible to them. That is the basis on which we are building the rest of the platform.
