Creating the Platform that Delivers Action-Based Scholarships
I joined ScholarJet in December 2015, when it was only a vague idea. My answer was pretty much a straight up “Yes!” when Tuan and Joe asked me to join their team after explaining their vision and mission. One of the reasons this decision was so easy to make was because their idea aligned so clearly with one of my goals, which is to help more students get into college, especially minorities.
A little over two years has passed since I joined ScholarJet, and in that time, we have had a positive impact on so many students who have participated in our action-based scholarships, both financially and emotionally. And our impact grows every day as we see new students sign up on our platform and as we post more scholarship challenges. But how did we create this? Let’s find out!
From MVP to 1.0
Our MVP
It all started with an MVP, minimum viable product. When I joined the team we were all very eager to make an impact. We wanted to learn how students would respond to action based scholarships, and we wanted to to start helping students pay for college- all this as soon as possible. So we needed to build something fast, really fast. We had multiple meetings to discuss the features that we wanted to have in our platform. We brainstormed so many ideas and features that it would take way too long to implement them. We had to narrow them down if we wanted to deliver value any time soon. We took our list of features and prioritized them. We had several long discussions of which feature is more important than the next one, or whether we should use one tool or the other.
For example, when we were building the feature to allow students to submit videos to challenges, we couldn’t decide upon which tool to use. Some of us thought we should use a third party, like YouTube, and take advantage of the features it already had. Others thought this didn’t sound right for our purpose. We might not always want student submitted videos to be public on YouTube’s platform. Plus, we would be giving away some control over the content. So after a couple of meetings and long discussions, we decided to build our own tool for the feature.
In the process of building our platform, we were learning a lot from students and companies. More interactions with students and companies armed us with data about how they behave and interact with the information we give them. This helped us understand what data points were most important to them as consumers. We made adjustments to our initial set of features and our platform based on each conversation until we felt we had built a set of features we thought were optimal for our users at the time. So now we had the right functionality, but we were missing something…an experience we wanted to deliver and one we thought our users deserved.
SCOUT
We had experienced software engineers on our team but immediately saw an opportunity to hire resources who could help us improve our platform’s user interface/user experience (UI/UX).
After finishing our MVP with the right set of features, we were ready to move into a stable, user friendly, release. We explored several options in hiring expertise for product design and our criteria was simple — we wanted a design that was appealing, engaging and user friendly. We ended up applying for and were accepted into Scout, Northeastern’s student-led design studio for startups. Out of over 100 ventures that applied for Scout that semester, we were among the 4 ventures that were picked. We were introduced to the team and we started working together right away. In just a couple of months and after countless discussions and brainstorming sessions over color scheme, fonts, logo design, etc., Scout delivered a stunning design for our website, that looked engaging, was user friendly, and promoted ScholarJet’s brand. We integrated the design into every aspect of our brand and our platform, which is what you see today, ScholarJet 1.0.
Before
After
Our Architecture and Stack
For those interested in software development, here’s a brief summary of our architecture and stack.
Backend/Server side
- Java / Java EE — programming language/framework
- Wildfly — application container, where our Java app runs
- Linux — the operating system our app runs on
- MySQL — the database server where we store our data
Third party services
- DynamoDB — NoSQL database we use to store temporal data
- Simple Cloud Storage Service (S3) — Where we store our application’s files
- RDS — where our MySQL database resides
- EC2 — for computing and virtualization
- Elastic Transcoding — for video processing
- App Plan Service — where we run our docker containers
- Application Insights — to analyze and track how our application behaves as users use it
- Container Registry — to host Docker images
Front-end/Client side
- Angular (5+) — hosted in Firebase (Google), along with other static files
Development processes
- Git / GitHub — we use Git as our source control management system, and host it in GitHub
- Jenkins — continuous integration/delivery server, the tool we use to automate the testing of our code and deployment of new features
- Jira — issue management tool, where we organize our development tasks
So, what do you think about the ScholarJet platform, our process of getting from MVP to 1.0, and our stack? Have you had a similar experience, or has it been better or worse? Feel free to comment or reach out at contact@scholarjet.com.
