Build an app with AI without coding: a founder's guide to working with a coding agent

Until recently, a founder without a technical background had three options for software: learn to code, pay a developer or agency, or bend a no-code tool until it broke. AI coding agents add a fourth. You describe the change in plain English, from your phone if you like; the agent writes the code, runs the checks, deploys it and tells you what it did. You look at the result and decide whether it goes live.

That works far better than most sceptics expect, and far worse than the marketing suggests if you treat it as magic. The difference is almost entirely in how you run the loop. This guide covers what an agent can realistically build, the loop we recommend, what it costs, where the risks are, and when you should hire a developer instead. It's the hub for our articles on building software with AI.

A real example: a founder running his own product tech

Here is how one published Fulcrum Cortex customer, the founder of a karaoke kiosk for rideshare cars, describes it:

Individual results vary. Note the shape of it: a focused product, a live pilot in one car rather than a national launch, real payments treated seriously, and a founder who keeps the decisions about anything customer-facing. That's the pattern to copy.

What an AI coding agent can build, and what to be careful with

The middle column is where most of the value is, and where review discipline matters most. The right-hand column isn't 'impossible'. It's where the cost of a mistake is high enough that you want an experienced engineer reviewing the design, not only the result.

In Cortex, this work is done by Fulcrum Code, the coding agent: it builds apps, automations, integrations and fixes, delegated from the same chat you use for everything else, then deploys and reports back.

The loop: brief, preview, review, release, rollback

Every change, from a typo fix to a new feature, goes through the same five steps. Small changes go through them in minutes. Skipping steps is how non-developers get burned.

1. Brief: describe the change, not the code

Say who it's for, what problem it solves, and how you'll know it works. A photo or screenshot is often worth a paragraph. 'On the song list on the tablet, riders can't tell which songs are explicit. Add a small E badge next to explicit songs, like the one in this photo. Done when an explicit song shows the badge and a clean one doesn't.' That's a good brief. We go through the method, with templates for features and bugs, in how to brief an AI coding agent.

2. Preview: see it before customers do

Ask for a preview or test version of every change that customers will see, and look at it on the device they'll use. A change that looks fine on a laptop can be unusable on a phone or a kiosk tablet. How previews are set up depends on where your app is hosted; agree the approach once, at the start.

3. Review: check behaviour, not code

You don't need to read code to review a change. You need to check that it does what the brief said, that it didn't break the things around it, and that the critical paths still work. Ask the agent to tell you what it changed, what it tested and what it couldn't test. Our guide to reviewing AI-built software changes covers which automated tests are worth having, a release checklist and how to treat payments and logins.

4. Release: a decision, not a side effect

Going live should be something you approve, especially for anything outward-facing. Release at a time you can watch the result, not late on a Friday. Keep a one-line record of what went out and why.

5. Rollback: know the way back before you need it

Before the first release, ask the agent: 'If this change breaks something, how do we go back to the previous version, and how long does it take?' Get the answer in writing. Changes that touch stored data, such as renaming fields or deleting records, are harder to undo than changes to screens, so they deserve a backup first.

Your job as a non-developer founder

The agent can be the engineering team. It can't be the product owner. These responsibilities stay with you:

• Direction. What gets built, in what order, and what doesn't get built at all.
• Acceptance. Deciding when a change is good enough to release.
• Customer-facing decisions. Wording, prices, what users can see and do.
• Access. Who holds the keys to hosting, domains, payment accounts and the code repository. That should be you, or your business, not a vendor or contractor.
• Risk calls. Whether to ship a fix now or wait, whether a feature needs a specialist review.

That's a few short sessions a week for a typical small product, mostly done from your phone. It is not zero, and anyone who tells you it's zero is selling something.

Start with internal tools

The safest first project is one only your team uses: an admin dashboard, a job tracker, a report that currently takes someone two hours every Monday. The users are forgiving, the data is yours, and you learn the loop without customers watching. RiideStar's admin site for managing songs and prices is exactly this kind of tool. We cover how to scope the first version, set permissions and decide when to buy instead in building internal tools with AI.

Pages that sell: landing pages, proposals and calculators

The other high-value starting point is pages that support sales: a landing page for a campaign, a proposal page for a specific client, or an ROI calculator. They're self-contained, quick to build and easy to review. The Nitrobots example in our CRM articles went from request to a live proposal page and public ROI calculator in one day, with the calculator writing contacts into the CRM; individual results vary. How to brief these pages, measure them honestly and capture leads properly is in AI landing page builder: briefs, analytics and approval.

Web app, installable app or app store?

Many founders assume they need an app in the Apple and Google stores. Often they don't. A progressive web app is built with web technologies but behaves like a platform-specific app: it can be installed on the device and can work offline (MDN: Progressive web apps). For internal tools, kiosks, booking pages and most small-business products, an installable web app avoids app store review cycles and lets you release changes the same day.

Choose a store app when you genuinely need something the web can't do well on your users' devices, or when being in the store is itself part of how customers find you. Ask the agent to explain the trade-off for your specific case before you commit.

What it costs

Software built by an agent isn't free. The costs are just different from a developer's invoice. Plan for these:

Current plans and the human-in-the-loop add-on, if you want a real person involved, are on the pricing page. Compare the total against what you'd pay a developer or agency for the same scope, including the changes you'll want every month after launch. That ongoing cost of change is where agents tend to win most clearly.

The risks, and how to contain each one

Security

AI-written code can contain the same security mistakes as human-written code. Ask for security fixes as routine work, keep the software's dependencies up to date, turn on multi-factor authentication for every admin account, and get a specialist review before you store sensitive personal information.

Payments

Never build your own card handling. Use an established payment processor and test thoroughly in its test environment first. Stripe, for example, provides a sandbox where test transactions don't move funds, and its terms prohibit testing in live mode with real card details (Stripe: Testing). Treat any change near the checkout as a critical path.

Lock-in

Make sure your code lives in a repository your business owns. Cortex lists GitHub and GitLab among its integrations. If you ever change tools or bring in a developer, the code and its history should go with you. We cover the wider question of depending on one AI vendor in AI vendor lock-in.

Knowledge in one place

If only the agent 'knows' how the product works, you have a different kind of key-person risk. Ask for a short plain-English document that explains the main parts of the system, where data lives and how to deploy, and have it updated when things change.

When to hire a developer instead

An agent is not always the answer. Bring in an experienced engineer, alongside the agent or instead of it, when:

• Failure could cause physical harm, serious financial loss or a significant privacy breach.
• You need formal security certification or a regulator-approved system.
• You're inheriting a large, undocumented codebase that nobody understands.
• You expect heavy traffic from day one and performance really matters.
• You don't have the time or interest to act as product owner. An agent amplifies direction; it can't supply it.

Many founders end up with both: the agent handles the steady stream of changes, and a developer reviews the architecture and the risky parts a few times a year.

A first-month plan to build an app with AI without coding

1. Pick one internal tool or one sales page as the first project. Not the core product.
2. Write a one-page brief: users, problem, the three things it must do, what done looks like.
3. Agree hosting, the code repository (owned by your business), previews and the rollback approach.
4. Run the first version through the full loop. Use it yourself for a week.
5. Keep a simple log of what went live, when and why.
6. Only then move to something customer-facing, starting with a small pilot, the way RiideStar started with one car.

Behind the scenes, a request like 'add a badge to explicit songs' is planned and handed to the right specialist by Fulcrum Sessions, the orchestrator; if you're curious how that works, see multi-agent orchestration explained.

If you have a tool or page in mind, the Fulcrum Code overview shows how changes are delegated from chat, built, deployed and reported back.