The Client
Future Females is a start-up that exists to increase the success of female entrepreneurs. They offer membership to a community-based learning platform, where members can access courses from world-class Creators, hand selected Founders, Executives and Changemakers. Their members also get access to online and offline events, accountability challenges, discussion forums and community fund competition.
Since their founding, they have managed to build a solid 150,000+ members community around the globe.
Context
While their growth was backed by the increasing number of community members, it had also highlighted a problem. Handling communication and providing materials became cumbersome for this number of people. Channels like Facebook, Instagram, Whatsapp were not providing enough scalability for the growth of their members. Therefore, the need for a consolidated app became obvious. This is where Equilobe Software came into play.
The Future Females team reached us with the need of a community platform. This would be delivered through an MVP type of project that was meant to go live in under a year. The features included:
Events - that users can attend online or on site
Courses with lessons, resources and Q&As,
Payment
Account profile
As their sales team considered launching in the same year, an MVP approach, that could be subsequently improved, was the way to go.
How did we start?
After the initial contact with their technical representative we started working on two different paths. Our software engineers worked on providing a solid architecture that will suffice both the requirements and the timeline. Meanwhile, our UI/UX designers worked on understanding the requirements. They provided a bigger picture of how the end product would look and feel. We strongly believe that our products should be at the highest level of quality. Therefore, product discovery was a must in the early part of the project. How did we do it?
Interviews with their team to understand the requirements
Research on similar platforms to validate the state of the current market
Iterations over wireframes proposals in order to achieve a customer centric approach
After a month we felt comfortable to start the actual development because we managed to provide the following
Wireframes that were used to shape the user experience on the app
Multiple proofs of concept that were used to validate our technical research phase
Branding and system design set
Initial iterations and infrastructure
Our first step was mainly setting up the infrastructure. We went with a cloud based approach for the most part of our infrastructure. Due to the quality of the services and also the experience of the development team we went with Azure as our cloud service provider. With a requirement to move fast, but not compromise quality the choice was obvious. Many of their services:
allow developers to easily scale their software services up or down based on demand
have an extensive global presence with data centers located in various regions worldwide (important as we have users spread through 3 continents)
offer built-in security controls, encryption, threat detection
have pay-as-you-go options and cost-effective pricing for various services. This allows developers to optimize costs by paying only for the resources they use, reducing upfront infrastructure expenses
We started simple. A development environment, with a SQL database instance. This way our team together with the product owner could see modifications real-time as commits were pushed into our Github repository. While features started to pile up we expanded this initial setup to a more complex system that included:
Azure FrontDoor profile - A CDN that ensures our users receive their requested content faster from various edge servers
Azure application insights - Used for logging purposes. This was added to both our backend solution and in our client so we could see errors and custom logging that we wanted
Azure function app - configuration so that we can run azure functions. Our main reason for this was for automation of different processes. We needed to trigger functions at specified intervals to perform tasks like event reminders, updating marketing tasks or update subscription
Azure key vault - a security layer that contains various app secrets that should not be kept directly in the repo
Streaming endpoint - as one of our main features was playing videos (we’ll get to that later) we needed a service that can serve a long video fast and load over time
SignalR - as many of the interactions in app needed to happen real-time we went with SignalR as it integrated easily with our .Net API
Storage Account - as users could upload documents, profile pictures, videos and so on we needed a storage solution that needed the least time to configure and scale accordingly
Azure B2C for authentication and authorization
UI and API
How did we choose the FE framework?
We decided to go with Angular as the UI framework. Why? Well, it is one of the most refined options that you can use at the moment. We needed a solution that is fast out-of-the box as our UI after all was meant for a community platform. With a lot of dynamic content and interactions on the page, SPA (single-page-application) was a no-brainer. Let’s also bring to the table the fact that it is used together with Typescript (static typing is the way to go in order to avoid dumb mistakes that will be hard to fix in a fast moving development process). It is maintained by Google so it has constant updates and support (also, the community contribution is quite large). Oh yeah, also AOT (ahead of time compilation), support for PWA or modular architecture made it the right candidate for the job.
We paired it up with Angular Material in order to benefit as fast as possible from the many integrations that the library has with the framework. Of course, the UI was a very important matter in this project as a user would frequently stop using an app if they are faced with bad UX or ugly UI. Because of this, we had to elevate some components from their plain material look. However, overall it was a good decision to start with a strong base of reusable components.
To monitor user interactions we also went for Google Analytics as metrics play a pivotal role in the success of any project.
How did we shape our backend?
Our backend consisted of different REST APIs implemented using the latest version of .Net Core framework in a monolith. Even though it might seem odd, we decided to implement the CQRS design pattern (in a monolith solution), it seemed like the right option due to various reasons:
Complex domain logic separated between commands and queries
Better data models that were optimized for reads and writes
Easy to extend functionality as read and write models can be adapted separately for new requirements
Separation of concerns
We combined this design pattern with other strong NuGet packages such as mediatr or fluent validation that made our life easier when developing.
For our emails we integrated with SendGrid and payments were done with Stripe. CosmosDB was added as our database to keep our discussion objects (question and replies kept as a document rather than having to model it for a relational DB).
Day to day workflow
The development team consisted of two senior developers together with a member from Future Females. Even though we follow the SCRUM methodology in many of our projects we needed to consider if it would be beneficial with our team structure. The client stated that they wanted to sync only 2 times a week. Having a two person team proved to be the right decision in order to accommodate this need of the client. They could communicate and sync their work without the need of any formalized form of communication.
The development team managed to keep the pace with the project that was changing in a very “agile” way. What do we mean by that? Features were often ideated by the client team, even after implemented. Therefore, the team was receptive to change and synced when needed, to make sure they delivered on the client’s requirements.
Launch
The initial launch included:
Events page - users can see, filter, search for events, register to attend, check description and details, join a zoom meeting from inside the app, see recording when the event has ended
Login with Google, Facebook or the classic name and password
Course page - users could start courses, see progress, resume from where they left of, download and see resources
Discussions - users can ask questions and add replies to any course, event or lesson, report or like others replies
Subscription based access - users can opt from 3 different type of subscription, can have free trials and pay from a checkout page integrated in the app
Account, billing and membership page - from there they can add profile pictures, adjust subscription, see paying history, add learning preferences
Access their app from any device as the final product was fully responsive and with an option to add it to your phone as it was a PWA
Dashboard with summarized information so users can fastly navigate to their events, courses etc.
And yes, all these features had an admin feature behind them with an interface ready so that Future Females team can work directly from the app
We had many other smaller features such as google maps integration or statistics about user registration or library of events organizers and so on. After the launch we provided maintenance and further feature development for a few months.
Conclusions
We took the challenge of this project and in less than a year developed a quality product in a fast agile way with two software developers and our UX team. We are proud of the final product and can say that all the challenges helped us evolve and become better
We had our ups and downs of course, but in the end the Future Females team has a platform where their community can join events, take courses, access learning resources and interact.
We managed to provide them the needed platform in less than 10 months and their community can grow now without limits.
