## Inspiration

Building and maintaining software is complex, time-consuming, and can quickly become expensive, especially as your application scales. Developers, particularly those in startups, often overspend on tools, cloud services, and server infrastructure without realizing it. In fact, nearly 40% of server costs are wasted due to inefficient resource allocation, and servers often remain idle for up to 80% of their runtime.

As your traffic and data grow, so do your expenses. Managing these rising costs while ensuring your application's performance is critical—but it's not easy. This is where Underflow comes in. It automates the process of evaluating your tech stack and provides data-driven recommendations for cost-effective services and infrastructure. By analyzing your codebase and optimizing for traffic, Underflow helps you save money while maintaining the same performance and scaling capabilities.

## What it does

Underflow is a **command-line tool** that helps developers optimize their tech stack by analyzing the codebase and identifying opportunities to reduce costs while maintaining performance. With a single command, developers can input a **GitHub repository** and the number of monthly active users, and Underflow generates a detailed report comparing the current tech stack with an optimized version. The report highlights potential cost savings, performance improvements, and suggests more efficient external services. The tool also provides a clear breakdown of why certain services were recommended, making it easier for developers to make informed decisions about their infrastructure.

## How we built it

![Blank board (6)](https://github.com/user-attachments/assets/f94681f3-4716-465b-b155-c8f0c13e2b02)

Underflow is a command-line tool designed for optimizing software architecture and minimizing costs based on projected user traffic. It is executed with a single command and two arguments:

```
underflow <github-repository-identifier> <monthly-active-users>

```

Upon execution, Underflow leverages the **OpenAI API** to analyze the provided codebase, identifying key third-party services integrated into the project. The extracted service list and the number of monthly active users are then sent to a **FastAPI backend** for further processing.

The backend queries an **AWS RDS**-hosted **MySQL** database, which contains a comprehensive inventory of external service providers, including cloud infrastructure, CI/CD platforms, container orchestration tools, distributed computing services, and more. The database stores detailed information such as pricing tiers, traffic limits, service categories, and performance characteristics. The backend uses this data to identify alternative services that provide equivalent functionality at a lower cost while supporting the required user traffic.

The results of this optimization process are cached, and a comparison report is generated using the OpenAI API. This report highlights the cost and performance differences between the original tech stack and the proposed optimized stack, along with a rationale for selecting the new services.

Finally, Underflow launches a GUI build with **Next.js** that presents a detailed analytics report comparing the original and optimized tech stacks. The report provides key insights into cost savings, performance improvements, and the reasoning behind service provider selections.

This technical solution offers developers a streamlined way to evaluate and optimize their tech stacks based on real-world cost and performance considerations.

## Accomplishments that we're proud of

We’re proud of creating a tool that simplifies the complex task of optimizing tech stacks while reducing costs for developers. Successfully integrating multiple components, such as the OpenAI API for codebase analysis, a FastAPI backend for processing, and an AWS-hosted MySQL database for querying external services, was a significant achievement. Additionally, building a user-friendly command-line interface that provides clear, data-driven reports about tech stack performance and cost optimization is something we're excited about. We also managed to create a streamlined workflow that allows developers to assess cost-saving opportunities without needing deep knowledge of infrastructure or services.

## What's next for Underflow

* Generating a better database containing more comprehensive list of available external services and dependencies
* Migrate traffic determination from user manual input to be based on server-level architecture, such as using elastic search on server logs to determine the true amount of third party service usages
## Inspiration

During my last internship, I worked on an aging product with numerous security vulnerabilities, but identifying and fixing these issues was a major challenge. One of my key projects was to implement CodeQL scanning to better locate vulnerabilities. While setting up CodeQL wasn't overly complex, it became repetitive as I had to manually configure it for every repository, identifying languages and creating YAML files. Fixing the issues proved even more difficult as many of the vulnerabilities were obscure, requiring extensive research and troubleshooting. With that experience in mind, I wanted to create a tool that could automate this process, making code security more accessible and ultimately improving internet safety

## What it does

AutoLock automates the security of your GitHub repositories. First, you select a repository and hit install, which triggers a pull request with a GitHub Actions configuration to scan for vulnerabilities and perform AI-driven analysis. Next, you select which vulnerabilities to fix, and AutoLock opens another pull request with the necessary code modifications to address the issues.

## How I built it

I built AutoLock using Svelte for the frontend and Go for the backend. The backend leverages the Gin framework and Gorm ORM for smooth API interactions, while the frontend is powered by Svelte and styled using Flowbite.

## Challenges we ran into

One of the biggest challenges was navigating GitHub's app permissions. Understanding which permissions were needed and ensuring the app was correctly installed for both the user and their repositories took some time. Initially, I struggled to figure out why I couldn't access the repos even with the right permissions.

## Accomplishments that we're proud of

I'm incredibly proud of the scope of this project, especially since I developed it solo. The user interface is one of the best I've ever created—responsive, modern, and dynamic—all of which were challenges for me in the past. I'm also proud of the growth I experienced working with Go, as I had very little experience with it when I started.

## What we learned

While the unstable CalHacks WiFi made deployment tricky (basically impossible, terraform kept failing due to network issues 😅), I gained valuable knowledge about working with frontend component libraries, Go's Gin framework, and Gorm ORM. I also learned a lot about integrating with third-party services and navigating the complexities of their APIs.

## What's next for AutoLock

I see huge potential for AutoLock as a startup. There's a growing need for automated code security tools, and I believe AutoLock's ability to simplify the process could make it highly successful and beneficial for developers across the web.
## Inspiration

Have you ever wanted to search something, but aren't connected to the internet? Data plans too expensive, but you really need to figure something out online quick? Us too, and that's why we created an application that allows you to search the internet without being connected.

## What it does

Text your search queries to (705) 710-3709, and the application will text back the results of your query.

Not happy with the first result? Specify a result using the `--result [number]` flag.

Want to save the URL to view your result when you are connected to the internet? Send your query with `--url` to get the url of your result.

Send `--help` to see a list of all the commands.

## How we built it

Built on a **Nodejs** backend, we leverage **Twilio** to send and receive text messages. When receiving a text message, we send this information using **RapidAPI**'s **Bing Search API**.

Our backend is **dockerized** and deployed continuously using **GitHub Actions** onto a **Google Cloud Run** server. Additionally, we make use of **Google Cloud's Secret Manager** to not expose our API Keys to the public.

Internally, we use a domain registered with **domain.com** to point our text messages to our server.

## Challenges we ran into

Our team is very inexperienced with Google Cloud, Docker and GitHub Actions so it was a challenge needing to deploy our app to the internet. We recognized that without deploying, we would could not allow anybody to demo our application.

* There was a lot of configuration with permissions, and service accounts that had a learning curve. Accessing our secrets from our backend, and ensuring that the backend is authenticated to access the secrets was a huge challenge.

We also have varying levels of skill with JavaScript. It was a challenge trying to understand each other's code and collaborating efficiently to get this done.

## Accomplishments that we're proud of

We honestly think that this is a really cool application. It's very practical, and we can't find any solutions like this that exist right now. There was not a moment where we dreaded working on this project.

This is the most well planned project that we've all made for a hackathon. We were always aware how our individual tasks contribute to the to project as a whole. When we felt that we were making an important part of the code, we would pair program together which accelerated our understanding.

Continuously deploying is awesome! Not having to click buttons to deploy our app was really cool, and it really made our testing in production a lot easier. It also reduced a lot of potential user errors when deploying.

## What we learned

Planning is very important in the early stages of a project. We could not have collaborated so well together, and separated the modules that we were coding the way we did without planning.

Hackathons are much more enjoyable when you get a full night sleep :D.

## What's next for NoData

In the future, we would love to use AI to better suit the search results of the client. Some search results have a very large scope right now.

We would also like to have more time to write some tests and have better error handling.