ROLE
Year
Type
Team
Core Leadership
Gert Tali
Product Design & Strategy
Co-led product direction. Owned interaction architecture,
UX systems, and availability model definition.
Lukas Haavel
Engineering & Architecture
Co-led technical direction. Defined system architecture and led backend implementation of aggregation logic.
Product & Mentorship
Fred Kaldre
Product Manager
Supported scope definition, roadmap clarity, and product alignment.
Jaanus Jagomägi
Product & Design Mentor
Provided strategic critique and high-level product feedback.
Background
Avail began at Garage48 (Nov 2025) as an attempt to simplify how groups decide when to meet. While building the MVP, a pattern became clear.
Plans rarely fail because people lack time.
They fail because clarity never emerges.
If availability becomes the primary object rather than the event,
groups can reach decisions earlier and with less friction.
Mapping the Coordination Loop
Groups rarely get past event negotiation. Momentum collapses before decision.
Loop restarts due to unresolved availability
What Happens
• Someone proposes an idea
• Vague replies
• Clarifications
• Suggestions
• Emerging conflicts
• Conversations stall
Why It Fails
• Individual mental modeling dominates
• Compatibility isn’t visible
• Cognitive load outpaces motivation
• No shared decision threshold
Why the Loop Fails
Availability is never externalized as shared state.
Each participant must:
Track proposed dates
Interpret partial responses
Check personal constraints
Estimate others’ availability
Recalculate as new information appears
This creates what I call Distributed mental computation.
Each individual runs the same compatibility calculation in isolation.
Compatibility remains implicit rather than visible.
Decision threshold
A decision threshold is the moment when shared clarity becomes sufficient for commitment.
Traditional tools miss this transition:
Chat apps prolong negotiation
Calendars require commitment before alignment
Neither supports the shift from ambiguity to collective clarity.
Coordination fails when clarity
never becomes shared state.
Prototype 0.1 - Event-First Architecture
The initial prototype treated coordination as an optimization problem.
How it worked
The prototype followed a calendar-synchronized optimization model.
Users connected their Google Calendar.
The system imported availability data.
A proposed day displayed automatically calculated free time slots.
Users could manually override unavailable periods.
The system recalculated and suggested the most compatible time.
After selecting a time, AI-generated activity suggestions appeared.
Participants voted on the preferred event.
Coordination was treated as a
compatibility calculation problem.
Where it broke
1. Commitment Before Clarity
Calendar synchronization required commitment before alignment existed.
2. Optimization Without Alignment
Time compatibility was calculated algorithmically.
Social coordination depends on flexibility and negotiation.
3. Ideation Before Compatibility
Event suggestions appeared before alignment was achieved.
The product increased interaction, not clarity.
Structural Insight
The breakdown was cognitive, not computational.
Each participant simulated compatibility mentally.
Group availability never became shared state.
We optimized the wrong layer.
Compatibility must be visible before commitment is required.
Availability-First Architecture
Coordination required an architectural shift: availability had to become the primary object.
We made calendar synchronization optional and introduced a lightweight manual availability layer.
This was a deliberate regression in technical sophistication to reduce onboarding friction and cognitive load.
Input Layer - Manual Availability
The input layer was redesigned to capture availability as a signal rather than as imported calendar precision.
Users mark general availability across days rather than syncing full calendars.
The model shifts from precision-first scheduling to signal-first coordination.
The goal is not perfect accuracy.
The goal is visible compatibility.
Group Availability - Visibility Layer
The second structural layer externalizes compatibility.
Instead of replicating a traditional calendar view, the system aggregates individual availability into a single shared compatibility state.
Each day encodes alignment using explicit aggregation rules:
• Fully filled green — 100% group overlap
• Partial green edges — time-range overlap within the day
• Darker purple — overlap exists, but not across the full group
Selecting specific members recalculates aggregation to reveal subgroup compatibility
This transforms availability from private data into visible structure.
The system produces three levels of clarity:
Full-group alignment
Partial overlap
Subgroup compatibility
The interface does not begin with:
“Which exact time works?”
It begins with:
“Where does alignment already exist?”
Compatibility becomes perceptible before commitment is required.
Coordination shifts from negotiation to structured discovery.
Create Plan -Precision After Alignment
After selecting a compatible day, users enter a structured Create Plan flow.
The flow introduces precision only after compatibility is visible.
Users specify:
Event type
Exact time and duration
Location
Optional description
Final confirmation
Prototype 0.1 prioritized precision before alignment.
v1 reverses this sequence: alignment first, precision second.
Commitment follows visible compatibility.
Home Timeline - Commitment Layer
Once confirmed, events enter the shared Home timeline.
The timeline encodes commitment through:
Chronological ordering
Persistent group context
Explicit participation state (“Going”)
Participation becomes publicly visible.
What was previously compatibility becomes commitment.
Temporal Hierarchy in Event Cards
The primary question encoded in each card is:
How soon is this happening?
Visual emphasis adapts based on temporal proximity:
Same day → time dominant
Next day → day dominant
Within 7 days → weekday dominant
Beyond 7 days → full date dominant
Rather than displaying uniform date strings, the interface encodes urgency contextually.
Upcoming plans remain scannable, and temporal priority is perceptible without visual noise.
Structural Difference from Prototype 0.1
Prototype 0.1 optimized for precision before alignment.
v1 reverses the sequence:
Externalize availability
Aggregate compatibility visibly
Introduce precision after alignment
Formalize commitment publicly
The redesign is architectural, not cosmetic.
Coordination shifts from computational optimization to perceptual aggregation.
The core change was not additional functionality, but a reordering of interaction logic.
Outcome
Avail v1 restructures coordination around visible compatibility.
Compatibility becomes the primary object of the system.
Input Layer
↓
Aggregation Layer
↓
Commitment Layer
↓
Stabilization Layer
Precision is introduced only after alignment is visible.
The coordination architecture is now defined and ready for behavioral validation.
Reflection
This project shifted how I think about coordination design.
I initially approached planning as a scheduling optimization problem.
Mapping real-world behavior revealed that the breakdown was cognitive, not computational.
The key insight was sequencing.
Precision introduced too early increases friction.
Clarity must precede commitment.
Removing calendar sync and AI-generated suggestions felt like regression.
In practice, it clarified the core hypothesis and strengthened the system.
Proposed Next Steps: Behavioral Validation
The next phase focuses on validating whether perceptual aggregation meaningfully reduces real-world coordination friction.
Key validation questions:
Decision Speed: Does visible full-group compatibility reduce the time required to reach agreement compared to traditional chat-based coordination?
Group Scale Limits: At what group size does unanimous overlap become statistically rare, and how should the system adapt beyond that threshold?
Behavioral Sustainability: Does manual availability input remain consistent over repeated use, or does engagement decay over time?
Cultural Variability: How do coordination dynamics shift across contexts with different norms around punctuality, commitment, and scheduling flexibility?
If aggregation does not measurably compress decision loops, the core premise must be reconsidered.