Shipping Production Systems Inside Client Infrastructure
Teaches the practical workflows a forward deployed software engineer uses to deploy, integrate, and harden production-grade software within a customer's existing tech stack, security policies, and operational constraints.
Start by mapping the customer's existing tech stack, security policies, and deployment pipelines. Build integration adapters that conform to their patterns rather than imposing your own. Deploy through their CI/CD systems, pass their security reviews, run load tests against their traffic profiles, and establish a handoff runbook so their operations team can maintain the system independently after you leave.
Outcome: You can reliably deploy production software inside any customer environment, passing their security reviews, integrating with their existing systems, and handing off a maintainable system their team can operate without you.
Prerequisites
- Solid understanding of CI/CD pipelines and infrastructure-as-code tools
- Experience with at least two deployment environments (e.g., AWS, GCP, on-prem)
- Working knowledge of network security, IAM policies, and compliance basics (SOC 2, HIPAA awareness)
- Familiarity with the FDE Five-Lens Framework and mission-driven engagement scoping
- Ability to read and contribute to codebases you did not author
Overview
A forward deployed software engineer does not ship code to a clean staging server and call it done. The entire value proposition of forward deployed work is that you build and deploy inside the customer's real environment, with their real data, their real constraints, and their real operations team watching. This skill covers the end-to-end workflow from initial infrastructure discovery through production deployment and handoff. It sits at the core of the Forward Deployed Engineering Five-Lens Framework, where the "ship production outcomes" principle meets the messy reality of someone else's servers, someone else's security policies, and someone else's on-call rotation.
The specific problem this skill solves is the gap between "it works on my machine" and "it runs in the customer's production environment under their SLAs." Most software engineers have never had to deploy into an environment they do not control. They have never negotiated firewall rules with a client's security team, adapted their container images to pass a vulnerability scan they did not write, or figured out how to integrate with a legacy SOAP API that the customer's vendor abandoned three years ago. Forward deployed engineers face all of these challenges simultaneously, often under tight timelines and with incomplete documentation about the customer's own systems.
The concrete artifact this skill produces is a deployment package paired with a handoff runbook. The deployment package includes infrastructure-as-code definitions that conform to the customer's patterns, integration adapters for their existing systems, monitoring and alerting configurations wired into their observability stack, and security controls that pass their compliance requirements. The handoff runbook documents how to operate, update, and troubleshoot the system after the forward deployed engineer leaves. When done well, the customer's team can run the system as if they built it themselves. When done poorly, the system becomes an orphan that nobody understands and everyone is afraid to touch.
Success looks like a system running in the customer's production environment for 30 or more days after handoff with zero escalations back to the forward deployed engineering team. That is the bar. Everything in this skill is oriented toward clearing it.
How It Works
The mental model behind shipping inside client infrastructure is constraint-first design. Instead of building the ideal system and then cramming it into the customer's environment, you start by mapping every constraint the environment imposes and then design your system to fit within those boundaries. This is the inverse of how most product engineering works, and it is the core reason this skill is difficult.
Think of the customer's environment as a series of concentric rings. The outermost ring is their network topology and security perimeter: what can talk to what, what ports are open, what authentication is required. The next ring is their deployment infrastructure: how code gets from a repository to a running process. Inside that is their data layer: where data lives, what format it takes, who owns it, and what regulations govern it. The innermost ring is their operational practices: who gets paged, how incidents are handled, what monitoring tools they use. Your system must pass through every ring without breaking any of them.
The reason this approach works is that it forces you to discover blockers early. The most common failure mode in forward deployed engineering is building for weeks and then discovering at deployment time that the customer's network policies block your service-to-service calls, or that their container registry does not support the image format you used, or that their compliance team requires a two-week review for any new data store. By mapping constraints first, you surface these blockers in the first few days rather than the last few days.
The FDE Five-Lens Framework frames this as the intersection of the "ship production outcomes" lens and the "customer environment as learning loop" lens. You are not just building software. You are learning how this specific customer operates and adapting your engineering practices to match. Every constraint you discover is data that feeds back into your understanding of the customer and, eventually, into your core product's design.
A critical assumption to surface: you are a guest in their environment. You do not get root access because you ask nicely. You do not install tools they have not approved. You do not create shadow IT. Every action you take must be legible to the customer's operations and security teams, because after you leave they need to understand and maintain everything you built. This constraint shapes every technical decision, from choosing well-known open-source components over custom internal tools, to writing verbose comments in infrastructure code, to avoiding clever abstractions that save you time but confuse anyone who did not write them.
Where the model breaks down is in environments with no existing patterns at all. Some customers, especially early-stage startups, have no CI/CD pipeline, no infrastructure-as-code, and no security policy. In these cases, you are not just shipping your system, you are building their operational foundation. This requires a different approach: establishing minimal viable infrastructure patterns that the customer can adopt and extend, rather than conforming to patterns that do not exist yet.
Step-by-Step
Step 1: Run an Infrastructure Discovery Sprint
Before writing a single line of application code, spend 2-3 days mapping the customer's existing environment. Request architecture diagrams, but do not trust them fully since they are almost always out of date. Instead, interview their DevOps or platform engineering team with specific questions: What CI/CD system do they use? What container orchestration platform?
What cloud provider and region? What IAM model? What logging and monitoring stack? What compliance requirements apply?
Document everything in a structured format. Create a constraints matrix with columns for category (network, compute, storage, security, compliance, observability), the specific constraint, the impact on your design, and your proposed adaptation. This document becomes the foundation for every technical decision in the engagement.
Tip: Ask to see their most recent production deployment, not their documentation about how deployments should work. The gap between documented process and actual process often reveals the real constraints you will face.
Step 2: Establish a Deployment Pathway
Get your first artifact deployed into the customer's environment within the first week, even if it is a trivial health-check service. This validates the entire deployment pipeline end-to-end: code repository access, CI/CD configuration, container builds, registry pushes, orchestration manifests, network routing, and DNS. If any of these steps fail, you want to know now, not three weeks from now when you have a complete system ready to ship. Work with the customer's platform team to configure your project in their CI/CD system.
Mirror their existing pipeline patterns exactly. If they use Terraform, use Terraform. If they use Helm charts, use Helm charts. If they deploy with bash scripts and prayer, adapt to that too and improve it incrementally with their permission.
Tip: The health-check service should include one dependency on the customer's network, such as a call to an internal API or a database connection test. A service that only returns 200 OK proves nothing about your ability to integrate with their environment.
Step 3: Map and Build Integration Adapters
Identify every system your software needs to communicate with in the customer's environment. For each integration point, document the protocol (REST, gRPC, SOAP, message queue, file drop), authentication method, data format, rate limits, and SLA. Build integration adapters as isolated modules with clean interfaces so that the specifics of each customer's systems do not leak into your core application logic. Each adapter should include retry logic, circuit breakers, and structured logging so that when something fails at 3 AM, the on-call engineer can tell which integration broke and why.
Write integration tests that run against mock versions of the customer's systems, and then validate against their actual systems in a staging or dev environment before production.
Tip: The most dangerous integrations are the ones the customer describes as 'simple.' A 'simple REST API' often turns out to have undocumented rate limits, custom authentication headers, or response formats that vary by endpoint. Test every integration with real data before trusting it.
Step 4: Pass Security and Compliance Reviews
Submit your system for the customer's security review process as early as possible. Security reviews in enterprise environments can take days to weeks, and surprises here are the number one cause of missed deployment deadlines. Common requirements include container image vulnerability scanning (no critical or high CVEs), network policy definitions (explicit ingress and egress rules), secrets management through the customer's approved vault, encryption at rest and in transit, audit logging for all data access, and identity federation through their SSO provider. Address each requirement systematically.
Create a compliance checklist mapping each of their requirements to your implementation. If their security team has specific tools or scanning pipelines, integrate with them rather than asking for exceptions.
Tip: Start the security review conversation during the discovery sprint, not after you have finished building. Ask their security team to review your architecture proposal before you implement it. Rework after a failed security review is the most expensive kind of rework.
Step 5: Configure Observability Within Their Stack
Wire your system into the customer's existing monitoring, logging, and alerting infrastructure. Do not introduce a separate observability stack. If they use Datadog, export your metrics to Datadog. If they use Splunk for logs, ship your logs to Splunk.
If they use PagerDuty for alerting, create your alert definitions in PagerDuty. Define SLIs (service level indicators) for your system that match the customer's existing SLA framework. Typical SLIs include request latency at p50, p95, and p99, error rates, throughput, and dependency health. Set alert thresholds conservatively for the initial deployment period, you can tune them down later once you have baseline data.
Create a dashboard that gives the customer's operations team a single-pane view of your system's health without requiring them to learn new tools.
Tip: Include a 'dependency health' panel on your dashboard that shows the status of every integration point. When your system degrades, the first question the customer's ops team will ask is 'is it your system or ours?' The dependency health panel answers that question in seconds.
Step 6: Run Load and Failure Testing
Before going live, validate that your system handles the customer's actual traffic patterns and failure modes. Get real traffic data from the customer: peak request rates, typical payload sizes, seasonal patterns, and concurrent user counts. Run load tests that simulate these patterns, not generic benchmarks. Test failure scenarios that are specific to their environment: what happens when their SSO provider is slow, when their message queue backs up, when their database hits connection limits, when a network partition isolates your service from a dependency.
Document the results in a table with columns for scenario, expected behavior, actual behavior, and any remediation needed. Share results with the customer's engineering team so they understand the system's limits.
Tip: Always run load tests during a window the customer approves, and never against production data stores without explicit permission. A forward deployed engineer who accidentally takes down a customer's database during a load test will not be invited back.
Step 7: Execute a Staged Rollout
Deploy to production using the customer's change management process. This typically means submitting a change request, getting approval from their change advisory board or equivalent, and deploying during an approved maintenance window. Use a staged rollout strategy appropriate to their environment: canary deployments if they support traffic splitting, blue-green if they have the infrastructure, or a simple percentage-based rollout if those are not available. Monitor closely during the first hours.
Have rollback procedures documented and tested before you deploy. Stay available during the customer's business hours for the first week after deployment to handle any issues. Keep a deployment log that records exactly what was deployed, when, by whom, and what configuration was applied.
Tip: Never deploy on a Friday or before a holiday at the customer's location, regardless of how confident you are. Your confidence is not the variable that matters. The customer's comfort level is.
Step 8: Build and Deliver the Handoff Runbook
Create a comprehensive operations runbook that enables the customer's team to maintain the system without you. The runbook should include: system architecture overview with a current diagram, deployment procedures including how to push updates, configuration management including all environment variables and feature flags, troubleshooting guides for the five most likely failure scenarios, dependency documentation with contact information for upstream service owners, backup and recovery procedures, scaling procedures for handling traffic spikes, and a glossary of any domain-specific terms. Walk through the runbook with the customer's operations team in a live session. Have them perform at least one deployment and one simulated incident using the runbook while you observe.
Fix any gaps the exercise reveals.
Tip: Write the runbook as if the reader has never seen your code and is being paged at 2 AM. Every instruction should be copy-pasteable. Every decision point should have clear criteria. If a step requires judgment, explain what to look for and what each observation means.
Step 9: Establish a Post-Deployment Support Window
Define and communicate a clear support transition period, typically 2-4 weeks after production deployment. During this window, remain available for escalations but route all first-response through the customer's team using the handoff runbook. Track every escalation that comes to you and categorize it: was it a gap in the runbook, a genuine bug, or a knowledge gap on the customer's team? Update the runbook for each gap.
Fix bugs with urgency and deploy through the customer's normal pipeline. For knowledge gaps, schedule targeted training sessions. The support window ends when the customer's team handles a full incident cycle without escalating to you. Document the engagement's outcomes and feed learnings back to your product team, following the process described in transitioning field learnings into product features.
Tip: Set explicit criteria for ending the support window at the start of the engagement, not at the end. Something like '14 consecutive days with zero escalations' gives both sides a clear, objective target.
Examples
Example: Deploying a Real-Time Data Pipeline at a Financial Services Firm
A three-person forward deployed engineering team is embedded at a mid-size financial services company to deploy a real-time transaction monitoring pipeline. The customer runs on-premises Kubernetes clusters, uses Jenkins for CI/CD, stores secrets in HashiCorp Vault, and has SOC 2 and PCI-DSS compliance requirements. Their security team requires a two-week review for any new service that touches cardholder data. The engagement has a six-week timeline.
During the discovery sprint, the team mapped 14 specific constraints including network segmentation between PCI and non-PCI zones, a mandatory Vault integration for all secrets, Jenkins pipeline templates that all services must use, and a requirement that all container images pass Twistlock scans with zero critical CVEs. They deployed a health-check service through Jenkins to the non-PCI Kubernetes cluster by day three, revealing that the cluster's ingress controller required a custom annotation their Helm charts did not include. They submitted the architecture for security review on day four, two weeks before planned production deployment. The security team flagged that the pipeline's Kafka consumer needed to run inside the PCI zone, which required a different service account configuration.
Because they caught this early, they adapted the deployment manifests and retested within two days. Integration adapters were built for the customer's existing Oracle database (JDBC), their internal REST API for account lookups, and their Splunk instance for audit logging. Load testing simulated 50,000 transactions per minute based on the customer's peak Black Friday traffic data. The staged rollout processed shadow traffic for one week before switching to live.
The handoff runbook included 23 pages of operational procedures, and the customer's SRE team completed a simulated incident exercise on day 38. The system ran for 45 days post-handoff with one minor escalation that resulted in a runbook update.
Example: Integrating a Machine Learning Model into a Healthcare Platform
A solo forward deployed software engineer is deploying a diagnostic assist ML model into a regional hospital network's electronic health records system. The customer runs on AWS GovCloud, uses Terraform for infrastructure, has HIPAA BAA requirements, and their EHR vendor exposes a FHIR R4 API with strict rate limits of 100 requests per minute. The engagement timeline is four weeks.
The engineer spent the first two days mapping the FHIR API's actual behavior versus its documentation, discovering that certain resource types returned non-standard date formats and that the rate limit was enforced per IP, not per API key. The constraints matrix identified 11 items, with HIPAA's minimum necessary standard being the most impactful since it restricted which patient data fields the model could access. A health-check service was deployed through Terraform into GovCloud by day two, confirming that the engineer's IAM role had the correct permissions. The ML model was containerized with a thin FHIR adapter that handled rate limiting with a token bucket algorithm and translated non-standard date formats.
The security review was pre-cleared by submitting the Terraform plan and a data flow diagram showing that no PHI left the GovCloud VPC. Observability was wired into the customer's existing CloudWatch setup with custom metrics for model inference latency and FHIR API error rates. Load testing simulated the hospital's busiest clinic day with 2,400 patient encounters. The runbook focused heavily on model update procedures since new model versions would need to be deployed quarterly.
The customer's IT team completed the runbook walkthrough and a model update exercise before the engineer departed on day 26.
Example: Shipping an Analytics Dashboard for a Retail Chain
A two-person forward deployed team is deploying a real-time store analytics dashboard across 200 locations for a national retail chain. The customer uses Azure, deploys through Azure DevOps, authenticates through Okta, and stores data in Snowflake. Each store has its own network with varying bandwidth. The timeline is five weeks, and the customer's IT team has two people who will maintain the system.
Discovery revealed that 40 of the 200 stores had intermittent connectivity with sub-1 Mbps upload speeds, which meant the original architecture of streaming raw events would not work for those locations. The team adapted the design to include a lightweight edge agent that aggregated data locally and synced batched summaries every 15 minutes. The deployment pathway was validated by pushing the edge agent to five pilot stores through Azure DevOps on day four. Integration adapters were built for Snowflake (using their Python connector with connection pooling), Okta (SAML federation for SSO), and the customer's existing Power BI instance for executive reporting.
The security review focused on data residency since the retail chain operated in three countries with different data protection laws. The team pre-segmented the Snowflake schema by region and demonstrated that no cross-border data movement occurred. Load testing simulated all 200 stores reporting simultaneously during a holiday sales event. The staged rollout went to 20 stores for one week, then 80, then all 200 over three weeks.
The handoff runbook was written specifically for the customer's two-person IT team, avoiding assumptions about Kubernetes expertise since the team managed Azure App Services exclusively. Post-deployment support lasted three weeks. The team tracked four escalations, all of which were edge agent connectivity issues at low-bandwidth stores. Each escalation resulted in a runbook update with specific diagnostic commands for the store-level network.
Example: Embedding a Search Service into an Enterprise SaaS Platform
A forward deployed software engineer is deploying an advanced search service into a B2B SaaS company's multi-tenant platform. The customer runs on GCP, uses GitHub Actions for CI/CD, follows a trunk-based development workflow, and has 450 enterprise tenants with strict data isolation requirements. The engagement is three weeks with a target of zero-downtime migration from their existing Elasticsearch cluster.
The discovery sprint mapped the customer's multi-tenancy model, which used tenant-specific Elasticsearch indices with a routing layer that directed queries based on JWT claims. The key constraint was that the new search service had to maintain identical API contracts so that 450 tenants experienced no breaking changes. The engineer deployed a shadow instance of the new search service behind a feature flag on day two, processing duplicate queries from the existing routing layer without returning results to users. Integration adapters were built for the customer's event bus (Cloud Pub/Sub) to keep search indices synchronized, their authentication middleware for tenant isolation, and their internal admin API for index management.
The security review was expedited because the engineer used the customer's existing GCP project, service accounts, and VPC, adding no new network pathways. Load testing replayed 48 hours of production query logs against the shadow instance, comparing result quality and latency against the existing Elasticsearch cluster. Results showed p99 latency improvement from 340ms to 95ms with equivalent relevance scores. 1% for any batch.
The handoff runbook included tenant migration procedures, index rebuild steps, and relevance tuning workflows. The customer's platform team completed a simulated tenant migration exercise. Zero-downtime migration was achieved, and the system ran for 60 days post-handoff with no escalations.
Best Practices
Mirror the customer's existing patterns before introducing new ones. If they use Makefiles, write Makefiles. If they use YAML-based configs, use YAML. Every unfamiliar tool or pattern you introduce is a maintenance burden they inherit after you leave, and unfamiliar patterns are the first things that break when no one who understands them is around.
Treat the customer's security team as a collaborator, not a gatekeeper. Bring them into architectural discussions early, ask for their requirements document on day one, and frame your requests in terms of their risk model. Security teams that feel respected tend to fast-track reviews. Security teams that feel bypassed tend to block deployments indefinitely.
Version everything, including infrastructure code, configuration, runbooks, and architecture diagrams. Store it in the customer's version control system, not yours. If your engagement ends abruptly, the customer should have full access to every artifact you produced without needing to request it from your company.
Write integration adapters as thin, replaceable modules with well-defined interfaces. When the customer's upstream systems change, and they will, the adapter should be the only component that needs updating. If integration logic leaks into your core application, every upstream change becomes a core refactor.
Establish a shared communication channel with the customer's engineering and ops teams from day one. Daily async updates in their Slack, Teams, or whatever they use. Post what you shipped, what you are blocked on, and what you need from them. Silence from a forward deployed engineer causes anxiety. Overcommunication builds trust.
Run a 'pre-mortem' before production deployment. Gather the customer's engineering leads and ask: 'If this deployment fails, what is the most likely cause?' Document every answer and verify that your system handles each scenario. Pre-mortems surface risks that no individual would raise in a normal review because the question frame gives people permission to be pessimistic.
Keep a decision log throughout the engagement. For every significant technical choice, record what you decided, why, what alternatives you considered, and what trade-offs you accepted. This log is invaluable during handoff because it answers the question the customer's team will inevitably ask: 'Why did you do it this way instead of that way?'
Automate the deployment pipeline completely before going to production. A deployment that requires manual steps will be performed incorrectly within the first month after handoff. If you cannot automate a step due to the customer's constraints, document it with screenshot-level precision and test it with a team member who was not involved in building the system.
Common Mistakes
Building the system in your own environment and then attempting to migrate it to the customer's infrastructure at the end.
Correction
This is the most common and most expensive mistake. It feels productive because you ship features faster in a familiar environment, but you accumulate integration debt that compounds with every feature. By the time you attempt migration, you have dozens of implicit dependencies on your own infrastructure that do not exist in the customer's environment. Build inside their environment from day one, even if it is slower.
The health-check deployment in Step 2 exists specifically to force this discipline early.
Treating the customer's deployment process as optional or negotiable because it is 'too slow.'
Correction
Their deployment process exists for reasons you may not fully understand, often regulatory, compliance, or hard-won lessons from past incidents. Bypassing it, even with good intentions, creates risk the customer did not consent to and erodes trust with their operations team. If their process genuinely blocks you, propose specific improvements with clear rationale and let them decide. Never deploy through a side channel, even in dev environments, because patterns established in dev tend to persist into production.
Writing a minimal or nonexistent handoff runbook because the system 'is well-documented in the code.'
Correction
Code is documentation for developers. A runbook is documentation for operators. The person who gets paged at 2 AM may not have written code in years. They need step-by-step instructions with exact commands, expected outputs, and decision trees for common failure modes.
If you skip the runbook, the customer's first instinct when something breaks will be to call you, which means your engagement never truly ends and the customer never develops independence. Budget at least two full days for runbook creation and validation.
Introducing your preferred observability tools instead of integrating with the customer's existing stack.
Correction
This looks like a minor convenience choice but has outsized consequences. A second monitoring system means the customer's ops team has to check two dashboards, maintain two sets of alerts, and learn two query languages. Within weeks, one system gets neglected, and it is always the one you installed. Wire into their existing tools even if they are inferior.
The operational simplicity of a single observability stack outweighs the technical superiority of your preferred tools.
Assuming the customer's architecture diagrams and documentation are accurate and current.
Correction
In most organizations, documentation drifts from reality within months of being written. Forward deployed engineers who plan based on diagrams alone will encounter surprises during integration: services that have been decommissioned, databases that have been migrated, APIs that have changed ownership. Always validate documentation against the running environment. Ask to see actual traffic flows, inspect actual network policies, and test actual API endpoints.
Trust, but verify, and build in buffer time for the discrepancies you will inevitably discover.
Delaying the security review until the system is feature-complete.
Correction
Security reviews are not a rubber stamp. They frequently require architectural changes: different secret storage, different network topology, different authentication flows. Discovering these requirements after you have built the system means rework that can add weeks to the engagement. Submit your architecture for security review during the first week.
Get preliminary approval on your approach before investing engineering time. Treat the security review as a design input, not a post-build checkbox.
Other Skills in This Method
Scoping Mission-Driven FDE Engagements
How to define clear, outcome-bound missions for forward deployed engineering work so engagements stay focused on shipping production results instead of drifting into open-ended consulting.
Operating Autonomously in Customer Environments
Techniques for making independent technical decisions at the edge of customer deployments while maintaining alignment with your home organization's product strategy and engineering standards.
Measuring FDE Success by Business Outcomes
How to define, track, and report on business-outcome metrics rather than technical output metrics to prove the value of forward deployed engineering engagements.
Running Continuous Learning Loops from Field Deployments
How to systematically capture insights, failure patterns, and feature requests from customer environments and translate them into actionable product feedback for core engineering teams.
Building Interdisciplinary Forward Deployed Engineer Skills
How to cultivate the hybrid blend of software engineering, data analytics, solution architecture, and client communication skills required to operate effectively as a forward deployed engineer.
Transitioning Field Learnings into Core Product Features
How to evaluate which customer-specific solutions deserve generalization, write compelling internal proposals, and collaborate with product teams to fold field-proven patterns back into the platform.
Preparing for Forward Deployed Engineer Interviews
How to study for and excel in FDE interview processes, including system design in ambiguous customer scenarios, live coding under constraint, and client-communication role plays.
Frequently Asked Questions
How do I handle a customer environment where there is no CI/CD pipeline or infrastructure-as-code?
This happens more often than you would expect, especially with smaller customers or legacy enterprises. Establish a minimal viable deployment pipeline before building your application. Set up a simple CI pipeline that builds, tests, and packages your code, and a basic infrastructure-as-code setup for the components you need. Keep it simple enough that the customer can maintain it. Frame this work as part of the engagement scope during [mission scoping](/skills/scoping-mission-driven-engagements), not as a surprise addition.
How long should the infrastructure discovery sprint take?
Two to three days for a typical engagement. If the customer has a complex environment with multiple security zones, legacy systems, or multi-cloud infrastructure, budget up to five days. The discovery sprint should never exceed one week because diminishing returns set in quickly. You will discover additional constraints during integration work regardless of how thorough your discovery was. The goal is to catch the big blockers early, not to document every detail.
Should I ship the production system before or after completing the handoff runbook?
Start the runbook during development and complete it before the production deployment. Writing the runbook after deployment is a common mistake because you are under pressure to move on to the next engagement and details get lost. The deployment procedure itself should be documented in the runbook before you execute it, which forces you to make the process explicit and repeatable. You will update the runbook based on the actual deployment experience and the post-deployment support window.
How do I manage conflicting priorities between moving fast on features and passing the customer's security review?
Submit your architecture for security review during the first week and continue building features in parallel. Structure your work so that security-sensitive components, such as authentication, data storage, and network configuration, are built first and can be reviewed independently. If the security team requests changes, you want those changes to affect foundational components before you have built features on top of them. Treat security requirements as design constraints, not post-build patches.
What do I do when the customer's existing systems have undocumented behavior that breaks my integration?
This is normal and expected. Build integration adapters with extensive logging at the debug level so you can capture actual request and response payloads during development. When you discover undocumented behavior, document it in your adapter code with comments, add specific test cases for it, and share your findings with the customer's team. Often you will be the first person to formally document how their own systems actually behave. This documentation becomes part of your handoff artifacts and is one of the most valued contributions a forward deployed engineer makes.
How do I balance using the customer's tools versus introducing better alternatives?
Default to the customer's tools unless they create a genuine technical blocker for your deployment. 'Better' is subjective and often reflects your familiarity rather than objective superiority. If you must introduce a new tool, choose one the customer has already evaluated or that has strong community adoption in their ecosystem. Propose it with a clear rationale tied to their goals, not yours. Get buy-in from the team members who will maintain it after you leave. If they are not enthusiastic, find a way to use their existing tools instead.
Why does my deployment keep failing in the customer's environment when it works in staging?
The most common causes are environment-specific configuration differences that staging does not replicate: different network policies, different resource limits, different secret values, different DNS resolution, or different versions of shared dependencies. Audit the differences between staging and production systematically. Create a checklist of every environment-specific parameter and verify each one matches production requirements. Also check whether staging has the same traffic load, data volume, and concurrent connections as production, since many failures only manifest under realistic conditions.