Can Claude Code and Codex Build Apps for Thousands of Concurrent Users?

Can Claude Code and Codex help build applications that thousands of people use at the same time? Yes. But a working demo is not evidence that an application can handle production traffic.

AI coding tools can help implement, test and improve software. The capacity of the finished application depends on its architecture, database, infrastructure and operational discipline. Those qualities need to be part of the brief from the beginning.

Start with what “thousands of users” actually means

Ten thousand registered accounts, ten thousand active sessions and ten thousand simultaneous requests are very different workloads. A customer portal showing cached pages behaves differently from a booking system where everyone tries to reserve the same slot.

Describe the important user journeys, peak activity, data volumes, geographical distribution and read/write mix. For example, 5,000 active users making one API request every ten seconds generate roughly 500 requests per second on average. A page that triggers six API calls, a synchronised login burst or automatic retries can change that picture substantially.

Specify both the expected workload and the overload scenario. Decide what the application should do when demand exceeds capacity: queue work, reject excess requests clearly or temporarily reduce optional functionality.

Turn non-functional requirements into acceptance criteria

“Make it fast, secure and scalable” gives an agent too much room to guess. Non-functional requirements describe how well the system must work and under which conditions. Make them measurable and connect each one to evidence.

• Performance: define response-time targets per critical journey, including the 95th and 99th percentiles. An average can hide a painful experience for many users. Separate browser experience from API latency.
• Capacity: define active users, requests per second, burst duration, background jobs and realistic database size. Include file uploads and long-lived connections if they matter.
• Reliability: agree an availability objective, timeouts, retry limits and graceful degradation. Define acceptable data loss and recovery time, then test restoration.
• Security and privacy: require server-side authorisation, tenant isolation, input validation, secret management and appropriate data retention. Include negative tests: a user must never access another customer's records.
• Observability: require useful metrics, structured logs and traces without sensitive payloads. Monitor latency, errors, saturation and queue age, with alerts someone owns.
• Maintainability and accessibility: require understandable modules, automated checks, documented deployment and rollback, keyboard navigation and accessible critical flows.
• Cost: set an agreed operating budget and track cost per meaningful transaction. Include databases, storage, network traffic, monitoring and third-party services.

Targets are business decisions, not universal defaults. A reporting portal and a payment platform need different trade-offs. Have product, engineering and operations agree the requirements before asking an agent to implement them.

A prompt that makes the requirements concrete

The following is an illustrative starting point for a customer portal, not a capacity claim or a benchmark achieved by either tool:

Build a customer portal for 5,000 simultaneously active sessions. Model 500 API requests per second sustained for 30 minutes, with an 80/20 read/write mix and a two-minute burst at 1,000 requests per second. Use realistic data volumes and document the assumptions behind this workload.

For the main read endpoints, target p95 below 300 ms and p99 below 800 ms in the agreed test environment. Keep unexpected failures below 0.1% at the sustained target. Report all rejected and timed-out requests separately, including rate limiting. Never hide failures by excluding them from the report.

Enforce authorisation and tenant isolation on every server-side operation. Use bounded database connection pools, pagination and appropriate indexes. Make retried writes idempotent. Put slow exports in a durable queue with bounded retries and visible failure states.

Propose a monthly availability objective of 99.9%, recovery within one hour and no more than 15 minutes of data loss, and identify what infrastructure and operating procedures those objectives require. A load test alone does not prove these objectives.

First inspect the existing system. Ask about missing constraints, including hosting, data residency, retention and budget. Propose the simplest suitable architecture and explain bottlenecks, failure modes and trade-offs before implementing.

Deliver in small, reviewable changes. Include automated tests, a reproducible load-test script, dashboards, a backup-and-restore exercise and a deployment/rollback runbook. Report measured results with the commit, environment and resource limits. Clearly distinguish passed checks, assumptions and checks that could not be run.

Keep these requirements in version-controlled project documentation and refer to them in follow-up tasks. A long opening prompt will not protect requirements that disappear from the development workflow.

Choose an architecture you can operate

Thousands of users do not automatically require microservices or Kubernetes. A well-structured application with a managed database, sensible indexes and an appropriate deployment can be a practical starting point. Split components when measured bottlenecks or operational needs justify the complexity.

Keep application instances stateless where possible so traffic can be distributed across them. Use shared session storage when needed. Serve static assets through a CDN. Cache carefully, with explicit invalidation and correct separation of private or tenant-specific data.

Pay particular attention to the database. Unbounded queries, missing indexes and repeated queries inside loops can overwhelm it long before application CPU is exhausted. Adding application replicas can make matters worse if each replica opens another large connection pool.

Move slow work such as exports and document processing into background workers. Bound concurrency and queue size. Use timeouts, retry backoff and idempotency so a temporary dependency failure does not become duplicate orders or a retry storm. Protect shared limits such as a final available booking slot with database transactions and constraints.

Prove capacity before launch

Ask Claude Code or Codex to help write tests, then inspect whether those tests represent the requirements. Generated tests can repeat the same mistaken assumptions as generated implementation. Human review and independently defined acceptance criteria remain important.

Run load tests in an authorised environment that resembles production, using realistic data, authenticated sessions and the actual mix of user journeys. Include cache misses, concurrent writes and slow external dependencies. Confirm the load generator itself is not the bottleneck.

Test sustained demand, sudden spikes, gradual overload and a longer soak to expose memory leaks or resource exhaustion. Measure throughput, tail latency, errors, database connections, lock contention, queue depth and cost together. Fix the limiting resource and rerun the same scenario.

Also test failure: restart an instance, interrupt a dependency, retry a write and restore a backup. Verify that the system recovers without corrupting data. Record the tested capacity envelope; do not turn one successful run into an unlimited scalability promise.

Release gradually and keep checking

Use automated delivery checks and a staged rollout. Watch real user behaviour, latency, error rates and resource usage. Define who responds to alerts and when to roll back. Check that database migrations remain compatible during deployment and that rollback is actually possible.

If the application itself calls an AI model, add a separate capacity and cost plan for provider quotas, token usage, latency, queues and fallbacks. Using AI to write an application does not mean that the application needs AI at runtime.

Official guidance supports a specification-and-verification workflow: OpenAI's Codex modernisation guide connects design specifications with validation plans, while Anthropic's Claude Code best practices emphasise giving the agent a way to verify its work. Neither substitutes for testing your application's actual capacity.

How HumanInTech can help

At HIT, we bring architecture, hands-on engineering, delivery leadership and AI expertise together. We can help translate business expectations into measurable requirements, review an AI-built prototype, identify database and integration bottlenecks, and build the testing and operational foundations needed for production.

That can take the form of a focused architecture review, a clearly scoped engineering engagement or a senior consultant embedded in your team. The goal is to give your people a system they can understand, operate and improve as demand grows.

Explore HIT's architecture, engineering and AI services, or talk to us about your application and expected workload. We will help you establish what is ready, what needs work and what evidence you need before opening the doors to thousands of users.

Yes, AI coding tools can help you build for scale. Make the non-functional requirements explicit, turn them into checks and let measured results determine when the application is ready.