The Boring Checklist Between 'It Works' and 'It's a Real Product' (Legal, Domains, Permissions, Keys)

A privacy policy and terms of use are not paperwork for paperwork's sake. They reduce your risk of being an easy target and they make your product look credible to users and potential business customers. The builder who raised this issue was direct about his reasoning. He called the legal step the final boss of the whole project, and said he added a privacy policy and terms of use for two reasons. First, so he would not be an easy target for people who look to exploit undocumented apps for money. Second, because it made his product look more professional the moment a real user or a potential partner looked at it closely. Both reasons hold regardless of how small your app is. An app with no stated privacy policy and no terms of use signals, to anyone who checks, that nobody has thought about what happens to user data, what users are allowed to do, or what you are and are not liable for. That is exactly the kind of gap that draws unwanted attention. You do not need a bespoke document drafted from scratch. Plenty of generator tools and templates exist to produce a reasonable first draft based on what your app actually collects and does. The bar to clear is having something specific to your app, not a placeholder page, and having it live before you share the link widely. This is general guidance, not legal advice. If your app handles sensitive data, payments or health information, get a real legal review before you rely on a template.

Least privilege means each cloud service or key gets only the specific permissions it needs to do its job, not broad access to everything in your account. It looks simple to describe and takes real time to set up properly. Most vibe-coded apps are wired up quickly: a database key here, a storage key there, an AI provider key everywhere. The fast path is to grant broad access once and move on, because narrowing permissions down to exactly what each piece needs takes extra configuration and extra thought about roles. The builder who documented this step called it out directly: you have different roles here, and setting each one up properly takes time. The practical version of least privilege for a solo builder looks like this. If a key only needs to read from one table, it should not also be able to write to or delete every table in your database. If a service only needs to send email, it should not also hold permission to manage billing or spin up new infrastructure. If a key is only used in server-side code, it should never be exposed to the browser at all. Most cloud platforms (Supabase, Firebase, AWS and similar) let you scope roles and keys down to specific tables, buckets or actions rather than granting account-wide access. It is worth the extra half hour to walk through each key your app uses and ask what is the narrowest permission set that still lets this work. One leaked key with narrow permissions is an inconvenience. One leaked key with broad permissions is a genuine incident. Knowing that least privilege matters is one thing. Sitting down and configuring roles correctly while you are also trying to ship features is a different story, which is why this step gets skipped by default rather than by choice.

A dependency audit checks every package your app relies on for known security vulnerabilities, and it takes one command to run. Skipping it means shipping other people's unpatched bugs as if they were your own. AI coding tools pull in packages constantly to solve small problems, and each package brings its own dependencies with it. A typical vibe-coded app can easily depend on hundreds of third-party packages the builder never directly chose or reviewed. Any one of them can carry a known, publicly documented vulnerability. Running an audit is straightforward even without deep technical knowledge. In a Node-based project, typing npm audit in the terminal lists every known vulnerability across your dependencies, ranked by severity, usually with a suggested fix command included. Most AI coding assistants can run this command for you and explain the results in plain English if you ask them to. The fix is often as simple as updating a package version. Occasionally it means replacing a package that has stopped being maintained. Either way, this is a five-minute check that catches problems most non-technical builders never think to look for, because nothing about the process of building the app prompts you to run it.

A proper business email and a domain that is actually available and correctly configured are basic credibility signals that also protect your personal accounts from being tied to your product. Using a personal email address as the public contact point for an app mixes your personal identity with your product's, and it looks noticeably less credible to anyone evaluating whether to trust you with their data or their money. Setting up a business email tied to your own domain, through your domain registrar or an email provider, is a small step that most guides skip entirely because it is not a coding problem. The domain itself needs the same attention. Confirm the name you want is actually available before you build a brand around it, register it through a reputable registrar, and make sure DNS records point correctly at wherever your app is hosted. A domain that is registered but misconfigured, or one where the DNS points at the wrong service, undermines the professional impression you are trying to create just as much as having no domain at all. Neither of these steps is technically hard. They are simply not steps that emerge naturally from asking an AI tool to build an app, so they get left until someone notices the app still has no proper public identity months after it went live.

