Replit, or an application from a description, hosting included

Replit, or an application from a description, hosting included

Replit began as a development environment running in a browser and became, above all, a tool where you describe an application in words and an agent builds, runs, and deploys it.

The difference from assistants working inside an editor is that here you get the whole chain. There is no separate step for configuring an environment, choosing hosting, or connecting a database. You write what should exist, and a quarter of an hour later you have a working address.

The newest agent version goes further: it checks the built application in a browser itself, clicks interface elements, detects errors, and fixes them without asking. That changes the character of the work and, as you will see below, changes the bill too.

Effort based billing

The billing model is the most important thing to grasp before starting, since it differs from everything other tools have accustomed you to.

The billing unit is a checkpoint, a snapshot of the project state the agent creates after completing a piece of work. Checkpoints serve a double role: they let you roll back to an earlier version of the application and they show what you paid for.

One frequent misunderstanding deserves straightening out immediately, since it leads to wrong conclusions about the bill. A charge is not tied to checkpoints alone: every agent interaction is billed, including a planning mode conversation after which no code change and no checkpoint appears. Checkpoints show up when the agent actually changed code rather than when a charge applied.

Previously every checkpoint cost the same, regardless of whether it covered a one line fix or rebuilding a module. Now the price depends on actual effort: the time and compute a given task consumed. A small change costs less than the former flat rate, while a large task fits into one checkpoint and costs correspondingly more.

The change is sensible and carries a side effect worth naming plainly. You do not know in advance what a given instruction will cost, since it depends on how much work the agent judges necessary. An instruction that sounds innocent can trigger a long chain of changes with a bill to match.

The newest agent version's character adds to that. Since it tests the application itself, clicks through the interface, and fixes what it finds, it performs many times more work per instruction than earlier versions. Users report noticeable bill increases after moving to it for that reason, and that is not a flaw in the tool but a consequence of it doing more.

The agent is only part of the bill, though, since you pick a plan first and the plan grants a credit allowance the charges come out of. There are two rates, because annual billing costs less than monthly.

Two things in that table usually escape notice. Credits on Core reset at the start of each billing period and do not carry forward, while on Pro an unused allowance rolls over for two further months before expiring. Credit packs bought separately expire six months after purchase and likewise do not carry forward.

Know too what happens once the allowance runs out and a limit is reached, since it is not merely a notification. A usage limit blocks the services billed by consumption until the next period begins or the ceiling is raised, and a separate shutdown limit suspends running services in the same fashion.

How to keep it under control

Since the cost is variable, working in a way that constrains it from the start pays off.

The first rule concerns instruction size. One large instruction covering four features at once gives the agent freedom whose cost is hard to predict. Four smaller instructions, each checked before the next, usually cost less and give a better result, since errors surface early.

The second concerns a spending limit. Set it before starting work, at an amount you are willing to pay. It is the only mechanism working without your attention, and with a tool that works on its own for a quarter of an hour, attention is unreliable.

The third concerns when to stop. The tool excels at building from scratch and at the first few dozen changes. On an application that already works and needs a precise fix in one place, describing that fix in words is often more expensive and slower than opening the code and changing two lines.

The fourth concerns reviewing the output. An agent testing itself detects technical errors rather than a divergence between what it built and what you wanted. Checking after every larger step costs a minute and prevents a situation where three further instructions elaborate a solution heading in the wrong direction.

The fifth concerns the agent's operating mode, the lever skipped most often. Small, narrow changes belong in the lightest mode, everyday work in the economy mode, and the most capable models deserve saving for tasks that genuinely need them. Picking the mode can move the bill more than shortening instructions does.

What you get beyond the agent

The rest deserves listing, since it is what sets this tool apart from assistants working with code alone.

The environment runs in a browser, so there is no local installation or configuration. That matters when working from a modest machine, during training, and when onboarding somebody, since getting started takes a minute rather than an afternoon.

Deployment is part of the tool. The application gets an address, certificate handling, and the option of attaching your own domain, without choosing a hosting provider or configuring anything.

A database and secret storage are built in, so a typical project needs no external services at the start.

Collaboration works inside one file simultaneously, as in a document editor. That helps with learning and with quickly showing somebody something, and less with a development team's daily work.

A caveat: the code produced is ordinary code and can be downloaded. That matters, since it means a project built here can move elsewhere, to Railway or Vercel for instance, once it outgrows this way of working.

How to write instructions for the agent

Since this is the main way of working, what separates an instruction that works from one you must undo deserves a moment.

Start by describing what the application should do from a user's point of view rather than how it should be built. An enumeration of tables and fields carries less useful information than a description of behaviour, since it removes the agent's ability to choose an approach.

A team task application.

A user signs in with an email address, creates a list, adds tasks to it,
assigns them to somebody on the team, and marks them done. Everyone sees
only the lists of the team they belong to.

Constraints that matter to me:
- data in a relational database
- passwordless sign in, through a link sent to the address

Keep the constraints block short and put in it only what genuinely matters. Ten preferences in the first prompt make the agent spend half its work satisfying them rather than on a working application.

State the constraints you care about, and only those. Naming a technology, a data format, or a login method makes sense when it genuinely matters. Listing ten preferences in the first instruction means the agent spends half its work satisfying them rather than on a working application.

Describe successive steps in the order you would perform them yourself. First the data model and basic operations, then the interface, finally appearance and details. The reverse order leads to a visually polished screen needing rebuilding because the way data is stored changed.

For fixes, point at the place rather than the symptom. The cost difference between two phrasings of the same report is often several fold.

