Stephen Gheysens

Hi there, Ravi! Full disclosure: I used to work for Twilio.

User experience and developer experience are the primary reasons I'd recommend Twilio. Starting with user experience:

• Simplicity: There's a reason companies with great engineering talent (like Stripe and Shopify) hand off the implementation of scalable 2FA infrastructure to Twilio - it's because they see improved user conversions and experience, by leaning on the dedicated Verification team at Twilio.

• Reliability: Twilio has been building out even more regionalized infrastructure the past two years for improved service reliability. The Verify service also optimizes the telecommunications providers + sending phone numbers that are used if they ever detect lower-than-usual 2FA conversion rates (if they measure that users aren't entering 2FA codes at normal rates, they automatically route traffic differently to improve and ensure messages are getting delivered).

On the topic of developer experience:

• Ease of integration: I worked with customers who had MFA proofs of concept running in one afternoon. Twilio has easy-to-understand documentation and code examples to get started in a variety of languages: https://www.twilio.com/docs/verify

• Extensibility: As you mentioned in your post, you're considering SMS and Email channels for MFA today, but want to keep your options open for improving security and UX. Twilio already offers additional verification channels, like Voice, in-app Push Notifications, and TOTP integrations with authenticator apps like Authy and Google Authenticator. For additional security considerations, Twilio's Lookup API v2 provides a useful database of information about users' phones, to complement your MFA implementation.

• Maintainability: Twilio has a solid track record for improving its Verification & security solutions since they've launched them, and last I knew while working there, planned to continue to invest strategically in these offerings.

Google Maps lets "property owners and their authorized representatives" upload indoor maps, but this appears to lack navigation ("wayfinding").

MappedIn is a platform and has SDKs for building indoor mapping experiences (https://www.mappedin.com/) and ESRI ArcGIS also offers some indoor mapping tools (https://www.esri.com/en-us/arcgis/indoor-gis/overview). Finally, there used to be a company called LocusLabs that is now a part of Atrius and they were often integrated into airlines' apps to provide airport maps with wayfinding (https://atrius.com/solutions/personal-experiences/personal-wayfinder/).

I previously worked at Mapbox and while I believe that it's a great platform for building map-based experiences, they don't have any simple solutions for indoor wayfinding. If I were doing this for fun as a side-project and prioritized saving money over saving time, here is what I would do:

• Create a graph-based dataset representing the walking paths around your university, where nodes/vertexes represent the intersections of paths, and edges represent paths (literally paths outside, hallways, short path segments that represent entering rooms). You could store this in a hosted graph-based database like Neo4j, Amazon Neptune , or Azure Cosmos DB (with its Gremlin API) and use built-in "shortest path" queries, or deploy a PostgreSQL service with pgRouting.

• Add two properties to each edge: one property for the distance between its nodes (libraries like @turf/helpers will have a distance function if you have the latitude & longitude of each node), and another property estimating the walking time (based on the distance). Once you have these values saved in a graph-based format, you should be able to easily query and find the data representation of paths between two points.

• At this point, you'd have the routing problem solved and it would come down to building a UI. Mapbox arguably leads the industry in developer tools for custom map experiences. You could convert your nodes/edges to GeoJSON, then either upload to Mapbox and create a Tileset to visualize the paths, or add the GeoJSON to the map on the fly.

*You might be able to use open source routing tools like OSRM (https://github.com/Project-OSRM/osrm-backend/issues/6257) or Graphhopper (instead of a custom graph database implementation), but it would likely be more involved to maintain these services.

I'm a bit biased, but I've always had fantastic experiences building with Twilio's tools and documentation. Years before joining Twilio, I started my own company with Twilio Video being a core component (it was a platform for online coaching), and as a one-dev-shop, I couldn't believe how easy it was. I now work here and get to help customer build quickly and effectively with these tools.

Some of the features I love include Video Insights for monitoring/debugging room and client device performance in aggregate or per session, the Compositions API for programmatically processing & exporting recordings in different formats, complementary products like Twilio Live that let you easily scale broadcast or livestream-style video experiences, the ability to store recordings directly to S3, and the integrated DataTrack API for exchanging & syncing data between participants.

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

Hi Mohamad, out of these two options, I'd recommend starting with MongoDB (on MongoDB Atlas) for a few reasons:

• Open Source & Portability - With MongoDB being open source, you have transparency into how your system will work. Not only can you see how it works, but you later have the option to migrate to self-hosted versions of the platform (decreasing costs and avoiding vendor lock-in) or move to a Mongo-compatible hosted database like Amazon DocumentDB or Azure Cosmos DB.

• Querying & Aggregation - MongoDB has been around a few years longer than Firebase, and in my opinion, that is evident from the great design and flexibility of APIs you have for querying and aggregating data.

• Tooling - MongoDB Atlas monitoring tools and the Compass GUI are great for understanding and interacting with the data in your database as you're growing your platform.

I hope this helps!