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).
Trying to help.
1 Like
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.
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.