My Experience in a Software Engineer Capstone Program
Preface
This story starts with my career plan. I used to work as a Data Scientist and in RPA (Robotic Process Automation) in the financial industry, where I also built some full-stack web applications. From the moment I got into web development, I was full of curiosity about this field.
At the time, I proposed presenting how each department used RPA in the form of a dashboard, and put together a simple proof of concept (POC). When my manager saw the dashboard, they were impressed and even invited other colleagues to evaluate the website I had built. In that moment I felt a deep sense of accomplishment, which sparked my interest in moving toward web development.
The language I usually work in is Python, and the frameworks I develop with are mostly Flask and FastAPI paired with Postgres. To deepen my web development skills, I evaluated a number of current software courses, and eventually decided to join the Software Engineer Enterprise Capstone Program at Hexschool.
About the Course
The course mainly uses Node.js with MongoDB — two technologies I had never worked with before. I was determined to learn these new technologies well and boost my career competitiveness.
This course is primarily project-driven, and it can be roughly summarized in four points:
- Complete a web development project in about three months
- Plan website wireframes from scratch
- Learn new technologies in a short time
- Collaborate remotely with other engineers
I’d also like to add that there was a live online lecture every Friday, and we aligned development progress with our capstone coach every Monday. Since the technologies taught in the course were also applied to the project, there was even more motivation to attend the lectures on Friday nights. Weekends were for sprint development, so that we could sync our progress with the coach on Monday.
Project Introduction
Our project was called “Superhandy,” with the motto “Give yourself superhuman power in everyday life.” We wanted to provide a platform where users could easily find tasks they need help with. At the same time, we wanted users to feel capable, like a superhero, of helping others solve problems and realizing their own self-worth.
Live Demo: https://superhandy-frontend.zeabur.app/
GitHub Backend: https://github.com/erik1110/SuperHandy-backend
GitHub Frontend: https://github.com/erik1110/SuperHandy-frontend
In summary, it’s a task-matching system that connects “clients” who need help with “helpers” who provide it. We built four core features:
- Map-based task search

- Map-based task search
- Skill ratings

- Skill ratings
- Chat room

- Chat room
- Member points top-up

- Member points top-up
About the Team
Our team had five engineers — two on the backend including me, and three on the frontend. I thought our team’s development efficiency, remote collaboration, and two-way communication were all excellent.
We usually held a full-team meeting on Wednesday and Sunday nights, where everyone participated and focused on the milestones of the whole project. For example, planning the website architecture together in the early stage, discussing the major features in the middle stage, and tracking the development progress of frontend-backend API integration in the later stage.
Backend meetings were usually on Sunday afternoons — sort of a pre-meeting before the evening session — where we discussed backend progress and where we needed help. So I tried to wrap up my own tasks before Sunday afternoon.
We met via Discord voice chat, as shown below.
(The backend folks formed their own little clique and even opened a separate backend room 🤣)
Choosing Technologies
Everyone’s time was limited, and we all had day jobs, so we listed out the technologies we might use for this project. Each person assigned point values to the technologies they wanted to learn (one point equals 4 hours), and the total came out to around 15 — representing the technology points we could learn in that time. (It’s a lot like playing online games as a kid: at the start your skill points aren’t quite enough, so you can only invest in what you want most.)
As shown below, this time I focused mainly on learning Node.js and planning the database environment, with secondary priorities including third-party login, payment integration, and cloud deployment.
The first sentence of the economics textbook: “Resources are limited, desires are infinite.” Learning multiple technologies in a short time is extremely difficult, and you might end up a jack of all trades, master of none. It’s better to circle the skills you want most from the start, and use a quantified approach to make the best use of your time.
Planning the API
Finally we reached the API planning stage, brainstorming what features might be needed based on the wireframes. Listing things out in a table was crucial here. The coach wanted us to finish login and user accounts first, so we could develop them while listing them out.
At a minimum, the fields needed to include role, page group, API name, API path, and method. Other fields depended on our project’s needs, such as progress, priority, and so on.
While planning the API, we also listed out the MongoDB collections in parallel.
Development Phase
After all the theory, it was time for the real battle 😆 We started development around mid-May. On the backend, we could begin by setting up MongoDB and Swagger Docs and getting familiar with Node.js syntax. One thing to mention: if you kept up with the weekly live lectures and did the homework, getting started with Express and Node.js would be very quick.
The backend’s job was to implement each API from the list into the Swagger Doc one by one.
The rough order of backend feature development was:
- Login, registration, and email
- User information
- Home page
- Posting tasks
- Finding tasks
- System notifications
- Chat room
- Payment integration
- Third-party login
The coach’s review standard at this stage was basically whether two roles could interact. For our project’s needs, the task system we designed included “helpers” accepting tasks and “clients” posting tasks. So roughly speaking, completing up to point five was the main functionality of this project, while points 6–9 were bonus features. Since development time was limited, if the main features weren’t built first, the bonus features would be useless.
I think the hardest part of this project was posting tasks. Our requirement was to build a task-order system, where orders could have many different statuses, plus a draft area and an unlisted mode.
As a side note, in the previous stage we also considered this and started planning the table below. This table also had to be discussed with the whole team, because it affected how the frontend would render the screen. Since we defined the meaning of each status first, we could develop the task-posting features according to this table.
Collaboration Tools
Below are the collaboration tools we used, and the project slides were made with Canva.
Reflections
After this project, besides making a group of engineer friends, we also completed a great side project, which gave me a real sense of accomplishment and reward. Since I joined the progress meetings with the coach early each time, I could also see other teams’ progress. Some members of other teams might have been busy with company projects, frequently working overtime, or in special situations, causing their progress to fall behind. So I’m really grateful that my teammates were all so capable — everyone’s progress was incredibly fast, and we covered for each other and joked around.
Another thing I want to mention: work is already exhausting, so why do people still study and improve their skills after hours? I think there are two reasons:
- Time planning: How many people remember the goals they set at the beginning of each year and actually accomplish them by year’s end? I think not many can do this. So joining a well-structured course, following the schedule, and having a group of partners reminding and learning alongside each other is, in my view, a pretty good approach.
- Self-improvement: Everyone wants to improve their skills, but more importantly, to boost their workplace competitiveness so they can show a side project in future interviews. By actually building something and applying the technologies, these skills become your own real expertise and true ability.
Thank you for reading this far. If you don’t mind, feel free to give the author a round of applause for encouragement. Thanks 😆