Lessons Learnt From Being The Lead Software Engineer Behind Afrotada

The journey to building afrotada is a bit like the cover image of this article, over a year and a half years ago I wrote about the journey at a point when I was trying to reassure myself that I could see it through to a stage where the project becomes scalable, we had limited resources and I was the only technical hand working on both the backend and the frontend 😣.

Previously On Afrotada

When I joined the team, they had a barely adequate website that I criticized, I was challenged to build a better one if I knew so much and I picked up the gauntlet 😂. I used HTML, CSS, and Javascript to build this version of the website. At that time, I was just learning to code and didn't know anything about frameworks or SPA (Single Page Applications) After acquiring more knowledge, I realized that manually creating pages in a bid to update the website isn't a scalable way to get things done so I decide to rebuild the website using MVC.

Midway into what would be the third attempt at rebuilding afrotada, I yet again realized that MVC wasn't the way to go as I was crumbling under the weight of singlehandedly developing a full-stack application and it was quite hard to get anyone to work on the project for free (I wasn't getting paid either and I wasn't exactly liquid enough to pay anyone 😅).

Using MVC, I was able to replicate the page shown above, I had created login, authentication, and registration features, I also allowed the MVC application to route to static HTML pages I developed before to give users articles to read while I developed the rest of the application, and was already working on creating a text editor within the application, however, I had just learned about APIs being a more scalable choice for build applications and I decided not to let myself be influenced by sunk cost fallacy.

I was determined to build a scalable web application and as such I had to bite the bullet by informing the team that I was going to rebuild the website for the fourth time! with a different set of technology yet again, I realized this time that I had to split the project into a backend and frontend in a bid to reduce my burden. The focus became building a solution that could be managed by a software engineer with less than one year of experience as we couldn't afford to pay anyone.

I decided on React for the frontend (because it had a lot of newbies who were willing to learn it and we'd be more likely to get someone to take on our work as their first attempt at building a portfolio) while I used C#/.Net Web APIs for the backend, we were lucky enough to get three React frontend engineers, and we got nobody for the backend, I knew there and then that the backend would be my responsibility.

Over time three became one as two of our three frontend engineers decided they couldn't continue with us; we were grateful for their help as none of us were getting paid. I and Adedayo Aturu were left to figure out a way to complete the task as our two frontend colleagues left us at the very beginning of the project! 😣 One of the hardest parts of the work was keeping our non-technical stakeholders abreast of development and engaging their concerns while making tradeoffs where necessary.

Over the course of 6 months, exactly 201 commits for me, and 126 commits for Adedayo, we ended up building what you see today on afrotada. Getting the job done meant I had to lead the software development, cybersecurity, database management, enterprise architecture, deployment, and advisory concerning the third-party solutions we were leveraging and the cost implications. I got to experience firsthand what a day in the life of a CTO felt like, especially on a shoestring budget.

I have to give special thanks to Adedayo Aturu for his doggedness as we were mostly working in the middle of the night, we developed a routine where he'd send me his deployment package in the middle of the night, I'd deploy, give feedback, write some more backend code, deploy by around 2AM, go to bed, wake up by 4AM to prep for work, then I get back from work and resume working on afrotada by 8PM, safe to say we weren't enjoying any work-life balance 😅.

Currently On Afrotada

We have been able to ship a scalable solution that shows netizens content about African culture, curated by Africans, of Africans, for Africans, we're able to onboard users whose passwords are encrypted, and we verify their email before granting them the ability to create content which goes through a necessary review, and approval by an editor or admin-level account before the article is published on the platform.

We have a lot of ground to cover, however as far as MVP goes, our fourth iteration of the website development ticks all the necessary boxes. We have gone as far as scheduled (and automated) backups to ensure that our users' data will never be permanently lost unless they choose to delete it themselves. Over time we will be extending the functionalities of the application and we're hoping to create an IOS and Android application soon if we can get the necessary resources.

I advise you to surf the platform both on your mobile browsers and desktop browser to compare the features across both platforms, trust me when I say that we're going to be doing a lot to give you a little bit extra on your desktop as it can accommodate more bells and whistles than mobile browsers 😉.

Lessons Learnt From Being The Lead Software Engineer Behind Afrotada

Criticism Is Easier Than Coding

I underestimated how much effort it would take to build afrotada, if I had known, I may have been a lot softer with my criticism of the first iteration that the non-technical team spun together 😅. It is quite easy to be an armchair software engineer, what is harder is taking a pen and paper to describe your idea of how the solution should be developed and following through with iterative development till you have a working solution.

You Don't Know It Till You've Done It

This is especially for newbie developers who have more tutorials watched than projects pushed to their GitHub repo 😉. The best way to learn is by doing as you get to learn from mistakes, resolve bugs, and discover errors you're prone to, writing code doesn't just help you learn how to write better code, it also helps you learn about the kind of developer that you are.

Life Is Easier With Friends

There are times when an extra set of eyes is all you need to debug some code, at other times having someone to bounce ideas off can be a blessing. Lucky for me, I had Olushayo Fagbenro, while he isn't a member of the team, I did consult him when I was stuck on a problem, and there were other times when we debated best practices and when to make necessary tradeoffs. You're not an island so don't be a stranger, you need friends.

Stakeholder Management Is Arguably More Important Than The Code

It's easy to feel like the startup is nothing without the code, however, there are a ton of brilliantly developed solutions that have no users because of poor stakeholder engagement. You can't do everything on your own, it helps to have a team working with you, you must respect them and keep them in the loop. Condescending to non-technical stakeholders isn't going to help you in any way as you need people to give your code any actual value to society.

Self-Motivation Is Invaluable When Building Startups

Unless you're Sam Altman, your startup is unlikely to be swimming in cash when you start, you're going to have very lonely days when you can't seem to justify why you're spending so many productive hours on something that hasn't and may never see the light of day. Your ability to keep yourself motivated in this marathon is what will see you through, sadly relying on external motivation isn't sustainable, you will need to figure out a way to discipline and motivate yourself in this journey.

Motivating Others Is Necessary

I know it sounds weird, especially coming after the previous talking point, but you may need to be there for your stakeholders when the going gets tough, I've had to encourage members of the team when they were feeling overwhelmed and this is totally normal as we can't maintain the same level of energy every day of the week, life happens and sometimes personal issues may affect your teammate's ability to get work done, you need to empathize and motivate your colleagues when necessary.

Know When To Be Firm

This lesson isn't at war with the lesson above, you must understand that a goal without a deadline is just a dream. There are times when you need to be firm about some deliverables, or your entire team may grow complacent, and you will watch the entire startup fall apart. You may be tasked with the unpleasant job of keeping one or more members of your team on track if you're to eventually ship your code.

Business Needs Trump Some Development Best Practices

This may be a bitter pill to swallow but chances are that if you're working on a shoestring budget, you won't be able to afford all the fancy bells and whistles that software development teams swear by. You will need to run a very lean program, and this will involve using the cheapest third-party solutions and altogether boycotting some because you can't afford it.

You should optimize your solution to make the best out of your budgetary constraints, I will not mention any products or services that you can live without, but you very well know that if you're respecting YAGNI (You Ain't Gonna Need It), you won't overengineer your solution to service a market size that you can't reasonably reach within the short term.

