A web app with login and database without a dev team

The short answer: the agent writes, you define

Not long ago, a web app with login and a database meant hiring at least one developer for a few weeks, or stitching together no-code tools that never quite talked to each other. Today an AI agent can write the whole app: screens, signup, login, a members area, database tables and the rules for who sees what.

What is still your job, and what decides whether the project works:

• Who uses the app and which types of users exist.
• What each of them sees and can do.
• What data the app keeps and for how long.
• The main path, the thing people come to do.

Once that is clear, the rest is conversation.

Website or web app: do you really need login?

Before asking for a web app, check that you do not just need a website. A site with a form covers a lot: quotes, contact, signups. Login is worth it when:

• Each person needs to see their own data (orders, appointments, documents, progress).
• There are repeated actions that get saved (log a visit, update a status, approve something).
• There are different roles, such as customer, staff and admin.

Typical examples for people who build sites for small businesses: a client portal for an accounting firm, member tracking for a yoga studio, a patient area with documents for a clinic, a simple work order system for a repair shop.

Write the request as a usage story

The agent understands plain language, but a vague request gets you a generic app. Instead of "I want a system for my gym," describe:

1. Who signs in: "Members and trainers. The owner is the admin."
2. What each does: "Members see their workouts and check in. Trainers create workouts for their own members. The owner sees everything."
3. The data: "A member has a name, email, phone and plan. A workout has exercises, sets and a date."
4. The first screen each one sees after logging in.
5. What must never happen: "A member never sees another member's workout."

That last line matters most. Access rules are where improvised apps usually fail, and writing them down from the start makes the agent build the separation into the database and the routes, not just hide a button.

What comes ready and what needs your attention

The most valuable test is simple: create one user of each type and use the app the way they would. Try opening another user's page by editing the URL. If something shows up that should not, ask for the fix with that exact example.

Start with the smallest app that works

The app that gets finished is the one that starts small. A suggested scope for version one:

• One user type besides the admin.
• Two or three screens.
• One main table.
• One complete flow, from signup to the main action.

Put it in the hands of three or four real people for a week. What they ask for is version two. This matters even more if you are selling the app to a client: shipping a useful first version fast and charging for its evolution beats promising everything at once.

Where the app runs

A web app with login needs its own process on the server, unlike a static site. The common options:

• A managed app server: you do not run a machine, and the limit is the plan's.
• A VPS: dedicated resources and full control, with server maintenance on you.

For most MVPs and small business portals, managed is enough. A VPS makes sense when the app grows, needs specific software or the client wants isolation.

How to do it on Basely

On Basely, Web Apps are built by the same agent as the AI Builder:

• Next.js with signup, login, a members area and its own Postgres database for each app.
• You describe the app in conversation; the agent writes the code, checks it in a real browser and publishes. Changes go through conversation too.
• The code is saved to a repository, so the project is yours and portable.
• Published on our server, within your platform plan's limit, or on a VPS when the app calls for it.

If you sell the app to a client, it follows the same sales flow as sites: proposal, contract and the client with their own login to the portal. And if you prefer the terminal, the Connector lets Claude Code read and write the app's files and query its data.

The honest limit: the agent builds what you describe. If the business rules are complex or the app handles sensitive data, have someone technical review it before opening it to the public.

The plan on one page

1. Write who uses it, what each person does and what must never happen.
2. Cut it down to the smallest app that solves the main problem.
3. Ask the agent, then test by signing in as each user type.
4. Put it in front of a few real people.
5. Improve based on what they ask for.

Write your app's usage story today and start with the first screen.