Giacomo Balli profile picture
Giacomo Balli
Build to Prod

For software you or your team built with AI:
is it ready for the people about to depend on it?

Tell Me What You Built LinkedIn

Building technology products since 2010 · 100+ apps

An inspection for software built with AI

You or your team built something with AI, and it works. Before colleagues, customers or money depend on it, I inspect it and tell you in plain English what could go wrong and what to fix first. $1,499, report within five business days.

Claude Code, Cursor, Lovable and Replit made it possible to build real software without a development team, and a lot of what gets built this way is good. The worry tends to arrive later, right before you hand it to someone else: a colleague, a customer, the whole office. Can one user see another user’s data? What happens to the bill if it gets used a thousand times a day? Is there a backup, and does it actually restore? Who can still get in after the person who built it leaves?

Build to Prod answers those questions for your app, before people depend on it.

You work with me, start to finish

Not an agency, and not a team your app gets handed around. I do the inspection, I write the report, and I am the person you call when something in it is unclear or when the app changes and you want to know whether a finding still applies. By the end I know your app, what it is for and what is riding on it, so you never have to explain it twice.

I have been building and shipping software since 2010, more than 100 apps, and I have kept my own running through years of updates. I know what tends to break after launch, when nobody is watching.

What I check

The checks are chosen for your app, from what it does and what it touches. A scheduling tool for twelve staff and a customer portal that takes payments do not fail the same way, so they do not get the same checklist.

  • Who can see what. Whether one user, or one customer, can reach records that belong to someone else.
  • Keys and logins. Passwords, API keys and tokens left where they can be found, and accounts that should have been closed.
  • The business rules. Whether someone can approve their own expense, edit an order after it was approved, or skip a step the process depends on.
  • The bill. What stops AI or API usage from running away, and whether your spending limit actually stops anything or only sends an email.
  • Bad days. What happens when the payment provider, the database or the AI service is slow or down, and whether a double click charges a customer twice.
  • Backups. Whether they exist, and whether they restore.
  • Who owns it. Whether the company, not one person, controls the code, the hosting, the domain and the logins.

I use professional scanners and AI tools where they save time, and I verify every important finding myself before it goes in the report. With your permission I test the running app as well as the code, because the code alone cannot tell you how the live system is set up.

Hardening, not rebuilding

Very little of what I see needs to be thrown away. Most AI-built apps need tightening: a key moved out of the code, a check on who can open a record, a hard cap on a bill. The report says what to keep as it is, what to harden, and, in the rare case it is warranted, what to replace and why.

What you get

Within 48 hoursA call. I learn how the business uses the app, who depends on it and what a bad day would cost, and you can ask me anything.

Within five business daysThe report. A plain-English summary of where the app stands and what should hold up a launch, then each finding with its evidence, what it could mean for the business, and the fix.

Fix instructions you can useWritten precisely enough to paste into Claude Code or Cursor, or to hand to a developer, each with a test that shows the fix worked.

A walkthroughWe go through the report together until every finding makes sense to you.

One retestWhen the fixes are in, I check them again.

$1,499, fixed. No hourly meter, no surprise invoice.

Credited in full to an engagement you start within 30 days, if the report raises a bigger decision you want help with. There is no obligation to start one.

The standards behind the checks

What I check draws on the standards application security professionals use:

  • OWASP Application Security Verification Standard (ASVS)
  • OWASP Top 10
  • OWASP API Security Top 10
  • OWASP Top 10 for LLM Applications, when the app uses AI
  • OWASP Mobile Application Security (MASVS), for iPhone and Android apps
  • NIST Secure Software Development Framework (SSDF, SP 800-218)

These standards shape the inspection. It is not a certification, a formal penetration test or a compliance opinion, and it does not replace one when a contract or a regulator requires it. For an attacker’s view of an established production system, see the Production Security Assessment.

Start with a message

A couple of lines is enough: what you built, who uses it, and what worries you. I read every message myself and reply within a day.

Tell me what you built

Please do not send passwords or keys. If I need access, we agree how first.

Frequently asked questions

Can’t I just ask Claude to check it?
You should, and I use it too. Claude is a very good coder. It still makes mistakes, skips checks nobody asked for, and reports both with the same confidence as everything else. It cannot see the business around the code: which data would hurt to lose, which rule your accountant relies on, what has to be fixed now and what can wait. And it builds eagerly. Two weeks of asking for one more feature leaves you with a stack of pancakes, each layer piled on the last, instead of a plate where everything has its place. Telling those apart takes someone who has shipped and maintained software for years.
Who will I actually work with?
Me. I do the call, the inspection, the report, the walkthrough and the retest. There is no account manager and no team your app gets passed around. When you call with a question, you reach the person who read your code.
Does it have to be built with AI?
No. An app a freelancer or an agency built for you gets the same inspection, and the best time for it is before you accept the delivery.
It is only an internal tool. Does this apply?
Often more than to a public app. A tool your staff built that touches payroll, accounting or customer records can do more damage than a website, and it usually gets less attention.
What access do you need?
Usually read access to the code and a call. For a live app I may ask for a test account or a copy to test against. I do not need production passwords by default, and I tell you exactly what I need before anything is shared. Please do not send passwords or keys through the contact form.
Will you tell me the app is safe?
I will tell you what I checked, what I found and what I could not verify. No honest inspection can promise that an app is safe, so mine does not.