What we learned from building an app to connect low-income students with tutors

Who we are, what we created, and a few takeaways

Tejasvi Nareddy
Hack4Impact
7 min readJan 7, 2018

--

GT Bits of Good is a student-run Georgia Tech College of Computing organization and Hack4Impact Chapter that connects talented undergraduate software engineers with local Atlanta nonprofits to work on technical projects. These projects are individually tailored to solve a problem that each nonprofit faces. This may range from redesigning a website to creating new custom web tools to meet specific needs. During the Fall 2017 semester, GT Bits of Good had 40 members and helped 6 nonprofits leverage technology to better serve the community.

About our project

Our group of 5 students worked with Midtown Assistance Center (MAC), a non-profit whose mission is to provide emergency assistance to low-income Atlantans in order to prevent homelessness and hunger during periods of crisis. Over the years, MAC has branched out to provide any type of support for low-income residents in the Atlanta area.

MAC wanted a service to better educate low-income, K-12 students in the Atlanta area. However, they wanted a remote solution that worked over the internet. If the students could access the service from their neighborhoods at any time in the day, it would reduce the barrier-to-entry dramatically. Additionally, they wanted the students to have 1-on-1 interactions with their teachers, similar to an online tutoring service. They emphasised that this app must be easy to use, as low-income students usually don’t have access to personal computers, meaning they’re not the most tech-savvy users.

We created a free, open-source web application to connect low-income students with tutors from Georgia Tech. Similar to how Uber helps riders find a driver to drive them, our web app helps students find a tutor to tutor them. All student-to-tutor communication is done externally through an integrated Google Hangouts session. Google Hangouts’ features (such as video chat, screen sharing, and file sharing) gives tutors an effective channel of communication with the students.

View our GitHub Repo here. Our web app is live on Heroku. We’re using a free dyno for development, so it might take a few seconds to load.

App overview

Both students and tutors register for accounts on the Sign Up page. After the approval process, students and tutors can access their individual dashboards.

In the student dashboard, students can search for tutors based on the subject they need help with, the grade they’re in, and the times they’re available. Then the student can join a tutor’s Google Hangouts session by clicking on the button. If you’re interested in backend logic for this, make sure to read the Tech Stack section!

On the tutor dashboard, a tutor sets up their tutoring schedule and kicks off the hangouts session. Any student can join this session while the tutor is active. This allows students to get help quickly anytime the tutor is available.

Student dashboard (left) and Tutor dashboard (right) with mock data.

The tech stack

We used the MERN stack for our project. This consisted of:

  • MongoDB for our data store. This NoSQL database (currently hosted on MLab) stores all our user data and some extra application-generated data used for monitoring and statistics. For more details, check out the/modals folder. It contains mongoose schema definitions.
  • Node.js with express for our back end. This express server exposes APIs that read or modify the database.
  • React for our front end. It calls our back-end APIs to perform actions and gather data to display. We used a variety of open-source modules for React, such as react-router, redux, and redux-thunk. Our package.json file contains a full list of front-end and back-end dependencies.

Additionally, we used the Google Calendar API (v3) for creating the Hangouts sessions. As expected, all these API calls are exposed in our back end. This was the most complicated part of our app! It took us a few 6-hour long “hackathons” to get this feature working. Here is how the process works:

  1. When a tutor is approved, a new calendar is created on MAC’s Google Account for that tutor.
  2. When a tutor starts a tutoring session, an event is added to the tutor’s calendar. Google auto-generates a Hangouts for the event. The Hangouts web link is then extracted and the tutor is redirected to it.
  3. Whenever a student joins the tutoring session, that student’s email is added to the calendar event in order to give them access to the Hangouts call. They are then provided the same Hangouts link.

Our CI/CD setup was very basic. Heroku is set to automatically deploy any commits on the dev branch. However, we disabled directly pushing to dev on the Github Repo. Only commits from approved Pull Requests can modify dev. Additionally, all Pull Requests must build and pass all tests on CircleCI.

Example pull request to that is blocked. A contributor must approve the changes via a code review.

Side-Note: We found ZenHub very useful for managing tasks and stories between the 5 of us.

We were hoping to add integration with AWS S3 or Firebase Cloud Firestore, but didn’t get to that this semester. We need one of these integrations to store user data, such as profile pictures or tutors’ resumes.

Takeaways & Reflection

Learn together, not alone

This was GT Bits of Good’s first semester as an organization, meaning that every member was new. Most of us had very minimal experience with web development. I’ve only created a handful of static websites previously and had no idea how a dynamic website worked.

Group members (from left to right): Sam Baek, Ganapathy Hari Narayan, Sruti Guhathakurta, Rohith Macherla, and Tejasvi Nareddy

To get all of us members up to speed, Bits of Good’s decided that all 5 projects would use the same tech stack. At first, it seemed a bit weird that we were molding 1 solution to 5 different problems. But within a few weeks, this decision made complete sense. Whenever one of the teams was stumped, they could ask any other team for help. Even better, the more experienced members ran hour-long crash courses on the MERN stack that every member could attend.

Find the perfect balance between developer confidence and development time

At the beginning of the semester, we asked ourselves:

Should we design the entire app and then start coding, or should we design and code a single feature at a time?

We knew that we couldn’t spend too much time designing the app. We only had about 15 weeks to get up to speed on web dev, design the app, and implement all major features! We wanted to start coding as soon as possible, but it would’ve been a bad idea to develop without everyone on the same page.

To get things moving, we decided to limit how much time we spend on the initial design phrase. In fact, we only spent the first 2 weeks planning and designing the overall structure our web app. We all agreed on the major features and the final outcomes of the service, but had not discussed any specific details. At the end of design phrase we had a few notes, a couple of clarifying questions for MAC, the basic structure for our codebase, and a EER diagram. We weren’t fully confident about our design when we started coding, but that was fine.

The messy EER diagram we created in our first two weeks. Even though we weren’t planning on using a SQL database, we found this exercise pretty helpful in understanding how objects are related. It also showed us what types of data we would need to store.

We jumped right into coding and discussed details when they came up. If a new feature didn’t really fit into our current implementation, we could easily rewrite some parts of our implementation. This particularly worked well with our tech stack: Since we were using a NoSQL database (mongodb) and a weakly-typed coding language (javascript), it was super easy to make changes to the codebase or our database schemas.

This takeaway doesn’t apply to all projects. Most projects need to be planned out in advance to ensure they’re feasible. For us, this wasn’t a huge concern because we knew it was doable. Instead, we had to find the perfect balance between planning the overall project to build developer confidence vs jumping into coding to decrease development time. For us, that balance was spending only 2 weeks on design.

What’s next for our project?

In December 2017, we demoed our final product to MAC. They loved it!

Together, we decided to continue this project in the Spring 2018 semester. While this project was a great success, it is just a Minimal Viable Product. We have a few features to add, such as:

  • Feedback for students on tutors
  • Better metrics on user activity
  • Better searching capabilities and matching algorithms
  • An admin portal

Additionally, we have to fix a few frontend bugs, secure our backend APIs, and document our code. We’re hoping to finish all this up next semester so that MAC will have a usable product to test!

If you have any questions, feel free to email GT Bits of Good at hello@bitsofgood.org or comment on this article below!

--

--