VedranCoworking · Web, mobile & AI · 2026
tersOS
Designing one connected operating system for running a coworking space and growing its community.
- Role
- Solo product designer
- Team
- tershouse operators and BetaStudio engineers
- Timeline
- 2026 · launch and live operation
- Outcome
- A live seven-module platform that runs tershouse's daily coworking operation.
At a glance
- Led product design independently across web, mobile, and AI
- Connected operator workflows with the member community experience
- Shipped a seven-module system now used daily at tershouse
Prefer the short version?
Don’t want to read the whole case study? I got you.
The tersOS application presentation is under construction. The viewer is ready and the deck will appear here as soon as it is added.
01 · The problem
One coworking space was being stitched together across too many disconnected tools.
Running tershouse meant coordinating rooms, memberships, teams, credits, invoices, events, check-ins, messages, and member support. The team had already spent a year using another coworking platform, yet operators still had to piece together information from multiple tools and rely on manual workarounds.
Members felt the same fragmentation from the other side: reserve a room in one place, pay an invoice in another, discover an event somewhere else, and leave the product to speak with the community. The space felt like a collection of transactions instead of one living place.
The design challenge was to create one product model with enough operational depth for staff and enough everyday simplicity for members, without reproducing the bloat tershouse wanted to escape.
Run the space efficiently without designing the life out of it.
02 · Process
The operating space became the research environment.
tershouse was both the source of the problem and the live environment for understanding it. The team drew requirements from hands-on space management, recurring front desk questions, and front desk logs rather than abstract feature requests or sales calls.
I worked with the operators closest to those workflows to map how spaces, people, teams, plans, credits, bookings, events, invoices, and conversations affected one another. That operating model gave the interface a stronger foundation than designing each feature in isolation.
The product also had to serve operators, members, visitors, and an AI assistant across web and mobile contexts while remaining coherent as operations, billing, community, events, displays, and AI evolved in parallel.
03 · Product direction
One domain model supported two deliberately different experiences.
The operator dashboard and member app became two views of the same system, not separate products. An operator's action, changing a booking, updating a membership, publishing an event, or issuing an invoice needed to remain understandable when it reached a member's account, calendar, feed, or conversation.
Operators needed dense, comparative views for coordination and administration. Members needed fast, focused paths for actions they performed throughout the day. I preserved shared concepts, terminology, and object states while adapting hierarchy, density, and navigation to each context.
Four decisions carried that direction across the product: community remained a core workflow, account relationships stayed visible instead of becoming isolated records, search and communication acted as connecting layers, and TersAI provided a shortcut through the system rather than replacing it.
Consistency meant preserving the product's decision model... not copying the same screen everywhere.
04 · Bookings and space
Availability became a shared, live picture of the workplace.
Bookings were a central test of the shared system strategy. Operators needed to compare rooms, timing, ownership, availability, and conflicts across a week. Members needed a much shorter path: find an appropriate space, understand when it was available, and confirm it with confidence.
I designed the operator calendar as a dense coordination surface, using time, room, booking ownership, and status together in one view. The member flow reused the same availability model but reduced it to the decisions required for one reservation.
05 · Community loop
The member app became a community surface, not only a booking utility.
A booking only app would solve access to space but miss much of the value of coworking. I designed the feed, post composer, events, profiles, and messaging patterns as first class parts of the member experience so operational activity and community participation could reinforce each other.
The composer kept everyday updates lightweight while supporting images, files, and tags when members needed richer posts. Published content could lead naturally into comments, direct conversations, event participation, and discovery across the workspace.
06 · Membership and billing
The account became a connected relationship, not a stack of records.
An organization's members, plan, credits, invoices, payment method, and activity all influence one another. I kept those relationships visible within the team and billing experience so an operator could answer common account questions without jumping between disconnected administrative areas.
The same structure gave members a clearer view of their team and billing context. This reduced the conceptual gap between what an operator managed and what a member saw.
07 · Findability and communication
A broad system still needed fast ways through it.
Unifying the platform removed tool switching, but breadth created a new risk: people could not be expected to remember where every object lived. I designed global search as a second navigation layer, grouping results by meaning across people, posts, messages, invoices, bookings, and settings.
Messaging kept direct and group conversations close to the workspace context. Notification controls let members decide which community, booking, event, and account activity deserved attention. Together, these patterns made a broad system feel immediate without becoming intrusive.
08 · TersAI
The assistant became a conversational path through the operating system.
I designed TersAI around the same rooms, bookings, members, events, billing, and workspace information used elsewhere in tersOS. A member could express an intention in plain language, find a room, register for an event, understand a charge, or locate information without first knowing which screen contained the answer.
The shipped interaction grounds answers in live space data and existing product rules. For a booking, TersAI can show the matched room, capacity, amenities, price, and alternatives, it asks the member to confirm before completing the action, then returns a booking confirmation. Questions it cannot resolve are handed to a person with the conversation context attached.
AI worked as an accelerator through a coherent product, not as a substitute for one.
Showing image 1 of 6.
09 · Delivery and outcome
The system shipped and became the software tershouse runs on every day.
I led the product design independently and partnered with tershouse operators and BetaStudio engineers to carry the shared product model across web, mobile, and AI interactions. The result is a live platform used for real coworking operations, with connected experiences for the people running the space and the members using it.
As of August 2026, tersOS says 100% of tershouse runs on the platform every hour of every day. The public product describes seven modules supported by 133 API endpoints, while TersAI handles roughly 100 recurring questions a week from live workspace data and passes unresolved requests to a person with context attached.
Those figures show that the designed system shipped, operates at real world breadth, and is used in a live space.
The strongest verified outcome is the product itself, one connected system running a real coworking operation.