How I Built a Full-Stack Productivity Tool for Notion using Kiro

As a student developer, I'm surrounded by deadlines. At times, it becomes hard to keep track and identify which deadline to focus on when you are juggling multiple of them. To ease this process and reduce my procrastination on certain tasks, I developed GitDone, and this is the story of how it went from a simple idea to a full-stack, cloud-native application.

GitDone is an open-source productivity tool that integrates with GitHub. It lets developers create real-time deadline countdowns for any repository goal-a project shipment, a bug fix, or a version update. The countdown automatically completes when a commit message containing a specific keyword is pushed to the repository. These countdowns can even be embedded in tools like Notion, keeping your entire workflow in one place.

The Initial Spark: Prototyping with an AI Partner

The project started with a simple frontend. I drafted the first version with standard HTML and CSS, but I wanted to build a more modern and user-friendly experience. For this, I turned to Amazon Kiro.

I used Kiro to help brainstorm the project requirements, outline the architecture, and break down the development into manageable tasks. Its integrated AI agent was instrumental in the frontend development, helping me:

• Refactor my stylesheet for a fully responsive, mobile-first design.
• Implement a JavaScript-powered light/dark mode for better user experience.
• Create the client-side logic to dynamically display the unique embed link for each goal.

The Leap to the Cloud: Architecting for Production

A local prototype is one thing, but a real-world application needs to be reliable, scalable, and secure. This meant deploying to the cloud. I chose AWS and designed a 3-tier architecture to separate the application's concerns.

• The Backend: A Python application built with the Flask framework, serving a REST API and dynamically rendering the frontend.
• The Data Layer: A managed AWS RDS PostgreSQL database to ensure data was persistent and secure.
• The Compute Layer: AWS Elastic Beanstalk to manage the underlying EC2 server infrastructure, handling everything from deployment to load balancing and health monitoring.
• The Edge Layer: AWS CloudFront to act as a CDN, caching static assets closer to users and providing security by managing the custom domain (gitdone.online) and terminating the SSL/TLS certificate.

This setup was robust on paper, but making all the pieces work together was the real challenge.

The "Five Circles of Debugging Hell": A Story of Challenges

Deploying a multi-service application for the first time is a trial by fire. I systematically troubleshooted my way through a series of critical, real-world cloud engineering problems.

1. The SQLite "Death Cycle"

My first major mistake was using a file-based SQLite database. My application worked perfectly until the first redeployment. I was horrified to find that 100% of the application data was being wiped out every time I pushed new code. I learned a hard lesson about the ephemeral nature of cloud servers. This forced me to re-architect the data layer, migrating to AWS RDS to achieve true data persistence.

2. The Application Won't Start

After migrating to RDS, my application still wouldn't deploy. Digging through the Elastic Beanstalk logs, I found two new culprits:

• ModuleNotFoundError: My application.py file structure and the Elastic Beanstalk WSGIPath configuration were not aligned.
• SQLAlchemy URL Parse Error: A simple typo in the DATABASE_URL environment variable was causing the application to crash on startup.

3. The Networking Maze

With the application finally starting, it still couldn't connect to the database, resulting in 504 Gateway Timeout errors. This led me deep into AWS networking. The solution was to configure a precise set of Security Group rules to act as a firewall, creating a secure bridge between the services:

• A rule to allow CloudFront to talk to Elastic Beanstalk.
• A rule to allow Elastic Beanstalk to talk to the RDS database.
• A temporary rule to allow my local machine to connect to the database to initialize the tables.

4. The Stuck Stack

At one point, a failed configuration update threw the environment into an UPDATE_ROLLBACK_FAILED state. The Elastic Beanstalk console was locked. I had to learn how to use the AWS CloudFormation console to manually intervene, skip the failing resource, and force the rollback to complete, successfully rescuing the "stuck" environment.

Automating Success: The CI/CD Pipeline

After solving these issues, I automated the entire deployment workflow by engineering a CI/CD pipeline with AWS CodePipeline. Now, every git push to the main branch on GitHub automatically triggers a deployment to Elastic Beanstalk. This eliminated a 5-step manual process, reduced the risk of human error, and enabled true continuous delivery.

AWS Archtecture

The Final Product & What's Next

After a long journey of building and debugging, GitDone is now a fully functional, stable, and scalable application running on a professional-grade cloud architecture.

The project is fully open-sourced, and the ultimate goal is for the community to contribute and help shape its future, adding the features and integrations they desire most. The next steps I envision are integrating email notifications for deadlines and expanding support to other Git providers like GitLab. I hope to see contributions made to this project to take to new heights.

You can try the live application at gitdone.online and view the code on the GitHub Repo. Thanks for reading!

Demo Video: