Goal Striver

Goal Striver is a personal startup project that focuses on creating a mobile app and web app to help users better manage their time and keep track of their day-to-day tasks, all while being able to focus on their goals. The challenge was to design something clean, simple, and easy to use, yet be able to fulfill all of the feature requirements needed to implement the product's key selling points. This is one of my largest project and best work so far.

• Visit Website
• View App

• Web Design
• HTML
• CSS
• Node.js
• Express.js
• Bootstrap
• App Design
• App Development
• Logo Design
• Project Manager

What I Did

The Technology Stack - Website

This was one of my most challenging web projects to date. Goal Striver was created during the period where I everything was almost new to me. Originally, the website was built using PHP as a Wordpress framework (temporarily). Then I switched it over to Laravel, but as great of a framework that was, I ultimately went with Node.js, Express.js, and MongoDB since during the technical design stage, I saw that this project could explode, and scalability would immediately become a huge problem. By going the Javascript framework route, this eliminates most of these challenges. Not only that, with the use of a Nginx reverse proxy, this helps ease the load a bit more.

The Technology Stack - Mobile App

My Co-founder and I both worked together on the development of the mobile app, although I was in full control over the design elements. Android app development was completely foreign to us. We ended up doing a approximately 3 month long hustle on developing the first version prototype of the app (which was released as 1.0.0 - but really should've been under beta). We opted to go with native Android Studio - java to develop this app. The reason being is that's all we knew of at the time for Android App Development. We wanted to make a iOS version, but no Mac OS computers. Speed, stability, and security, were the main factors that made us go with java for developing this Android App natively.

Challenges

As a whole, both technical and non-technical, Goal Striver was probably full of surprises both good and bad. Goal Striver presented a lot of challenges for me and my co-founder mainly because it was a startup project. Because of that, I was challenged to the point where I nearly had to use all of my skills on top of having to learn new skills to get this project off the ground. However, because this is a technical portfolio, I'll focus on the technical challenges.

Logo & Branding

Name

The tough part about the branding was coming up with a easy to remember name while staying relevant to the niche. Sadly, it was tough due to the fact that this niche is crowded, and all the good names were taken. I was left with Goal Striver or coming up with a name that is not from the dictionary. I ended up playing safe by going with Goal Striver. The main con of it was that when verbally spoken, it sounds like "Ghost Rider" or "Goal Driver". I also made sure to check USPTO so it's not trademarked, which I managed to trademark successfully.

Logo Design

As far as coming up with a logo design concept for Goal Striver, that part was surprisingly easy. The hard part for me was to make it in Adobe Illustrator. Fortunately, at the time, I figured out some of the "secrets" of designing logos in Adobe Illustrator the "right way". It took a few attempts before I managed to get the shapes created properly and have the right ratios and sizes.

Website

Choosing A Technology Stack

One of the tough parts of the website was choosing a technology stack. At the time, I was still new to the concept of MVC and frameworks (except Bootstrap, but that's NOT the framework I'm referring to).
I first considered CakePHP, but it was bloated, so I tried making a custom MVC framework from scratch, but that only semi-worked and the security was questionable. I later went with Laravel, which worked amazingly plus it was super lightweight and was very well documented unlike CakePHP. It was great until authentication/authorization came into play.

NOTE - This was when Laravel didn't have Passport integrated into its framework.

I decided to scratch Laravel, and went with Node.js which I fell in love with. I knew that my current hosting, Hostgator, wouldn't cut it. So I had to learn Linux for web deployment and found a cheap VPS hosting service: DigitalOcean. Node.js was super lightweight, fast, easily scalable, and very easy to manage.
Why was it a challenge to choose a technology stack? There were a lot of options, and I lacked knowledge and experience. It made things tough. That's why. Plus, I was on a very strict budget.

Database Design

I first started using Apache mySQL for a relational database structure (one-to-one, one-to-many, etc.). While designing the architecture, I saw that it could easily become something very hard to maintain and scale if not done properly. Not only that, making tables to group the relations together was not fun, especially for this type of app.
So during my transition to Node.js, I also transitioned to a noSQL database schema solution: MongoDB. By going with a document (key-value) database solution, it solves most of the hassle that relational databases have in terms of performance, scalability, maintenance, etc. The only tough part remains is what to do if the user creates millions of tasks, and it exceeds the 16 Mb document size limit threshold? I decided to just let the user keep the data for a maximum of 1 year, and it will clear old tasks, but keep a general record in a smaller maintainable size.

Mobile App

Me and my co-founder had no experience nor knowledge on how to make mobile apps. That was the main challenge. The goal we set was to get a basic app released by the end of summer, which means we only have 3 months for everything including the website to be finished.

Front End

The front end coding was semi-easy and somewhat straightforward. However, it was the UI/UX design process that made it hard, as well as performance and dealing with nested components. The hardest part in this was making it scalable, performance friendly, and easy to use.

Goal Striver is not an ordinary to do list apps. In fact, it has a ton of features (a majority that still hasn't been developed to this day that will set it apart from its competitors.) The ones we did implement was only still the tip of the iceberg, and we had to shrink things own so it's easier to use and less cluttered.

Back End

The challenging part on the backend was architecture. Goal Striver has undergone 3 major architecture changes since the first developed version. We started with the standard architecture generated by the project, which then led to me creating a subfolder solution which you can learn how to do in this article I wrote: How to Create Subdirectories in Android Studio Layouts Folder. However, that solution was quickly outgrown and we resorted to a architecture where we had Activities, Fragments, and "Helper Classes" stored in their respective generic folders.

The Result

After multiple redesigns and redevelopments, I ended up with a very clean blue and white theme which is fitting of the Goal Striver brand. As far as the mobile app goes, it still has its quirks that needs to be worked out, and it is still far from the true minimum viable product I envision it to be. I will have to learn more about Android App development to really get Goal Striver off the ground. The mobile app is currently a somewhat usable ordinary to do list app with the ability to set goals. As far as the website goes, it still lacks a proper user login dashboard which is still a work in progress along with the backend.

What I Would Do Differently

If I had to go back in time, and start this process over again, I would probably skip the PHP frameworks step, and go directly to Node.js right off the bat despite having no knowledge of the framework.

As for the Android App, I would probably go with a MVC folder architecture. For the sake of getting a more functional and proper minimum viable product out, I would probably skip having a offline feature, and focus on a must be connected to the internet to work. That means making the mobile app as just another frontend with minor backend functionality while most of the work is done via a REST API.

As far as the website's header design goes, I would probably make some slight modifications to the hero section to incorporate some organic wave shapes using several shades of blue just to make it pop out more. Not only that, it'll help make it look less dull and bland despite it looking clean and minimalistic at the moment. As far as the webapp architecture goes, I would go with a Dockerized microservice implementation. The only reason I never did it before was because I didn't know Docker existed and the concept of microservice architecture was still foreign to me.