I should start with a disclosure: I did not write this blog post. Claude did. Which is fitting, because Claude also wrote the app this blog post is about, the deploy script that shipped it, the technical documentation that explains it, the deployment skill that prevents future mistakes, and the Linear project that tracks the roadmap. Claude even filed the tickets. With due dates.
I am telling you this upfront because it is the entire point of what follows.
The Problem I Carried Around for Years
Third-party risk management has been a pain point at every company I have worked at. The question is always the same: when someone buys a new tool, how does the security team know about it, and how do they decide whether it needs a review? The answer, historically, has been some combination of Slack messages, shared spreadsheets, and hoping someone remembers to loop in the right people. It works until it does not, and it stops working quietly.
At Handshake, this problem got measurably worse when we migrated to Ramp for procurement. Ramp is a fine tool for what it is built to do. What it is not built to do is make security, privacy, and legal reviews painless. The platform consolidates everything into a single workflow with a UI that can generously be described as dense. Every spend request funnels through the same pipeline regardless of whether it requires a security review, a legal review, both, or neither. The result is noise. An extraordinary amount of noise.
For the people responsible for conducting due diligence (security, privacy, legal), the experience is a wall of requests where the ones that actually matter are buried alongside office supply orders and conference sponsorships. The filtering is limited. The notification logic is aggressive. Every request generates alerts, mentions, and follow-ups that train people to stop paying attention. When everything is urgent, nothing is.
For everyone else in the organization (the people buying tools, submitting requests, waiting for approvals), the experience is equally frustrating. They are forced through a review process that feels opaque and slow, peppered with nudges in Ramp and follow-up messages in Slack. The procurement workflow generates so much ambient noise that people go numb to it. Mentions in Ramp become background static. Slack nudges become another thread to ignore. The system designed to ensure oversight instead ensures fatigue.
I had been thinking about a better approach for months. A tool that pulls spend requests from Ramp automatically, separates the signal from the noise by scoring each vendor against the criteria the security team actually cares about, routes the qualifying ones into Linear for structured review, and gives the team a dashboard showing the full picture. I knew exactly what this should look like. I also knew, with complete certainty, that I was never going to build it.
I run a GRC program. I do not write production software. I have never shipped an application. The gap between "I know precisely what this should do" and "I can make it do that" felt permanent.
Six Days
On a Friday, I opened Claude Code and described the problem the way I would explain it to a colleague over coffee. Here is what we deal with, here is how the workflow should go, here are the systems involved. No product requirements document. No technical specification. Just a conversation.
By the end of that session, I had a working backend. A FastAPI service that could pull spend requests from the Ramp API, deduplicate vendors by name, and score them against two intake questions: does this vendor access customer data, and does it integrate into our infrastructure.
Over the weekend and into the following week, the rest came together at a pace I still find slightly absurd.
Claude built the full React frontend: a dashboard with stats cards, a filterable and sortable vendor table, detail pages with spend history and review timelines, and an admin page for triggering syncs and exports. It built the Linear integration so qualifying vendors get issues created automatically, assigned to me, with the right labels. It built the decision sync that pulls completed assessments back from Linear. It added Slack notifications. It added CSV export for bulk triage. It built the Docker configuration, the deploy script, and packaged everything for Google Cloud Run.
By Thursday, the app was live in production behind Google's Identity-Aware Proxy, accessible only to Handshake employees, with daily automated syncs and role-based access separating admins from viewers.
One week. From "I have an idea" to "it is running in production and syncing every morning."
What I Actually Did
I want to be honest about the division of labor here, because the takeaway should not be "AI magically built an app."
I brought the domain knowledge. I knew which Ramp fields mattered for risk scoring. I knew how our team triages vendors in Linear, what a security review workflow should look like, which roles needed which access levels, and how the tool should fit into processes we already run. Every architectural decision was mine: use SQLite on a mounted storage volume instead of a managed database, keep it as a single container behind IAP, use Linear labels for decision tracking rather than building a separate review engine. Those choices came from years of understanding the problem space and the team that would use the tool.
Claude wrote the code. All of it. The Python backend, the React frontend, the SQL schema, the API endpoints, the Docker configuration, the deploy scripts. When something broke (and things broke plenty; I do not have half the GCP permissions I thought I did), I described the error and Claude fixed it. When I wanted a feature to work differently, I described the change in plain language and it happened. When we hit a permissions wall, Claude drafted the exact commands a GCP admin would need to run and I forwarded them to our infrastructure team in Slack.
The dynamic was closer to working with a very fast, very capable engineer who needed direction but never needed to be told anything twice. I was the product owner, the architect, and the QA team. Claude was the entire engineering department.
The Part That Surprised Me
The app was only the beginning of what came out of this process.
While building, Claude also wrote the full technical overview documenting the architecture, data model, and deployment process. It created a post-MVP roadmap capturing every improvement we discussed: SOC 2 report analysis, pentest report parsing, auditor peer review verification, web intelligence, writing decisions back to Ramp. It wrote a deployment skill for my specific GCP setup, a reference document that captures my exact permissions so that future sessions never suggest commands I cannot run. (This alone has saved me hours of 403 errors.)
After the build, I asked Claude to create a project in Linear under our GRC team and populate it with issues reflecting everything we had built and everything still planned. It looked at an existing project I pointed to for structure, created the project with the correct initiative mapping and target dates, and filed 18 issues with accurate statuses. Completed work marked done. Infrastructure items waiting on admins marked in progress. Nine post-MVP features spread across the quarter with due dates. Each issue had a detailed description pulled from the context of our actual build conversations.
And then I asked it to write this blog post. Which it did. Because at this point, why wouldn't it.
Who This Is For
If you are a security professional, a compliance lead, a risk manager, an operations person, or anyone in a role where you know exactly what tool your team needs but have never had the engineering bandwidth to build it: this is for you.
The bottleneck was never about ideas. Security teams, GRC teams, IT teams; we all carry around a backlog of tools we wish existed. The bottleneck was the ability to turn requirements into working software. We sit in a queue behind product engineering, waiting for bandwidth that rarely comes. The tools we need are too niche to justify pulling engineers off revenue work, and too complex to solve with spreadsheets and Slack workflows forever.
That bottleneck is gone now. Not reduced. Gone.
I went from never having built an application to running one in production in less than a week. The TPRM tool processes every new vendor coming through Ramp, scores it automatically, routes it to Linear for review, notifies the team via Slack, and gives us a dashboard to see the full vendor risk picture. Nine more features are on the roadmap through Q3, and I will build every one of them the same way.
Get in Touch
If you are interested in how this works, how to get started, or how to go from "I have an idea" to "it is running in production" without writing a line of code yourself, reach out. I am deeply interested in this space and committed to showing that the barrier between knowing what to build and being able to build it has fundamentally changed. You can do more now with less. The only prerequisite is knowing your problem well enough to describe it.
What was once a dream is now a reality. And to no one's surprise, the thing that turned it into reality also wrote the blog post you just read.