We make AI-built apps safe to launch
uBuilt is a production engineering practice. Founders bring us apps built with Lovable, Replit, Base44, Bubble, or Claude Code, apps that already work, and we do the part the builder does not: security, data, performance, infrastructure, and the operational work that keeps it standing once real users arrive.
How the work is structured
- 1
Production Check
Free consultation + scoped audit
- 2
Production Ready
Fixed-scope project, quoted after the audit
- 3
Cloud Independence
Scoped per stack and data volume
- 4
Managed App
Per month, no long-term contract
Shipping a v1 got easy. Surviving real users did not.
Building a working first version used to take a small team a quarter. Now one person does it in a weekend, and the result is not a toy. That part of software genuinely changed.
What did not change is everything on the other side of the demo. A policy that returns your rows still has to return nothing to someone guessing another account’s id. A query that runs in four milliseconds against two hundred rows still has to run against two million. These are not AI problems. The builders just moved them from month six to the end of week one.
What changed is who is standing in front of them. It used to be a team with an engineer who had been paged at 3am. Now it is a founder with an app that works and a launch date.
Nobody we work with is careless. They are holding a set of unknowns with no way to rank them. The failure mode is not ignorance. It is three weeks spent on the wrong risk while the real one sits in a database policy nobody read.
So we do the ranking first. Read the code, push the app until something gives, hand back a report that separates broken from untidy from fine. The report is useful whether or not you hire us, which is the whole point of putting it first.
What a demo proves
- The idea makes sense to a human being who is not you
- The happy path works end to end, on your machine, with your account
- You can sign up, log in, and see your own data
- It deploys, and the URL loads
What production asks next
- What comes back when somebody puts another user’s id in the URL
- What that query does at two million rows instead of two hundred
- Where the uploads and the SQLite file go when the container restarts
- Who gets paged when a dependency ships a critical advisory on a Saturday
- What the bill looks like at ten times the traffic
- How you get yesterday’s data back, and whether anyone has ever tried
Six positions we don’t move on
None of these are unusual. They are just easier to write down than to hold to in the week a project runs long.
We measure before we recommend
Every recommendation arrives with a number attached: a query plan, a p95, a bundle size, a projected bill.
We don’t rewrite what works
A rewrite trades a known set of bugs for an unknown one and costs you a quarter of roadmap.
You own everything we build
Code lands in your repository. Infrastructure runs in your cloud accounts, on your billing.
Fixed scope after the audit
The audit exists so the quote can be a number instead of a range.
We work with your developers, not around them
Most engagements sit alongside a founder still shipping features in the builder, or a small team that owns the product code.
We tell you when you don’t need us
A real share of our audits end in “this is fine, launch it” or “fix these two things yourself, here is exactly how.” We would rather lose the project and be the people you call at ten thousand users than sell a hardening engagement nobody needed.
What we’re good at
Nine areas, in roughly the order they break an app that was built fast.
Security & access control
- Row-level security policies tested per role, not read per file
- Service-role and third-party keys moved server-side, then rotated
- Authorization enforced at the data layer, not only in the UI
- IDOR, injection, and file-upload surfaces reviewed by hand
Data & databases
- Schema and index decisions taken from real query plans
- Point-in-time recovery enabled, then a restore actually rehearsed
- Reversible migrations, reviewed, never run from a laptop
- Connection pooling sized to the workload instead of the default
Performance
- p95 traced end to end rather than judged from one page load
- N+1 queries and unbounded table scans found and removed
- Bundle weight, image payloads, cold starts, and render blocking
- Caching where it measurably helps, and nowhere else
Infrastructure
- Environments sized to real traffic on AWS, GCP, Vercel, or Fly
- Development, staging, and production separated down to the data
- Secrets in a managed store, scoped per environment, rotatable
- Networking, TLS, CDN, and custom-domain cutovers
CI/CD & release safety
- Deploys from git, with a preview environment per pull request
- One-command rollback that somebody here has actually practised
- Types, tests, dependency advisories, and secret scanning in the pipeline
- Database migrations that run as part of the deploy, gated and reversible
Testing where it counts
- Tests around the invariants: authorization, money, and data integrity
- A regression test written the day an incident happens
- Load tests shaped like your traffic, not a synthetic benchmark
- Seed data and fixtures so nothing has to be verified against production
Observability
- Error tracking with releases and source maps wired up properly
- Structured logs you can query, with a request id that crosses services
- Uptime and synthetic checks on the paths that make money
- Alerts that reach a person, at thresholds that do not cry wolf
Cost
- A cost-per-user model for the stack you have today
- Builder and per-seat pricing compared against infrastructure you own
- Egress, function invocations, and database compute broken out separately
- The projection at 10x and 100x, so the surprise happens on a spreadsheet
Handover
- Architecture notes that describe what is deployed, not what was planned
- Runbooks for deploy, rollback, restore, and incident response
- Infrastructure as code, so the environment can be rebuilt from scratch
- A walkthrough call with whoever will operate it after we leave
The stack we work in
We pick tools for your traffic shape, your budget, and whoever has to operate them at 3am. Not because of a partnership.
- Builder platforms
- LovableReplitBase44BubbleClaude CodeBoltv0Cursor
- Languages & frameworks
- TypeScriptReactNext.jsNode.jsExpressPythonFastAPIGo
- Data
- PostgreSQLSupabaseNeonPrismaDrizzleRedisPgBouncerS3
- Cloud
- AWSGCPVercelFly.ioCloudflareRailwayRenderHetzner
- Build & deploy
- DockerTerraformGitHub ActionsKubernetesNginxCaddy
- Observability
- SentryGrafanaPrometheusOpenTelemetryLokiBetter Stack
- Security & secrets
- SemgrepTrivyDependabotDopplerAWS Secrets ManagerCloudflare WAF
Something not on the list is rarely a problem. If it runs on a server we can read, we can operate it, and if we cannot, that is the first thing we will tell you.
What we will not do
A short list, and we hold it in the weeks when holding it costs us the project.
We will not sell you a rewrite you don’t need
The most profitable thing an agency can do with an AI-built app is call it unsalvageable and quote a rebuild.
We will not lock you into our hosting
Your infrastructure runs in accounts you own, billed to your card, with your team on the root credentials.
We will not take a project we can’t land
If the work sits in a domain we cannot responsibly operate: regulated clinical data, payment infrastructure we have no track record in, a stack nobody here has run under real load.
We will not report a finding we can’t demonstrate
Every critical and high finding in an audit comes with a reproduction: the request, the response, the query plan, the line number.
The person doing the work
uBuilt is small on purpose. You talk to the engineer who reads your code, not an account manager who forwards it.
Kato Chojiro
Full Stack Engineer
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Want to know what is actually wrong?
The Production Check is free, and the report is yours whether or not you hire us.