I don't think you will throw it all out afterwards. It is still a good thing to keep and prototype on as you evolve.

The main drawback I see on replit: it skews you into using their infra. But that doesn't mean you can't hire a developer (or even cursor) to change that. One can develop on replit and commit code to GitHub, which makes you free to use cursor (and also replit) for evolving and making it more robust.

But that doesn't mean you'll throw it all out. It might just mean that your workflow switches to cursor and you work together with developers on the same repo.

A second drawback I see is that replit and cursor are both in one single repo. As your feature set grows it makes it harder for the models to be fully aware of your context. Here again might you may hit a point where you want to hire someone to help you restructure and architect the code. It is not incompatible with the cursor idea i shared above.

If I were in your place I would start by

1) dual development - replit and cursor - because it creates the foundation in GitHub for you to collab with a developer. You'll start using issues, actions etc. You'll gradually turn replit into one part of your dev cycle

2) start looking for a dev that could help you structure the code and architecture.

All in all you don't need to ditch replit completely but you can grow further than it's vanilla usage