PB

Keep Your App's Infrastructure Organized When Building With AI

By PB ·

Building an app with an artificial intelligence assistant is productive. It can generate code, configure forms, and connect online services.

Yet behind code sits your infrastructure, the underlying services, servers, databases, and networks keeping an application running online. When an assistant moves fast, it directs you to register accounts and adjust settings without records. Weeks later, you wonder where files live, who owns your domain, and where customer data is saved.

I manage this complexity through simple records. I keep one record per app listing where code lives, who can approve a release, and its status. Its header warns that status fields are planning notes until I check the live site. By building an infrastructure map, setting an AI working agreement, and running a verified change routine, you can build fast without losing control.

Four habits that keep an AI-built app organized: 1. Map Components: Record hosting, domains, database, and owners. 2. Protect Secrets: Store key names and locations, never values. 3. Set AI Rules: Provide explicit working rules in your repo. 4. Run Change Routine: Check before, change once, read back, record. Figure 1: Four habits that keep an AI-built app organized: map components, protect secrets, set AI rules, and run a safe change routine.

Before You Start

Gather three prerequisites before organizing infrastructure:

Why Infrastructure Gets Lost When AI Builds Fast

By default, an AI assistant knows only the files and messages you give it. Connected tools can let it read outside accounts, bills, inboxes, or hosting dashboards, depending on their permissions. Still, it has no record of accounts you created elsewhere unless you give it one.

This causes three common problems:

To maintain clarity, keep a central record outside the conversation.

The One-Page Infrastructure Map

An infrastructure map is a plain-text document in your project folder tracking six foundational parts:

For each component, record five facts: service name, purpose, account owner, operational status, and renewal or billing details. If an owner or renewal date is unconfirmed, write "Unknown" explicitly. Marking an item as Unknown highlights an immediate operational task; guessing creates false confidence.

Keeping Secret Keys Safe

Connecting outside services requires credentials called API keys (Application Programming Interface keys). Some appear in browser code (publishable keys), while others carry administrative power (secret keys). Treat any key marked secret like a password.

Handle credentials with care:

An AI Working Agreement

AI assistants do not inherently understand operational safety. In my repositories, I keep a working agreement file named AGENTS.md. Here is a starter version for a small app:

# AI Assistant Working Agreement

1. Scope rule: Edit only assigned files.
2. One writer per file: If another writer is editing a file, do not edit it.
3. Secret protection: Never request or display secret keys; reference by name.
4. Configuration safety: Do not alter deployment scripts or settings without approval.
5. Transparent actions: Explain proposed commands before running them.
6. Stop and report: If a step or check fails, stop and report the exact error.

My guide on verifying AI coding agents shows how to give an assistant checks that prove its work. A working agreement sets expectations; checks confirm the result.

The Safe Change Routine: Before, Change, After, Record

When updating an application, follow this four-part routine:

  1. Check Before: Confirm the live site is healthy. Verify there are no uncommitted changes (edits not yet saved into version control history), note the current version tag (a label such as v1.4.0 that marks a saved release), and prepare a rollback plan to revert the site if problems occur.
  2. Make One Bounded Change: Apply a single adjustment at a time. To deploy means sending files to your hosting server so changes become active. A build converts source files into a bundle ready for servers. Isolating edits ensures that if an error appears, you know the cause.
  3. Read Back After: Never assume deployment succeeded because a command finished cleanly. After I upload a change to this website, I read back the public page and its images; a "deployment started" message is not proof. Inspect the live feature directly.
  4. Record the Update: Update your infrastructure map immediately with the new version, date checked, and modified settings.

Honest Status Words

Clear operations require precise terms:

Tag every observation with the date checked. An observation from last month is historical context, not proof of current health.

Worked Example: Sunlight Yoga Booking

Consider Sunlight Yoga, a fictional yoga studio whose founder documented its booking app in this map:

Code Repository

Web Hosting

Studio Domain

Customer Database

Payment Gateway

The database entry marks the owner and renewal as "Unknown", highlighting a necessary task: locating credentials and securing ownership.

When enabling card checkout for a $20 drop-in class pass (fictional price), the founder ran the change routine:

  1. Check Before: Confirmed live schedule loaded, verified no unsaved edits at version tag v1.4.0, and prepared a rollback for errors: switch PAYMENT_MODE back to test and restore the previous PAYMENT_SECRET_KEY value in the hosting dashboard, then redeploy tag v1.4.0.
  2. Make One Bounded Change: Instructed the assistant to edit only the booking card file and to read the publishable key from the public variable NEXT_PUBLIC_PAYMENT_KEY, replaced the test value of PAYMENT_SECRET_KEY with the live key and switched the payment setting from test mode to live mode (PAYMENT_MODE=live) in the hosting dashboard settings (outside code), and deployed.
  3. Read Back After: Visited live schedule, completed one real booking with the founder's own card, verified confirmation screen, charge, and database record, and refunded test order.
  4. Record the Update: Updated map setting Payment Gateway to "Live and verified (2026-11-03)" at version tag v1.5.0.

Honest Limits

An infrastructure map is an administrative tool with boundaries:

Taking Your Next Step

Open a text document and list three core components: where code lives, where your site is hosted, and where your domain is registered. Note the primary owner for each, and label missing facts as Unknown.

Once those three entries are written down, you have your first infrastructure map. Add the database and outside services next.