Post-Deployment Support at Normaly: What It Is (and What It Isn’t)
Purpose of Post-Deployment Support
Post-deployment support at Normaly exists for stabilization, not reinvention.
Every Normaly service includes a two-week post-deployment support period because real systems operate in real conditions. Once a configuration or integration goes live, edge cases may surface, users may encounter unexpected behavior, or data patterns may differ slightly from test scenarios.
Support exists to address those realities without expanding scope.
Our goal during support is simple:
Fix bugs
Stabilize delivery
Ensure the system behaves as designed
Not to redesign, rebuild, or introduce new functionality.
What Normaly Support Covers
During post-deployment support, we focus on:
Fixing defects directly related to delivered work
Addressing issues caused by edge cases not visible during testing
Correcting logic that does not behave as intended post-go-live
Making minor adjustments to ensure the original solution functions correctly in production
Support is about making the system quiet, not adding new noise.
What Support Is Not
To keep systems stable and predictable, support does not include:
New feature requests
Major workflow changes
New integrations or new flows
Re-architecting previously delivered solutions
Changes driven by new business strategy or requirements
Those items require a separate scoped engagement.
This boundary is intentional. It protects system integrity and avoids unplanned complexity.
Why We Limit Scope During Support
From a CTO’s perspective, uncontrolled post-go-live changes are one of the fastest ways systems degrade.
Unscoped changes:
Introduce regressions
Break tested logic
Create undocumented behavior
Increase long-term maintenance cost
Normaly’s support model prevents this by keeping changes deliberate, traceable, and aligned to the original implementation.
The Outcome You Should Expect
At the end of post-deployment support, you should have:
A stable, predictable system
Known issues resolved
Clear understanding of how the system behaves in production
Confidence that further changes require intentional planning
Support ends when the system is quiet.
