GIIP FDE Box customer case study

It Works in Dev, but Not in Staging — The Production Problem AI Coding Alone Didn't Solve

A customer built a real, paid web service on GIIP FDE Box, wiring together Google Drive, Stripe, Claude and an AI chatbot. It worked fine in Dev — then broke the moment it was deployed to Staging.

AI can write code fast. But "the code works" and "the service keeps running for paying customers" are different problems. This case shows exactly where that gap shows up.

A live, paying production service — not a demo

Background — this is not a demo

The customer uses GIIP FDE Box not as a coding assistant on the side, but as the platform for building an actual business.

Using GIIP FDE Box, they built a web service from zero and connected it to several external services:

Google Drive integration
Stripe payment integration
Data analysis powered by Claude
An AI chatbot
Other external APIs and authentication services
End-user billing

This matters: it is not a one-off demo. It is a commercial web service that serves real end users and charges them, generating revenue — built and operated on GIIP FDE Box.

The incident

The service worked correctly in the Development environment.

After merging and deploying the same changes to Staging, some of the external service integrations stopped responding correctly. The customer asked GIIP for help diagnosing the cause.

It would be inaccurate to simply say "it broke in Staging, and GIIP fixed it." Here is what was actually going on, explained for a non-developer audience too.

Root cause — not the code, the environment

Connecting external services generally requires values like these:

Example values a typical integration needs

GOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRETSTRIPE_SECRET_KEYCLAUDE_API_KEYDATABASE_URLCALLBACK_URLWEBHOOK_SECRET

In development, these settings and secrets are commonly kept in a file such as `.env`. For security reasons, `.env` is usually listed in `.gitignore` and never committed to the Git repository.

So when only the code is merged and deployed from Dev to Staging, the code moves — but the Environment Configuration and Secrets it needs to run may not move with it.

DEV — Code + Environment/Secrets → works correctly

Git merge / deploy → only the code moves

STAGING — Code + Environment/Secrets missing or mismatched → external service connections fail

The actual incident was never confirmed to be 100% caused by a missing .env file. What happened is that GIIP first suspected the Dev/Staging environment difference and the Secret/Configuration management structure — and changing how environment-dependent settings were managed is what resolved the problem.

The structure GIIP proposed

Before

Application

↓

Local / server .env

↓

Google / Stripe / Claude / external APIs

Because a human has to create `.env` by hand for every environment, this structure is prone to configuration drift between Dev, Staging and Production.

After

GIIP Management UI

↓

Central Configuration Management

↓

Secret / Credential Storage

↓

DEV / STAGING / PRODUCTION

↓

Google / Stripe / Claude / external APIs

Principles applied

Encrypted storage
A structure that can use a Secret Manager / Vault / KMS
Permission separation per environment
Secret values are never re-displayed in full on screen
Access logging
Restricted access to production secrets
A structure that supports secret rotation

The customer now registers the settings they need in a management UI, and each environment picks up the right values from there. The point is not "the .env contents were put into a database" — it is that Configuration Management and Secret Management were separated from the application code.

The story, step by step

① AI built the service
Google Drive, Stripe, Claude, an AI chatbot, a database, a web application — using GIIP FDE Box, the customer combined all of it into an actual paid service.
② It worked in Dev
Every integration behaved as expected in the development environment.
③ It broke when deployed to Staging
The moment the same code was rolled out to Staging, some of the external integrations stopped responding.
④ Having AI keep editing the code alone may not fix it
The problem may not be the code at all — it can live in the environment, configuration, secrets, or deployment architecture.
⑤ GIIP's experience-based support changed the framing
The investigation started from a different question: "Is the code really wrong — or is the Dev and Staging runtime environment actually the same?"
⑥ The structure itself was improved
The approach moved away from copying files per environment by hand, toward central Configuration/Secret Management.
⑦ Staging was fixed, and the same risk in Production was removed in advance
The issue that surfaced in Staging was removed structurally, before it could recur in Production.

The customer's feedback, in substance, was that GIIP FDE Box matters because a supporter who understands the system at depth is part of it — and that for someone without infrastructure or development experience building a service with AI, it is hard to find a service that also offers this kind of structural advice.

Actual customer feedback (paraphrased)

The following is a paraphrase of actual customer feedback. Because the exact wording has not been verified word-for-word, it is presented as a paraphrased summary rather than a verbatim quotation.

How this connects to "30 years of experience"

AI can perform tasks like these very quickly:

Code generationAPI integrationUI developmentDatabase implementationTestingRefactoring

But real production services also run into problems like these:

Environment differenceSecret managementIAMNetworkDeploymentDatabasePerformanceMonitoringSecurityScalingFailure recovery

The ability to generate code alone does not resolve that second list. What GIIP calls 30 years of experience applies specifically to that domain.

This case surfaced exactly that class of problem. GIIP FDE Box combines AI's execution speed with engineering experience that has actually operated in this domain.

How this differs from a typical AI coding agent

AI Coding Agent	GIIP FDE Box
Writing code	Writing code
Building features	Building features
Connecting APIs	Connecting APIs
Testing	Testing
—	Dev/Staging/Production operations
—	Infrastructure
—	Configuration management
—	Secret management
—	Monitoring
—	Performance
—	Production troubleshooting
—	Experience-based support

The goal isn't to finish the code. The goal is to keep the service running.

Frequently asked questions

Why does an application work in development but fail in staging?

Even with identical code, the Environment Configuration it needs to run — environment variables, secrets, callback URLs and the like — may not be identical between Dev and Staging. Settings kept outside Git, such as `.env`, do not move automatically when you merge or deploy code. It is usually more productive to suspect an environment difference before assuming the code itself changed.

Should `.env` files be committed to Git?

Generally, no. `.env` files often contain secrets such as API keys and database credentials, so committing them raises the risk of exposure. Most projects exclude them via `.gitignore` — which then raises a separate question: how do you keep secrets in sync across environments instead?

How should API keys be managed across Dev, Staging and Production?

Rather than a person copying files by hand into each environment, it is preferable to distribute the right values per environment through a central configuration/secret management layer — with encrypted storage, per-environment permission separation, access logging, and support for secret rotation as baseline principles.

Can AI coding agents manage production infrastructure?

AI coding agents are strong at accelerating development work — writing code, building features, connecting APIs, testing. Operational concerns such as environment differences across Dev/Staging/Production, secret management, monitoring and incident response are not always fully covered by code-generation ability alone.

What is the difference between an AI coding agent and GIIP FDE Box?

An AI coding agent primarily handles writing code, building features, connecting APIs and testing. GIIP FDE Box adds Dev/Staging/Production operations, infrastructure, configuration and secret management, monitoring, and production troubleshooting, backed by support grounded in 30 years of production experience.

Why does production experience matter when developing with AI?

AI dramatically increases how fast code can be generated, but operational problems — environment differences, IAM, networking, deployment, scaling, failure recovery — require a different kind of judgment than code generation. Telling apart a case where the real cause is environment design rather than the code, as in this case, is where hands-on production experience helps.

A dedicated knowledge-base article on "why an application works in development but fails in staging" is a candidate for future publication, but does not exist yet as of this page. It will be cross-linked from this page once published.

Building a service with AI? Not sure it will hold up in production?

GIIP FDE Box supports more than development — Dev/Staging/Production, infrastructure, databases, monitoring and incident response.

Talk to us about GIIP FDE Box See pricing

contact@littleworld.net