Keep your costs low, and work with tools/solutions that are either free or cheap, I know you're so sure that the entire world will love to register on your app on the day you launch but it's mostly not true, even if you end up being right, it's a champagne problem, at that point it would be easier to raise support to finance the things your startup needs, but you may never get there if you burnt through your cash reserves on an academic exercise aimed at optimizing your code to match the heavyweights.

Done Is Better Than Perfect

Analysis paralysis has killed more startups than one can even begin to imagine. Your code is just like your underwear, you're not supposed to show anyone, but you're supposed to have them on you. I understand the need to write the best code because technical debt isn't fun, however, if your quest for perfection is keeping you away from launching then you have a much bigger problem than the quality of your code.

There's no perfect codebase anywhere, get the fear of people mocking your code out of your head, code written by 10X developers has been mocked by users who don't know any better, in fact getting people to mock your startup shows you've created something they care about enough to criticize and if that is the case look no further than the first lesson I shared with you; criticism is easier than coding. You'll be fine. Now, get back on the saddle and ensure you ship as soon as you have a working MVP 😉.

Finally

For all the challenges behind building a software solution from the ground up, I can assure you that it's one of the most exhilarating things you can do, you'll learn so much about yourself, about code, and about people that would all but make up for all the despair that you may face along the way.

If you're a junior developer trying to break into the industry, I strongly advise you to get yourself a small team of newbies like yourself in the field of product management, software development, and UI/UX, even if you don't create anything novel, an e-commerce platform (that users can interact with outside of your localhost) will give you enough experience and talking points in an interview and should hopefully land you your first job.

For the technical and non-technical audience that made it this far, thank you so much for your attention, it means the world to me, I hope you enjoy afrotada, if you have any feedback for me or about the platform, don't hesitate to reach out or drop a comment, I will discuss with the team and ensure your feedback is implemented once I have the buy-in of the team, once again, thank you very much for doing reading this article 🥂.