Yes, a non-developer can build a working internal client intake app in an afternoon. For a simple internal checklist or form, Claude Artifacts is the fastest place to start because it builds and runs the tool inside the chat window with nothing to set up. If you want a proper multi-page web app with a real URL, Lovable is the friendliest full builder for beginners, with Bolt, Replit and v0 as close alternatives. The catch — and it matters for an Australian firm — is that a prototype built on any of these platforms is not a safe home for real client data.
This article is for practice managers, office administrators and partners in accounting, legal, real estate and conveyancing firms who want a small internal tool and want to know which builder they can actually finish with. If you have never heard the term, start with our plain-English explainer on what vibe coding is for business owners, then come back here.
Lovable vs Bolt vs Replit for beginners
All of these turn plain-English instructions into a working web app. The difference is how much they hide from you and where the result lives. Pricing on every one of these changes often, so treat the tiers below as general guidance and check the current plans before you commit.
| Builder | Best for a beginner | Where the app lives | Cost pattern |
|---|---|---|---|
| Claude Artifacts | A single self-contained tool: a form, calculator or checklist you use inside the chat | Inside your Claude account, in the conversation | Works on the free tier; a paid tier gives more usage |
| Lovable | A full web app with pages, a form and a shareable link, described in chat | Hosted on Lovable's platform; can connect a database | Free tier to experiment; paid tiers for real hosting and more builds |
| Bolt | Similar to Lovable — full apps from prompts, slightly more technical feel | Runs in-browser, deploys to a host you choose | Free allowance of build credits; paid for more |
| Replit | People who want to see and tweak the actual code as they go | Replit's cloud, with hosting and databases built in | Free tier; paid for always-on apps and more compute |
| v0 (Vercel) | Good-looking interface components and page layouts | Your own Vercel hosting once you export it | Free allowance; paid for heavier use |
The honest summary: if your tool is one screen, use Claude Artifacts and skip the rest. If you genuinely need several pages and a saved-data backend, Lovable is the gentlest on-ramp. Bolt and Replit reward slightly more patience. v0 is strongest when you care about how it looks. None of them require you to write code — they require you to describe clearly and correct firmly.
Can I build an internal tool with AI for my office?
For internal, low-stakes tools, absolutely — and it is one of the best uses of an afternoon. Good candidates are things that are currently a scruffy Word document or a shared spreadsheet: a matter-intake checklist, a document-request list generator, a fee estimate helper, a settlement-date counter.
What these have in common is that they help a staff member do a task, they don't need to be right every single time, and no real client information has to be permanently stored to make them useful. That is the safe zone for a prototype.
The tools that are not good first builds are anything that logs in as a client, takes a payment, stores personal information, or feeds a downstream system that trusts it. Those need a developer and proper controls. We will draw that line clearly at the end.
A worked build: a matter-intake checklist app in Claude Artifacts
Here is a build a beginner can finish today. The goal is an internal tool where a staff member picks a matter type and gets a tailored checklist of what to collect from a new client, which they can tick off and print. We will use Claude Artifacts because it needs no setup — go to claude.ai, start a chat, and it renders the app beside your conversation.
Step 1: Describe the tool
Type something close to this:
Build me an internal web app called Matter Intake Checklist. At the top, a dropdown to choose a matter type: Conveyancing – Purchase, Conveyancing – Sale, Family Law, Commercial Lease, Estate. When I pick one, show a checklist of the documents and details our office needs to collect for that matter type. Each item has a tick box. Show a progress count of items ticked. Add a Print button. Keep it clean and plain, no colours needed.
Claude will generate a working app on the right. Pick a matter type and the checklist should appear.
Step 2: Fix the first wrong result
The first version is almost never quite right — reacting to that is the actual skill. If the checklist items are too generic, correct it in plain English:
The conveyancing purchase checklist is too vague. Replace it with: signed contract of sale, buyer's ID (two forms), deposit source and amount, finance approval details, building and pest inspection status, and property address. Do the same level of detail for the other matter types.
Keep going in small corrections: "Move the print button to the top too", "Add a free-text notes box under each checklist", "Add a field for the fee-earner's name that prints on the checklist". Change one thing at a time so you can see what each instruction did.
Step 3: Make it genuinely useful
A few finishing prompts that pay off:
- "Add a button that copies the unchecked items as a plain-text list I can paste into an email."
- "Show today's date at the top."
- "When all items are ticked, show a line that says the intake is complete."
That copy-the-unticked-items button turns your checklist into a document-request list you can send a client — which is the exact bridge into a real onboarding process. When you are ready to make that process repeatable rather than manual, our guide to automating client onboarding in a law firm shows where it goes next.
Step 4: Keep it, but keep it out of shadow IT
The Artifact lives in your Claude account. To reuse it, save the conversation or ask Claude to give you the code to paste into a Lovable or Replit project for a proper URL. Tell your firm's principal or IT contact it exists. A helper tool that no one else knows about is exactly how shadow IT starts — a one-line note in your AI policy covering "internal tools staff have built" solves it.
Where does an AI-built app store its data?
This is the question that decides whether your prototype is safe. A single-file Artifact or a fresh Lovable app usually keeps whatever you type only in your browser session or in the builder's own cloud — it disappears or persists in ways you did not design and cannot audit. The moment you connect a database (Lovable and Replit make this easy), that data sits on a third-party platform, often on overseas servers.
For an Australian firm this is not a technicality. Under the Privacy Act and the Australian Privacy Principles, the moment you enter a client's personal information into one of these systems you are handling it under the Act, and storing it overseas is a cross-border disclosure under APP 8 that has to be documented. The OAIC's general guidance on commercially available AI products is blunt: publicly available tools should not be given personal information. That guidance, not a builder's marketing page, is the reference point.
So the rule for prototypes is simple: use fake data only. Test your matter-intake checklist with "John Sample" and "123 Test Street", never a real client. We cover the full picture in whether AI is safe for client data under the Australian Privacy Act — read it before you connect any tool to anything real.
Where a prototype stops and a real system begins
A vibe-coded app is a brilliant prototype and a poor production system. The honest line is here: the moment your tool needs any one of the following, it stops being a weekend build and needs a developer or a proper platform.
- Logins. As soon as different staff need accounts and permissions, you need real authentication — not something improvised in a prompt.
- Stored client data. Anything that saves personal information needs a governed database, an enterprise or API tier where your data is not used for training, a documented data-flow record, and Australian or contractually-controlled hosting.
- Backups. If losing the data would hurt, a prototype's storage is not enough. You need backups and a recovery plan.
- It has to be right every time. A checklist that helps a human is fine. A tool the firm relies on without checking is not — that needs testing and someone accountable for it.
- It faces the client. Anything a client sees or fills in should be built and reviewed properly, never shipped straight from a builder.
If you want the persistence and structure without a developer, a no-code platform is often the sensible middle ground — see our walkthrough of building a client intake form with Notion, ChatGPT and Zapier, which keeps data in tools your firm already controls.
Start with a throwaway internal tool, prove the idea works, then decide whether it earns a real build. If you want more small automations you can try the same way, our free guide to 10 AI workflows to save 10+ hours a week is a good next step — practical builds, with the same discipline about real client data throughout.
Common questions
Is Lovable or Claude better for building a client intake app?
For a single-screen intake checklist, Claude Artifacts is faster because it builds and runs the tool inside the chat with nothing to set up. Choose Lovable when you need a real multi-page web app with a shareable link and saved data. Beginners usually prototype in Claude first, then move to Lovable only if the tool proves worth keeping.
Can I put real client details into an app I built with an AI builder?
No. Treat these prototypes as fake-data-only tools. Under the Australian Privacy Act, entering personal information means you are handling it under the Act, and storage on a builder's overseas servers is a cross-border disclosure. The OAIC's general guidance advises against giving personal information to publicly available AI tools. Test with sample names and addresses instead.
Where does an AI-built app actually store the information I enter?
It depends on the build. A simple Claude Artifact or fresh Lovable app usually keeps data in your browser session or the builder's own cloud, often overseas, in ways you cannot audit. Once you connect a database, that data sits on a third-party platform. This is why prototypes should never hold real client information.
When do I need a real developer instead of a vibe-coded tool?
Hand it to a developer or a governed platform the moment the tool needs logins and permissions, stored client data, backups, a guarantee of being right every time, or a client-facing screen. Vibe-coded apps are excellent prototypes to prove an idea, but they lack the security, hosting controls and accountability a production system requires.
Do I need to write any code to build an internal office tool?
No. Every builder mentioned here — Claude Artifacts, Lovable, Bolt, Replit and v0 — turns plain-English descriptions into working apps. The real skill is not coding but describing clearly and correcting the first result firmly, one change at a time. Replit will show you the code if you want it, but you never have to touch it.
Want these ideas working in your firm? We build controlled AI workflows for Australian professional services firms — starting with a free automation audit.