How to Safely Get Started with AI Coding

Owning the software your business runs on used to take an engineering team. Everyone else rented. You bought a platform that almost fit, used a tenth of its features, paid for all of them, and filled the gaps with spreadsheets nobody fully trusted.

That status quo has changed, and it is worth being clear about why.

Before, the barrier was money, talent, and most importantly, understanding. Knowing your own operation well enough to turn it into a system. Hiring a developer was how you rented that understanding. AI coding does not remove it. It just moves it onto your desk, where it probably belonged anyway.

That is the real opportunity, and it is bigger than cheaper software. The person who actually knows the work can now build the tool that fits it. Not a developer interpreting a requirements doc. Not a vendor guessing at your industry. You, in plain English.

And it is cheaper than people expect. An AI coding tool (Claude Code or Cursor, or browser builders like Lovable, Bolt, or Replit if you have never opened a terminal), a hosted database (Supabase or Neon), and somewhere to put it online (Netlify or Vercel). Most of it is free to start. A real, in-use internal tool runs around thirty-five dollars a month, against per-seat SaaS pricing across a whole team.

But here is the part the excitement skips. The thing that made software hard did not disappear when the coding got easy. It relocated. Building your own tool is no longer a question of whether you can. It is a question of whether you understand what you are building well enough to not hurt yourself. And that question has levels.

There are levels to this

Not every build carries the same risk. Matching your ambition to your understanding is the first real decision you make, and the first place people overreach.

Level one: replace a spreadsheet. A small shop wants scheduling, or inventory, or a client list out of Excel and into something real. This is where DIY AI coding shines. The data is simple, the stakes are low, and the worst case is going back to the spreadsheet you started with. You barely need to understand databases to do this well. Start here. Almost everyone should.

Level two: consolidate years of data living across many spreadsheets. Now you are pulling financial history, or an entire client base, out of a dozen files that disagree with each other. You can still do this yourself. But the difficulty just jumped, and not because the AI got worse. Because the data got harder. You now need to actually understand how a database works: how records relate, what keeps data consistent, what happens when you change the structure later. The AI will happily build you something that looks correct and quietly corrupts your numbers if you do not understand the model underneath. At this level, slow down.

Level three: anything customers touch, anything regulated, anything moving money. This is where "you can probably DIY it" stops being good advice. This is the foundation-first territory I have written about before. Build the simpler levels first, get fluent, and bring in help before you put something fragile in front of the people who pay you. I have built at this tier, a HIPAA-compliant operations platform for a multi-site physician group, and the controls it runs on (role-based access, audit logging, retention policies) are exactly where a solo build quietly breaks. Not because the tools fail, but because at this level the gap between "it works" and "it is safe" is the whole job.

It is all about data flow

Here is the part most people skip, and it's really the most crucial part.

Whatever you build comes down to the same five parts: the screens people use, the logic that moves information, the place it is stored, the rules for who can touch it, and the spot it all runs. None of them are really about code. They are about data: how it gets in, how it moves, where it lives, who can touch it, and how you keep from losing it. Those are the five questions, every time.

And here is why you cannot wave them off. The AI will build all five whether or not you understand them. If you cannot read what it made, you cannot tell working from safe, and you have handed your operation to a system you have no way to judge. Understanding these is not about becoming a developer. It is about staying able to direct the thing instead of being directed by it. Here is each one, in plain terms.

The front end is what people see. The screens, the forms, the buttons. The one thing to understand: looking finished is not the same as working. The front end cannot be trusted to enforce your rules, because anything that only lives in the screen can be gotten around, by a determined user or just a bug. That is why the real rules have to live behind it.

The back end is the rules and the plumbing. This is where your operation's logic lives: a job cannot be marked paid with no price, an email cannot be blank, a discount over a set amount needs a manager. Developers call that business logic and validation. It is also where the screen talks to the data, through what is called an API, the contract for reading and writing a record. The rule to remember: if something is not enforced here, it is not enforced. "The screen would not let me" is not a control.

The database is where your data actually lives. This is the part that separates level one from level two, so give it the most attention. Data lives in tables, like the tabs of a spreadsheet, made of records (the rows) and fields (the columns). Each field has a type: a price is a number, a date is a date, a status is one of a fixed set, not free text someone can fat-finger. The shape of all of it is your schema, your data model. The thing spreadsheets never gave you is relationships: one customer has many jobs, and instead of retyping the customer into every job, you link each job to the customer by an id. One source of truth, referenced everywhere, changed in one place. And because your needs change, you will eventually alter that structure, which is called a migration, and doing it without scrambling the data you already have is exactly the skill level two asks for. Get this right and your numbers stay trustworthy. Get it wrong and the tool quietly rots from the inside.

Authentication and security is who can touch what. Two ideas people collapse into one. Authentication is proving who you are, the login. Authorization is what you are allowed to do once you are in: roles and permissions, and what is called row-level security, so a sales rep sees only their own clients and not the whole book. Separate from both are your secrets, the API keys that are effectively the keys to your data, which must never sit in the front end or in code anyone can read. Most real breaches are not a picked lock. They are a missing permission check, a door nobody thought to lock because the login made everything feel safe.

