Whadup (Beta)

The onboarding reality: what happens the second you open it

The app loads a login screen. No guest mode exists. The login requires an email or phone number. Below the login fields, a "Sign Up" link leads to a registration form. The registration asks for a name, email, and password. No social login options are available. This is a deliberate choice. It keeps the app focused on real identities. After registration, the app asks for location permissions. This is mandatory. The app only works in Leuven, Belgium. Without location access, the app shows an error message. The error message reads: "Whadup is currently only active in Leuven." This is the first reality check. The app is geographically locked. The home screen appears after location is granted. The home screen shows a list of plans. The plans are sorted by time. The newest plans appear at the top. Each plan shows the activity, location, time, and number of participants. A "Post" button sits at the bottom. Tapping it opens a plan creation form. The form asks for an activity title, description, location, time, and max participants. The location field auto-suggests places in Leuven. The app uses the device's location services for this. The form also has a toggle for "Public" or "Private". Public plans are visible to everyone. Private plans are only visible to friends. The app does not have a friend system yet. This is a beta limitation. The private toggle is currently non-functional. The app saves the plan and posts it to the feed. The plan appears immediately. Other users can see it and join. The entire process takes less than a minute. This is the app's core strength. It is fast and frictionless.

The plan detail view shows the full description. Below the description, a chat room is visible. The chat room is simple. It shows messages in chronological order. The oldest messages are at the top. The newest are at the bottom. A text input field sits at the bottom. Users can type and send messages. The chat room does not support images or emojis. This is a beta limitation. The chat room also shows the number of participants. The participant list is visible. Tapping a participant shows their profile. The profile shows their name and join date. No other information is available. The profile is minimal. This is by design. The app focuses on the plan, not the person. The chat room is the primary communication tool. It allows coordination before the event. It also builds anticipation. Users can discuss details, share locations, and ask questions. The chat room disappears after the event ends. The event end time is set by the plan creator. After the end time, the chat room becomes read-only. This is a useful feature. It prevents post-event clutter.

How posting a plan and the chat room work together

The plan creation and chat room features are deeply connected. When a user posts a plan, a chat room is automatically created. The chat room is tied to the plan. It is not a separate feature. This integration is seamless. The user does not need to create a chat room separately. The chat room is populated with the plan's details. The plan's title becomes the chat room's name. The plan's description is pinned at the top of the chat. This provides context for new joiners. The chat room also shows the plan's location and time. This information is always visible. It reduces confusion. The chat room is the central hub for the plan. All communication happens there. The chat room also shows who has joined. This creates a sense of community. Users can see who else is attending. They can message each other directly. The chat room fosters connection before the event. This is the app's unique value proposition. It is not just about finding events. It is about building relationships. The chat room makes this possible. It turns a simple plan into a social experience.

The app also has a "Discover" tab. The Discover tab shows plans that are nearby. The plans are sorted by distance. The closest plans appear first. The Discover tab also shows plans that are popular. Popularity is measured by the number of participants. This is a simple algorithm. It works well for a beta app. The Discover tab does not have filters. Users cannot filter by activity type or time. This is a limitation. A user looking for a specific activity must scroll through all plans. The app does not have a search function. This is another limitation. The app relies on serendipity. The user must browse and discover. This is intentional. It encourages exploration. It also reduces friction. The app is designed to be simple. It is not a feature-rich platform. It is a tool for spontaneous connection.

Real-world performance: what works and what doesn't

The app performs well in Leuven. The user base is small but active. A few hundred people use the app each week. This is enough for a beta. The app is stable. Crashes are rare. The app loads quickly. The chat messages send instantly. The location services are accurate. The app correctly identifies places in Leuven. The plan creation is fast. The overall experience is smooth. However, there are limitations. The app is only available in Leuven. This is a major restriction. Users outside Leuven cannot use the app. The app also lacks multi-language support. The Play Store description is in Chinese. The app interface is in English. This is inconsistent. The app does not have a tutorial. New users must explore on their own. The app also lacks a feedback mechanism. Users cannot report bugs or suggest features. This is a missed opportunity. The app is in beta. Feedback is crucial. The developer email is listed on the Play Store. However, this is not user-friendly. The app should have an in-app feedback form. The app also has no analytics. The developer cannot track user behavior. This makes it difficult to improve the app. The app's data safety is commendable. It does not collect or share data. However, data is not encrypted. This is a privacy concern. The app also does not have a privacy policy link. This is a legal requirement in some regions. The app is still in beta. These issues are expected. They will likely be addressed in future updates.

Technical detail: the app's geographic lock and data handling

The app uses the device's GPS to determine location. The location is checked against a predefined list of coordinates for Leuven. If the device is outside Leuven, the app displays an error message. The app does not use IP geolocation. This is a deliberate choice. IP geolocation is less accurate. GPS is more precise. The app also requests background location permission. This allows the app to update the plan feed even when closed. The app does not store location data. The location is only used for verification. The app does not share location data with third parties. This is consistent with the data safety policy. The app's data handling is simple. All data is stored locally on the device. The app does not use cloud storage. This is a security feature. It reduces the risk of data breaches. However, it also means that data is not backed up. If a user uninstalls the app, all data is lost. The app does not have a data export feature. Users cannot download their data. This is a limitation. The app's data handling is transparent. The developer has stated that no data is collected. This is a rare commitment. It builds trust with users. The app's privacy-first approach is a strength. It differentiates Whadup from other social apps. The app does not have ads. This is another positive. The app is completely free. There are no in-app purchases. The developer may introduce monetization later. For now, the app is a community project. The focus is on building a user base. The app's future depends on user feedback. The developer is actively collecting feedback. The app is expected to expand to other cities. The expansion timeline is unknown. The app's success in Leuven will determine its future.