Vianor

• 

  Sign in Page

• 

  Onboarding

• 

  Venue Options

• 

  Reviews

Inspiration

Vianor was inspired by a simple but often overlooked problem: most restaurant and cafe discovery apps are built for a “default” user. They tell people what food is popular, how aesthetic a place looks, or how close it is, but they often leave out the information that disabled, neurodivergent, and accommodation-seeking users actually need.

For many people, going somewhere new means asking questions like: Can I get inside? Will it be too loud? Is the lighting overwhelming? Is there enough seating space? Will the environment actually work for me?

We wanted to build a tool that makes those questions easier to answer before someone leaves home.

What it does

Vianor helps users find cafes and restaurants that match their personal accessibility needs. Instead of giving every location one generic accessibility label, Vianor lets users set what matters most to them, such as mobility access, noise level, lighting, and seating.

The app then generates a personalized match score for each location. Users can also submit their own match score after visiting, helping the platform improve based on real-world experience.

How we built it

We built Vianor using a full-stack web architecture.

For the backend, we used Node.js and Express to create API routes for signup, login, user profiles, venue search, venue details, and user-submitted reviews. We used Supabase as our database to store users, accessibility preferences, venues, and accessibility reviews.

We also integrated the Google Places API so users can search for real cafes and restaurants nearby. Venue data from Google Places is combined with community-submitted accessibility information to create a more useful experience.

Our main database tables included:

• users
• user_profiles
• venues
• accessibility_reviews

Instead of letting users submit one separate overall score, we designed the review system around specific accessibility factors like mobility, noise, lighting, and seating. When users review a place, their ratings contribute to the venue’s accessibility data, which helps update the match score shown to future users.

Challenges we ran into

One challenge was deciding how to represent accessibility in a respectful and accurate way. We did not want to reduce accessibility to a simple “yes” or “no,” because a place can work well for one person and not work for another. That led us to focus on personalized access needs and match scores.

Another challenge was data collection. Restaurants often do not provide detailed accessibility information, so we designed Vianor around community feedback and user-submitted reviews.

On the technical side, we worked through setting up Supabase tables, connecting the backend to the database, integrating Google Places, handling Git branches, resolving merge conflicts, and making sure our API endpoints worked correctly.

Accomplishments that we're proud of

We are proud that, instead of creating a generic rating system, we catered to individual needs and real user experiences.

We are also proud that we built a working full-stack prototype. Our backend connects to Supabase, supports user signup and login, saves accessibility preferences, searches venues through the Google Places API, and stores user-submitted accessibility reviews.

One major accomplishment was adding a user match score feature. This lets visitors share how well a location actually matched their needs, making the platform more grounded in lived experience rather than only predicted data.

What we learned

We learned that accessibility is not just about whether a place has a ramp or a label that says “accessible.” It is about whether a person can actually enter, navigate, sit, communicate, and feel comfortable in that environment.

We also learned how important it is to build systems that listen to users directly. By letting users submit reviews, Vianor values lived experience instead of assuming that an algorithm always knows best.

Technically, we learned how to build and connect a backend with Express, Supabase, and external APIs, as well as how to collaborate through GitHub branches and pull requests.

What's next for Vianor

In the future, we would like to add more accessibility categories, stronger filtering, and a more detailed confidence system for each location. We would also like to make the interface itself highly accessible, with screen reader support, keyboard navigation, plain-language summaries, and low-cognitive-load design.

Vianor’s goal is to make local discovery more inclusive, more personal, and more trustworthy for people whose needs are too often ignored.

Built With

• express.js
• javascript
• node.js
• sql
• supabase