Welcome back to the closing chapter of the full stack series! I am grateful that you stuck around to hear the end of the journey. This post summarises my main takeaways.

I hope it provides a useful perspective of full-stack development and working with a “pseudo” (read non-paying) client.

---

Technical Takeaways

Great documentation is a life saver.

The AWS Elastic Beanstalk documentation was subpar. The service had two major releases and most of the documentation existed for the earlier release.

The lack of clear instructions made configuring production services such as logging painful. And logging is essential for production.

One of my team members spent some time looking into it but couldn’t get it to work. I also sunk equally long hours and was unsuccessful. For a “real” project, I would have brought the maintainability concerns of AWS EB to the client and advised them to consider other deployment platforms.

Thanks to this experience I realised how critical documentation is. It makes life so much easier. This is now a top-of-the-list requirement for future tech stacks.

React + MobX is a solid combo

After using React and its surrounding tools I am fairly convinced. For my next project, TypeScript would be my choice. This will provide me the opportunity to further up-skill and improve the robustness of the code-base.

Redux is a common state management library most React tutorials will introduce. However, I found MobX to be more than sufficient for my needs.

Django is insanely good for getting things done

“The web framework for perfectionists with deadlines”

That’s their tagline - copied straight from djangoproject.com.

For Python programmers I can’t imagine a more solid choice than Django for the back-end, even if you want to use javascript frameworks for the front-end.

It’s easy to set up - I found most of the tools I needed straight out of the box and DjangoRestFramework enables API calls so I didn’t sweat at all when it came to adding new blocks of lego.

Authentication was really tricky given my constraints

The project required us to integrate with a 3rd party service for various use-cases.

First, we needed to synchronise our database by pulling data at regular intervals into our database. In addition, we needed to pass the credentials into our web application and log users in automatically once they are authenticated by the 3rd party service.

To understand the technical implications of utilising these credentials, I spent a considerable amount of time trying to trying to find a solution that fits the requirements.

At the time we were unable to build the PoC so I had to pick a direction based on the documentation and tutorials I consumed. Ultimately we ended up choosing token authentication, as mentioned in part [3/5], but coming to that decision was arduous.

Database schema designs are not easy

I love doing schema designs but it can be tricky for someone with less experience. One of my team members proposed some schema changes and I spent an hour explaining why those changes are not what we were looking for.

Testing parties are stressful but fun!

Before presenting the project to the client, we ran an internal testing party (team members only) and an external testing party with the client. It was a chance to show off our work and get them to help prioritise the last 2-3 weeks of work.

Making sure that everything was working right before the external testing party was very stressful. We received constructive feedback during the testing party and that was really effective in guiding us during the final stretch of the project.

Client Relationships

Learn some Figma to impress your client check your understanding and get your client on board

Before we built the front-end the designs were mocked up and new ones added as more features emerged.

This enabled us to… y’know, agile 🏎️.

Below is an example of a mock-up we did. Yep it’s a mock-up, not a screenshot of the actual application.

Scope non-negotiables early and clearly

As mentioned previously, we needed to consume user credentials from a 3rd party service for authentication. This service had poor documentation and no source code for us to work with. Despite finding a few public repositories with similar work, the path to success was unclear.

We worked in parallel to build the features and authentication requirements but it wasn’t until the very end of semester that I eventually found a way.

This was by far the most stressful part of the project.

Unfortunately for us, it was a non-negotiable and we needed to make it work to call the project a success.

Non-negotiables will happen in every project and it’s vital to ask for extra time to scope the requirements precisely and negotiate a longer timeframe to account for the uncertainty.

Be sure to set the expectations early and give frequent updates so that they’re not chasing you up during every meeting. If the non-negotiable is extremely difficult, raise that with the client.

Always be in sync about priorities and deadlines

We spent the first two weeks of scoping out all the features, filtered them down to what we thought were essentials and sorting them by priority.

I then estimated the difficulty and uncertainty of each piece of work and worked with the client to set milestones for the project.

There were a few times where we needed to adjust the project scope after we learned something new. A healthy chunk of features were set in stone, but there were instances where we de-prioritised certain features to make room for more esssential items or requested more time for a particular feature.

Ask lots of questions, clarify how important everything is. Make sure you are always in sync with the client about priorities and deadlines.

Here are some examples of what we discussed during our project.

“We would like to change our stack to Django + React because it allows us to easily build great UI for students and teachers.”

“This feature is difficult to implement and might take time away from other essentials we’ve scoped.”

“Integrating with the 3rd party service will take a considerable amount of time to figure out. I know it’s essential to the success of this project. Is it possible to have a bigger buffer to account for the uncertainty?”

“Do students really need this? What if we did it this way?” (This way being easier and less technical)

For a paying client, negotiating high priority items will be much more difficult. Luckily we were playing the game on easy mode because our client was super understanding and not expecting much (given that we were just uni students).

Keep the client engaged in strategic decisions, not technical implementations

Stick to the agenda during a meeting and don’t include technical discussions unless the client wants to hear it.

We were scoping a feature with the client and trying to understand what they were looking for. However, as discussion progressed we subconsciously dived into technical details that were not relevant to the client.

As a team, we should’ve picked up on that and told the client that they are free to go.

Finally, ask your client for feedback. Do it more often than once

Don’t be like me… only asking at the end of the semester…

Not much to say here, ask your client for feedback on the project regularly. It can be during weekly updates:

• “hey is this shaping like out to be what we’re expecting?”
• “Is this what we’re looking for?”

The main feedback that we received was the previous takeaway.

I didn’t actually realise it at the time because the technical discussion required the client to first make a business decision, but in hindsight we should have defined a precise set of business requirements first and then took the discussion internally within the team.

Closing Thoughts

And that’s my 200hrs of full-stack!

I’m 2% of the way there to becoming an expert! 😛

This experience was valuable for 2 reasons:

1) It gave me a perspective on what being a “tech lead” is like - I was by far the most experienced student on the project and often set the standards and processes for the team. I ended up reviewing pretty much all the PRs that came through and got a lot reps in. For your entertainment, I’ve attached a screenshot of my contribution document where I just listed out all of the PRs I was involved with. 🙂

2) It mirrored what freelancing on the side would feel like - and I must say I really enjoyed it. With my full-time job it meant that I would be writing code well past 5pm but I was working on something totally different. As a result I didn’t feel overwhelmed with an endless amount of work.

It wasn’t until the 3 month mark that I started to feel exhausted as we approached the project deadline.

tl;dr it was really fun, would do it again (if I was paid…)