Project Overview
The Confetti Cannon is a branded remote online notary (RON) platform intended to be used by any small businesses that need to facilitate secure, official remote document signings. This project isn't (yet) a functional application; instead, this is intended to showcase some of my skills as a project planner and systems designer. I created a specification document, wireframes, and user flow diagrams, in order to pave a clean foundation for a team of developers to implement.
Learning Outcomes
These are topics that I explored while working on this project; it's not a list of things that I've "mastered", moreso a list of things I learned about and/or used.
- Frameworks
- ReactJS
- TailwindCSS
- Jitsi Meet
- WebRTC
- Atlassian Suite
- Figma
- Jira
- Confluence
- Amazon Web Services
- Amplify
- EC2
- Key Management Service
- Chime
- Computer Science Concepts
- Data Structures
- Thinking Algorithmically
- Calculus for Machine Learning
- Network Security
- Operating Systems
Reflection
This project introduced me to systems design and project management. It was full of difficult lessons, and ultimately ended in failure to launch; I'm determined to make it a success. It's a pretty beefy undertaking in concept, and at the time I started working on it, I wouldn't have considered myself as capable of pulling it off as I am now.
Context
The CEO of the company I was working for approached me in early August 2022 to see if there were any possibility of replacing their existing RON platform with our own, proprietary SaaS that we could market to other businesses. My title had recently changed to Web Developer, and I was a plucky 25-year-old determined to prove that I earned it.
At a company summit in September 2022, I gave a solid presentation about migrating our infrastructure to the cloud; at the end of it, I presented my first steps in the planning phase toward the new RON platform.
What I Thought I Should Do
I knew that I was pretty in over my head, so I talked with the CEO again to set up a game plan for how I was going to get this on its feet.
I started prototyping the Confetti Cannon at the tail end of 2022, tinkering with AWS Amplify to see if I could get the functionality I was looking for out of it (somewhat, but at the time it seemed like a much more data-driven application engine). This was before I had done any form of documented, concrete planning; I had considered the amount of work the project would take, but I didn't plan or document it. This is when I first experienced the impact of starting giant projects without planning workloads.
We ended up turning the RON platform into a backburner project; every month, I would dedicate a few days of time to its research and development. Most of that time was spent learning and documenting the tools that would go into building something like this, which oftentimes felt like I was accomplishing nothing (because of the relative lack of code-writing), but turned out to be quite the opposite. This is when I learned to value workload planning, and that I would need more than myself if this project was going to actually launch.
Instead of stumbling my way through building shoddy components, I spent time reading about how to build applications, frameworks I might use, how to grant single-use temporary credentials to document access and prevent fraud, and much more.
I needed to make sure that this thing could compete with enterprise applications, and the only way to do that was to learn how enterprise builders think. I needed every resource I could possibly get my hands on.
What I Did
After a year of launching as many services and automations for the company as I could (Confetti Bits, Celebrator Creator, etc.), I felt that it was time to approach building the RON platform again. I had another chat with the CEO to discuss next steps, and she put me in touch with a team of developers in Ukraine that would be willing to contract the project.
It was then at the end of November 2023 that I had had my first real experience in a (virtual) room with other developers. I was the developer at my company, and prior to me being promoted, that role did not exist. Prior to this meeting, every project, every automation, every line of code, was known only to me, my keyboard, and my rubber ducky.
I had been translating low-level tech concepts and project breakdowns into english for several years at that point, and I was floored being in a video call with professionals overseas (who were in the middle of a war, by the way).
After the consultation with our new tech partners, I got to work building the specification document and the resources that you see here. I don't think I can post everything, but I can show you some of the work that I put in. There's a ton more where this came from.
Results
Ultimately, the project never launched. I vastly underestimated the scope, and it ultimately led to burnout. It was a hard lesson that shaped my approach to future projects. I ended up leaving the company with a collection of the documents I drafted, which in part is what's showcased here.
I learned the importance of clear communication when working on large projects like this; I used what I learned from my theatre degree and graphic design minor to ask important clarifying questions, and answer them in kind, to good effect. What I didn't ask for was help, and trying to do it all alone is what really ended up killing this project.
Apart from that, I learned a lot of new concepts in software development and computer science: frameworks, tools, web services, operating systems, container orchestration, and more.