Expensive: the save button does not work

Cheaper:  on the task edit screen the save button does not submit the form,
          the data is valid, there is no console error, clicking does
          nothing and the address does not change

The second phrasing is not longer for decoration. It removes the reproduction stage from the agent and narrows the search to one screen, and on a larger application that part of the work costs the most.

One last thing: record what already works. A checkpoint after every working feature gives you a point to return to, and that is the only protection against an instruction that breaks something previously working perfectly.

Since the resulting code is ordinary code, keep it in your own repository from day one as well, independently of the tool's checkpoints.

git init
git add -A
git commit -m "Sign in and task list working"
git remote add origin git@github.com:company/tasks.git
git push -u origin main

That habit costs a minute and settles two things at once: you have history readable outside the tool, and a ready exit route for when the project outgrows this way of working.

Replit against the alternatives

The split runs along one question: do you want the code under control, or do you want the result. On a prototype, an internal application, and learning, the result matters, so the first row wins. On a system maintained for years by a team the code matters, and then a tool working in your editor and repository fits better.

Note too that this is not a permanent choice. Starting here and moving the project once it leaves the prototype phase is a normal path rather than a failure.

The limits of this approach

They deserve naming plainly, since the tool's promise is broad and the limitations are real.

The first concerns complexity. An application with a few tables, login, and a dashboard comes together here smoothly. A system with twenty modules, dependencies between them, and business rules demanding precision exceeds what can be sensibly described in words.

The second concerns maintenance. Code generated by an agent is often correct and simultaneously inconsistent in style, since it arose across dozens of steps without an overall plan. On a project somebody must develop for two years, that is a real cost.

The third concerns cost predictability. On a project with a fixed budget, billing tied to the agent's effort is a risk to accept deliberately or constrain with a limit.

The fourth concerns dependence on one platform. The code can be downloaded, while the built in database, secret storage, and deployment are part of this environment, so moving a project means recreating those elements elsewhere.

Security of an application built from a description

This part deserves separate treatment, because an application can work flawlessly and carry a serious problem that nothing signals.

The most common concerns data access. The agent builds the read and write layer so that it works, and the rule "a user sees only their own entries" appears when you ask for it. Without that the application behaves correctly for one user and exposes other people's data once a second one arrives.

The second concerns keys and passwords. The environment has a built in secrets store and it pays to use it from the start, since a key typed into code enters project history, and once the project is shared publicly it stays there permanently.

The third concerns server side validation. Checking data only in the browser looks complete and is not, since a request can be sent bypassing the interface. That mistake occurs in hand written code too, but here it is harder to notice, because you do not read every line.

The fourth concerns what the application exposes publicly. The deployment address is available to anyone who knows it, so an administration panel without sign in is open to the world even though nobody links to it.

Checking the first of these comes down to two requests: one with one user's token and one with another's, for the same resource.

curl -s -H "Authorization: Bearer $TOKEN_ANNA" \
  https://my-app.replit.app/api/tasks/42

curl -s -H "Authorization: Bearer $TOKEN_MAREK" \
  https://my-app.replit.app/api/tasks/42

If both calls return the same task, the access rule does not exist, regardless of the interface showing each person only their own list. The second thing takes one call with no header at all.

curl -s -o /dev/null -w "%{http_code}\n" https://my-app.replit.app/admin

Any code other than 401 or 302 means the panel is open to anyone who knows the address.

Practical advice: before sharing anything beyond your own team, ask the agent explicitly for a review focused on data access, and then check those two things yourself. That is ten minutes which saves considerably more.

Common mistakes

The first is no spending limit. Billing depends on the agent's effort, so without a ceiling the bill can surprise you after one evening.

The second is instructions covering too much at once. Four smaller steps, each checked, cost less and give a better result than one large one.

The third is using the agent for small fixes in a working application. Opening the code and changing two lines is often faster and cheaper than describing that change in words.

The fourth is relying on the agent's self testing as a review. It detects technical errors rather than a divergence between the result and your intent.

The fifth is building a system meant for years of maintenance here without a plan to move it. The code can be downloaded, but the later you do it, the more environment pieces must be recreated.

The sixth is skipping code review with sensitive data. An application built from a description can work correctly and leave data openly accessible, because nobody checked.

FAQ

How does billing work?

The price depends on actual effort, so a small change costs less while a large task fits into one checkpoint and costs correspondingly more. Charges come out of the monthly credit allowance attached to your plan: 25 USD on Core and 100 USD on Pro. Every agent interaction is billed, including a planning mode conversation after which no checkpoint appears.

Why did bills rise after the new agent version?

Because the agent does more per instruction: it tests the application in a browser itself, clicks through the interface, detects errors, and fixes them. More work performed means a higher cost under effort based billing, so a spending limit deserves setting before you start.

Can I download the generated code?

Yes, ordinary code is produced and can be moved elsewhere. The built in database, secret storage, and deployment are part of this environment, though, so moving a project requires recreating those with another provider.

Is this suitable for a production project?

For an internal application, a team tool, and a prototype shown to a client, yes. For a system maintained for years, consider moving it once it leaves the prototype phase, since code produced across dozens of steps is often stylistically inconsistent.

How does it differ from an editor assistant?

In scope. Cursor and similar tools work on your code in your environment, with deployment and infrastructure remaining yours. Here you get the whole chain from a description to a working address, at the cost of less control over what appears along the way.

Documentation sits on the project site, and the billing change is described in the vendor's post.