Hosting and environments is where it runs and how you do not lose it. The app runs somewhere, and you want at least two copies: production, the live one your team uses, and a separate staging copy where you try things and break them. You never edit production directly. Under that sits version control, called git, a complete history of every change with an undo, so a bad edit is a rollback instead of a catastrophe. Your secrets live in environment variables, kept out of the code itself. And backups are the floor under all of it. The safety net is not any one of these. It is all of them together, and it is what lets you move fast without betting the business.

That is the same thing I wrote about last time. Most companies want AI, which is intelligence sitting on top of their data, without having answered a single one of those questions about the data underneath. Building your own tool, even a small one, forces you to answer them. That is not the hard part of this. That is the point of it. And you come out understanding your own operation better than the vendor ever did.

Build your first application

None of that is abstract. Every one of those five questions becomes a concrete decision the moment you build, and building forces you to make them in the open. Here is the actual path, using a customer and job tracker as the example, the thing that replaces the client spreadsheet most small operations run on.

Start with the data, on paper. Before you open a single tool, write down what you are tracking. Customers: name, phone, email, status. Jobs: which customer, date, what you did, price, paid or not. That is your data model, and deciding it now, in plain language, is the single most important step. It is the database part, done before any code exists. Everything downstream is easier when this is clear and harder when it is not.

First, get something real working

1. Pick a browser builder. Lovable, Bolt, or Replit. No terminal, no setup. You describe what you want in plain English and it builds the screens, the logic, and a starter database, then shows you a working preview.

2. Describe the app. Paste in your data model and say what you want: "A web app to track my customers and the jobs I do for them. A list I can search, and a form to add and edit." It generates the front end (the screens and forms) and the back end (what happens when you hit save). Read what it built. Then change it by describing the change, not by writing code.

3. Use it with fake data. Add a few made-up customers and jobs. Click everything. Does it match what you pictured? This is your sandbox. Nothing here is real, so there is nothing to break. For a lot of small shops, this is the whole journey. You have replaced the spreadsheet. Level one, done.

Then graduate to a stack you own

You outgrow the builder the moment a second person needs in, or the data starts to matter, or you want to truly own the thing and control what it costs. That is level two, where the five parts stop hiding inside one box.

4. Move the code into your own hands. The builders let you export the project or push it to GitHub. Open it in Claude Code or Cursor, AI coding tools that work directly in your own copy of the project. You are still directing in plain English. You just have real control now, and you are still working on a copy that touches nothing real.

5. Stand up a real database. Supabase or Neon, both free to start. This is where your data will actually live, instead of inside a builder you do not control. Before you put in a single real record, make sure backups are on. On Neon that comes built in; on Supabase it means the paid plan. Either way, set it up before the data goes in, not after.

6. Add a login. The moment more than one person uses it, or it holds anything you would not post publicly, it needs authentication. Supabase has this built in; tell the agent to put the whole app behind it. Decide who sees what. Even a tool only you use should sit behind a login, not open on the internet for anyone who finds the link.

7. Put it online, with two copies. Deploy to Netlify or Vercel. Keep two versions running: the live one your team uses, and a separate copy where you try things and break them. Never edit the live one directly. This is the habit that prevents almost every beginner disaster. With a real database and host in play, you are now in that thirty-five dollars a month range.

8. Verify, then move the real data. Before anything real goes in, try to break it. Leave a required field blank. Enter the same customer twice. Put a letter where a price should go. Watch what it does. Only when it holds up do you bring the real data over, one record first to confirm it landed right, then the rest. Keep the old spreadsheet untouched for a while. It is your backup until you trust the new thing.

You stay the operator

Look back at what that took. Almost none of it was code. It was a string of decisions about your data, the same decisions your old software made for you, silently, and usually wrong. That is the real return on building it yourself. Not the thirty-five dollars. You end up understanding your own operation in a way renting never required.

The walkthrough had three rules running underneath it, and they are the whole discipline: start on something low-stakes you cannot wreck, verify the result yourself instead of trusting that it "seems to work," and ship in tiers so each step earns the next. None of it required you to become a developer. It required you to stay the operator, the person who owns the call on what is good enough to trust.

AI coding does not replace understanding your business. It lowers the cost of acting on what you understand. The winners will not be whoever builds the most software. They will be whoever understands the work well enough to build the right thing. The spreadsheets were never the problem. They were a placeholder for a system you could not afford to build. You can afford it now. The question is whether you are ready to build it well.

The tools, by level

You have already done the hard part above: the five questions, answered honestly. The tools are the easy part. Match them to the level.

Level one: replace a spreadsheet. A browser builder that does everything in one place: Lovable, Bolt, or Replit. Screens, logic, a starter database, and one-click hosting, all from plain-English description. No terminal. Free to a few dollars a month.

Level two: consolidate and go multi-user. The assembled stack you own: Claude Code or Cursor to build, Supabase or Neon for the database on a plan with backups, Supabase Auth for logins, GitHub to keep a safe copy separate from the live one, and Netlify or Vercel to host. Around thirty-five dollars a month.

Level three: customer-facing, regulated, or money. Everything in level two, hardened: role-based access, audit logging, and data-retention controls; Stripe for anything involving payments, because you never build money movement yourself; error monitoring and a separate staging copy; and a developer or partner to review the architecture and security before launch. This is the level you do not solo.

Start at level one. Build something small you actually own, and let it earn its way up. Schedule a call when you are ready to install something durable.