PROJECT OVERVIEW

DETAILED ANALYSIS

AI & Software Published: 1/15/2025
AUDIT.LOG

PROJECT DETAILS

TECHNICAL SPECIFICATIONS

Why I Built This

AUDIT.LOG started the way a lot of good ideas do — from a real problem that bugged me. I co-founded this startup with Vyom S and Thomas H after we kept running into the same issue: manual code audits are slow, expensive, and they miss things. In any organization with a complex codebase and multiple contributors, bad commits slip through. Sometimes it is an accidentally committed API key. Sometimes it is a security flaw that nobody caught in review. Sometimes it is something worse.

We asked ourselves: what if you could automate that entire process and catch problems the moment they happen, not weeks later during a manual audit?

What It Does

AUDIT.LOG is a regex and AI-powered auditing platform designed for organizations, businesses, and teams. It integrates directly with GitHub and Slack, sitting in your existing workflow rather than adding another tool to check.

When a commit is pushed, AUDIT.LOG scans it automatically. The regex engine catches known patterns — API keys, credentials, secrets, common vulnerability signatures — with speed and precision. The AI auditor goes deeper, analyzing code changes for security flaws, suspicious patterns, and potential bad actors that rule-based systems would miss.

When it finds something, it does not just log it quietly. It alerts through Slack so the right people know immediately. The goal is zero delay between a problematic commit and the team’s awareness of it. In security, minutes matter.

The platform handles the full audit lifecycle: detection, classification, alerting, and reporting. Teams can review findings in a dashboard, track remediation, and see historical trends in their codebase’s security posture over time.

How We Built It

Working as a co-founded startup was a fundamentally different experience from building solo projects. With Vyom and Thomas, we had to divide responsibilities, align on architecture decisions, manage our own deadlines, and hold each other accountable. Nobody was assigning us tasks or grading our work. We had to decide what mattered and execute.

I focused on the core auditing engine and the AI analysis pipeline. The technical challenge was balancing accuracy with speed — the system needs to scan commits fast enough to provide near-instant feedback, but thorough enough to catch subtle issues that a quick regex pass would miss. We built a layered approach where fast pattern matching handles the obvious catches and the AI model handles nuanced analysis.

Impact

AUDIT.LOG is a live product with real users. That alone makes it different from most student projects. We did not build it for a class or a competition — we built it because we saw a market need and wanted to fill it. The platform is actively protecting codebases and giving teams confidence that their repositories are being monitored continuously.

The startup experience taught me things I could not have learned any other way. Product decisions, user feedback loops, infrastructure costs, reliability requirements — these are concerns that only surface when real people depend on your software. It changed how I think about building products. Every feature decision now starts with “does the user actually need this?” rather than “would this be cool to build?”

What I Learned

Co-founding a startup in high school taught me that building a product and building a project are very different things. A project can have rough edges, known bugs, and missing features. A product cannot — or at least, users will tell you about it loudly if it does.

Working with Vyom and Thomas showed me the value of complementary skills on a founding team. We each brought different strengths, and the product is better because no single person’s blind spots went unchallenged. The experience of negotiating technical tradeoffs with co-founders, rather than making every decision unilaterally, made me a more thoughtful engineer.

AUDIT.LOG is still growing, and I am proud that something I helped build is out in the world doing real work. It is one thing to win a competition with a project. It is another thing entirely to have people rely on your software every day.

PROJECT LINKS

EXTERNAL RESOURCES