We are told that maybe our project is too big for Replit. Before moving to custom code and paying a developer lots of money we wanted to have someone from replit take a look at our project to see if we can in fact keep using replit for our launch and moving forward. Will it grow with us or do we need to think about going custom? Published app is available but we are 80% complete www.naturesteward.com.
Who is telling you this? Seems odd. Your site looks great! So I have a large project and I asked the agent. Here’s what it said. Interesting.
Replit starts to strain when a project combines several of these factors at once:
-
Long build times — You’re already hitting this. Your Next.js build times out in the free/standard compute tier. This is one of the most common friction points for full-stack TypeScript apps.
-
Memory-intensive processes — Type checking a large codebase, bundling, and running a FastAPI backend + Next.js dev server simultaneously competes for the same container RAM.
-
Many background workers — Your project runs a background scheduler, connection pool, health checks, and periodic data ingestion. Each adds resident memory pressure.
-
Large dependency trees — Your
node_modules+ Python packages + system deps are substantial. Cold starts (restarting a workflow) become slow. -
CPU-bound workloads at runtime — AI calls, concurrent HTTP screening across 30+ data sources, DOCX report generation, and shapely/pyproj geocoding all spike CPU. Fine for bursty use, but a problem under load.
Your project specifically is large by Replit standards — a production-grade dual-stack app (FastAPI + Next.js), 12 router modules, 30+ external data connectors, Postgres, Stripe, OpenAI, and a PWA with Capacitor. Most Replit projects are a fraction of this scope. You’re not approaching a conceptual limit; you’re past where Replit is the idealhome, but it still works.
The practical ceiling isn’t a hard wall — it’s friction that compounds:
-
Builds that timeout or require restarts
-
Dev hot-reload being slow because the container is under memory pressure
-
Deployments failing health checks because the server is slow to start cold
What larger teams typically do:
-
Move the FastAPI backend to a dedicated service (Railway, Render, Fly.io, or a VPS) and keep only the Next.js frontend on Replit, or vice versa
-
Use Replit primarily as a development environment and deploy elsewhere for production
-
Upgrade to Replit’s higher compute tiers for the build and run containers
For your use case, Replit remains a reasonable home for continued development — especially with the health check and binding fixes you just made. The deploy is working. The main ongoing friction will be build timeouts, which are solvable by keeping the build command within resource limits (Next.js has options like disabling type checking during next build and running tsc separately).
I’m swamped with work and holiday I just wanted to lob this in for you to consider as a possibility
Look at how the agent answered you here:
I’m sure you phrased your agent conversation in a way that led it to use this tone. However, if you use more aggressive and assertive language that assumes the agent is incorrect or untrustworthy the. You may get it to respond to you by saying something along the lines of:
“You’re project might be too big for Replits current infrastructure”
I’m not saying this is what happened here. Although, it’s interesting to point of that your copied and pasted agent response actually indicated (subtly), that you and your project have or are close to reach the point where Replit might not be the preferred home.
If you removed that context from your prompt, or perhaps ask a completely unrelated LLM like GitHub copilot for example to give you the same response, or better yet an objective one. You might start to see where these “odd claims” often stem from.
Indeed it’s possible. However, there is a growing consensus among larger builds that eventually (as your Replit agent suggested) Replit doesn’t become the ideal home. Not that you couldn’t pay for the inflated case for conviction, convenience, or just the love of Replit.
However, I assure you the way things stand right now. Larger builds will find it more suitable to migrate off for larger buids on to more proven and matured infrastructure.
Again, I’m not saying it’s not possible. I’m saying, it’s like living in an apartment that eventually costs you 10x more than if you left and found a new spot.
Also, this is very dependent on the client/ builders actual build. Not just what the site looks like, but what’s going on under the hood.
You could have a substantial build that runs flawlessly on Replit because it doesn’t require the heavy intensive behind the scenes work going at all times. Or, the opposite.
I don’t think it’s odd at all your asking these questions @jogren. In fact, I encourage you to poke, prod, and get all of these answers.
This wasn’t to offend or say you’re wrong @jogren I’m just saying this isn’t exactly accurate.
Trying to help.
1 Like
No no! Jeez my tone was probably coming off wrong. I totally get it I actually found it helpful myself.
My tone was:
Observer lobbing in objectively.
I totally support you and love the help from the community. I guess I was trying to engage in a more robust conversation about this and it came off as vague pseudo, intellectual posturing.
Feel free to pose the question however you want to whatever AI you choose.
1 Like
Who told you that? Never heard such a thing.
Wanna take a bet if it was AI or not?
Of course there’s no way to validate and verify.
I’m going to assume that there are several projects too big for Replit not that Replit couldn’t handle it but that it’s not cost-effective.
But, hey, what do I know right? Lmfao
And no it was not me who said this to them lmfao although I would say it honestly if I felt it js
Post your project specs, have review the codebase and all the endpoints and other dependancies and post it here, the only real limitation would be an excessively active database (huge data churn) that blows past the included 10gb limit read/write, or high compute. Yours doesn’t seem overly complex though.