Manually checking what your own API endpoints actually return, not just what you intended them to return, is one of the most useful habits a solo builder can build. It catches real oversharing before anyone else finds it. One builder testing his own app found exactly this kind of issue during development. An endpoint was meant to return a public question and answer. Instead, it was also returning the email address of the person who had asked the question, sitting alongside the public content. He caught it by opening the API response directly in a browser and reading through what actually came back, rather than assuming the code did only what he had asked it to do. If he had not caught it, anyone could have opened that same endpoint in a browser and read every email address attached to a question, without needing any special access or technical skill. That is the shape most real-world oversharing bugs take: not a dramatic hack, just an endpoint quietly returning one field too many. The fix is a habit, not a tool. Before you consider a feature finished, open the relevant API response in your browser or a request tool and read through the raw data field by field. Ask whether each field genuinely needs to be there, and whether any of it identifies a specific person. This check takes a few minutes per endpoint and it is one of the highest-value security habits available to someone who cannot read every line of AI-generated code.

Building and launching from Australia adds two extra considerations on top of the general checklist: the Australian Privacy Principles and Australian Consumer Law, both of which can apply even to a small solo project. The Australian Privacy Principles set out how personal information should be collected, used, stored and disclosed, and they can apply to your app depending on what data it collects and how much revenue your business generates. Australian Consumer Law separately covers how you represent your product, what guarantees apply, and how you handle complaints and refunds if you charge for anything. Neither of these replaces the general privacy policy and terms of use covered earlier. They sit alongside it as specifically Australian obligations that a generic overseas tutorial will never mention, because most vibe-coding content is produced for a US audience operating under different rules entirely. This is general information, not legal advice, and the detail genuinely matters here. If your app collects meaningful personal data or you plan to charge Australian customers, get a proper read of how the Privacy Act and Australian Consumer Law apply to your specific situation before you scale beyond a handful of early users.

This checklist exists because almost none of it emerges naturally from asking an AI tool to build your app. It has to be taught, deliberately, alongside deployment rather than left for each builder to stumble onto separately. Every item above (privacy policy, least-privilege permissions, dependency audits, business email, domain setup, and checking your own API responses) sits outside the part of building that AI tools handle well. AI tools are excellent at writing the code you ask for. They do not remind you to scope a database key down to one table, and they will not flag that your endpoint is leaking an email address unless you specifically ask them to check. At buildAcademy, this surround work is covered in the same week as deployment, not treated as homework you discover you needed after something has already gone wrong. Students walk through the privacy policy and terms setup, configure least-privilege permissions on their own accounts, run a real dependency audit, and check their own API responses for oversharing, with a mentor in the room to answer the specific question that only comes up once you are doing it on your real app. The goal is not to turn every student into a security specialist. It is to make sure the gap between a working app and a legitimate product closes in a single guided week, rather than becoming the reason a good project never gets shared beyond a small circle of friends.

Do I actually need a privacy policy for a small app with only a few users? Yes, if you collect any personal information at all, even just an email address for sign-up. The number of users does not change whether data protection rules apply, and having a policy also reduces your risk of being targeted and improves how professional your app looks. This is general guidance, not legal advice, so check your specific situation if you are unsure. What does least privilege actually mean in practice for a solo builder? It means each key or service in your app gets only the specific access it needs, not broad account-wide permissions. A key that only needs to read one table should not also be able to delete every table in your database. Most cloud platforms let you scope this down; it just takes deliberate setup rather than accepting the default. How do I run a dependency audit if I am not technical? In most JavaScript-based projects, typing npm audit in the terminal lists known vulnerabilities across your packages with suggested fixes. Your AI coding assistant can run this command and explain the results in plain English, and most flagged issues fix with a simple version update. Is checking my own API responses really necessary if my code looks correct? Yes. Code that looks correct can still return more data than intended, as in the example above where an endpoint quietly leaked an email address alongside a public answer. Reading the raw response yourself catches problems that reviewing the code alone will not. Does Australian privacy law apply to a hobby project I have not started charging for yet? It depends on what data you collect and your business's size and revenue, among other factors, so it is worth checking rather than assuming it does not apply. Once you start charging Australian customers, Australian Consumer Law also comes into play. This is general information, not legal advice, so get a proper check for your specific setup before scaling up.