Chapter 9: Production Mode

Production mode only applies to external projects. If your project is internal (tools for you, your team, or a small trusted group), stable mode is the finish line.

The transition from internal to external is significant. You're declaring that real users will depend on your software. Once you make that declaration, every feature must go through production mode. The standards you set apply going forward.

Before you can implement production mode, you need to know what "production-ready" means for your project. This varies dramatically based on what you're building.

A beta SaaS with twenty early users has different needs than an enterprise platform serving Fortune 500 companies. A side project gaining traction has different needs than a healthcare application handling patient data.

The Jetty Method uses production standards presets to capture these differences:

Startup MVP. Early-stage products, internal tools going external, prototypes with first users. Basic security, simple monitoring, daily backups. The minimum viable production setup.

Production SaaS. Established products with paying customers. Web application firewalls, performance monitoring, zero-downtime deployments, on-call rotation. What most SaaS products need.

Enterprise. Mission-critical systems with strict SLAs. Multi-region deployment, advanced DDoS protection, chaos engineering, disaster recovery. For products where downtime has serious consequences.

Regulated. Products handling sensitive data under compliance requirements. HIPAA, PCI, FedRAMP. Encryption everywhere, audit logging, quarterly penetration testing. For healthcare, finance, and government.

You choose your preset when you transition from internal to external. The preset defines specific standards for security, performance, monitoring, and compliance. These standards become the specification for production mode.

Production mode implementation varies based on your chosen standards, but typically includes:

Security hardening. Rate limiting on public endpoints to prevent abuse. Input sanitization to prevent injection attacks. Authentication and authorization checks everywhere they're needed. Security headers to protect against common web vulnerabilities. The defenses that protect against malicious users.

Performance optimization. Load testing to verify the system handles expected traffic. Performance budgets to catch regressions. Caching strategies to reduce server load. Database query optimization to maintain acceptable response times. The work that ensures your application stays fast under real conditions.

Monitoring and observability. Error tracking so you know when things break. Performance monitoring so you know when things slow down. Audit logging so you know what happened. The visibility that lets you operate confidently and respond to problems before users complain.

Infrastructure resilience. Database backups with tested restore procedures. Rollback capabilities for failed deployments. Graceful degradation under load. The preparations that let you recover from failures without losing data or trust.

Production Scenarios

Production mode scenarios are derived from your production standards. They describe what production-ready looks like for your specific feature:

Scenario: Login endpoint rate limits excessive attempts

Given I am on the login page

When I attempt to log in 10 times in one minute

Then my subsequent attempts are blocked for 5 minutes

And I see a message "Too many login attempts. Please try again later."

Scenario: Login audit logs capture authentication attempts

Given I am on the login page

When I successfully log in

Then an audit log entry records my user ID, timestamp, and IP address

Scenario: Login handles high concurrent load

Given 100 users attempt to log in simultaneously

Then all requests complete within 2 seconds

And no requests fail due to server overload

These scenarios test production concerns: security measures, compliance requirements, performance under load.

Production mode follows the same RED-GREEN loop. Run the production scenarios. They fail because the hardening doesn't exist yet. Implement the security measures, monitoring, and optimizations. Run again. Repeat until green.

The difference is scope. Production scenarios often test the system rather than individual functions. A security scenario might test the complete authentication flow. A performance scenario might test the system under simulated load. You may need additional tools for load testing and security scanning.

Production mode ends when all production scenarios pass. The feature works, handles errors gracefully, and is safe to operate at scale.

At this point, the feature is truly complete. It's been built incrementally (speed mode), hardened for reliability (stable mode), and prepared for real users (production mode). Each layer built on verified work from the previous layer.

The feature can be deployed to production with confidence. It meets your stated standards for security, performance, and compliance. Users can depend on it.

The three modes form a progression. Each builds on the previous:

Speed mode answers "does it work?" You implement all functionality assuming ideal conditions. Integration, required features, optional features. All success scenarios pass. The feature exists and functions correctly.

Stable mode answers "does it handle reality?" You add error handling, validation, and edge case coverage. All failure scenarios are handled gracefully. The feature is reliable and won't corrupt data or crash unexpectedly.

Production mode answers "is it ready for real users?" You add security hardening, performance optimization, and operational tooling. The feature meets your production standards and can be deployed safely.

Not every project needs all three modes. Internal projects stop after stable mode. External projects continue to production mode. The method tracks your project's state and adjusts expectations accordingly.

Each mode uses the same RED-GREEN loop. Write scenarios that describe what you want. Watch them fail. Implement until they pass. The only difference is what you're implementing: functionality, then resilience, then production readiness.

This progression prevents the fragile tower from Chapter 1. You're building layer by layer, and each layer is solid before the next one begins. You don't try to do everything at once. You don't get overwhelmed. You build incrementally, verify constantly, and end up with software that works.