by Bruno Campos

🤔 The Production Myth

There’s a dangerous misconception in the data world that once a model hits production, the work is complete. Product managers breathe a sigh of relief, stakeholders start planning their analysis, and data teams move on to the next priority. But here’s the uncomfortable truth: your data model isn’t ready for prime time just because it’s running in production.

After years as a data engineer across companies of various sizes and speeds, I’ve observed a consistent pattern that every data professional eventually understands: new data pipelines require a maturation period before they stabilise. In my personal experience through analysis, this usually lasts approximately 3 months. This isn’t a failure of planning or execution, it’s an inherent characteristic of how data models evolve in real-world environments.

Production deployment is not the finish line. It’s the starting gun for the real work of model refinement.

📊 The Maturation Pattern

Through analysis of git histories across multiple companies and data teams throughout my time as a professional, a clear pattern emerges: data models experience their heaviest modification activity in the first few months after production deployment. After this period, changes become infrequent and typically maintenance-focused rather than structural.

This is observable behaviour that manifests consistently across different company sizes, data complexity levels, tech stacks, and team experience levels. The pattern is so reliable that data teams should plan for it rather than being caught off guard by it.

🔄 The Complete Lifecycle

Understanding what actually happens after production deployment reveals why the maturation period is inevitable:

The traditional development cycle covers requirements, development, testing, and deployment. But then comes the hidden phase nobody talks about where real users interact with real data and discover what the development environment couldn’t reveal.

During this maturation period, edge cases surface from production scenarios, business requirements evolve based on actual insights, data quality issues emerge under load, and transformation logic gets refined. Only after this iterative refinement process do models reach true stability, where changes become infrequent and predictable.

🏃‍♂️ Accelerating the Process

The maturation period isn’t just a waiting game—it’s an active process that can be accelerated through strategic user engagement. Models that receive heavy usage during their initial period mature significantly faster than those with light adoption.

The most effective acceleration strategies include proactive user onboarding immediately after deployment, establishing dedicated feedback channels, implementing regular check-ins during the initial period, and monitoring usage analytics to identify problematic patterns early. But crucially, communicating to stakeholders that this period is normal and expected is vital to avoid frustration, confusion and delays in the maturing process.

To have the most accelerated maturation period possible, aim for:

• Clear communication: Set expectations with stakeholders that the model will evolve post-deployment.
• Heavy initial usage: The more users interact with the model early on, the faster issues are uncovered and resolved.
• Proactive feedback loops: Regularly solicit user feedback to identify pain points and areas for improvement.
• Dedicated support: Provide resources to help users navigate the new model and help fix issues quickly.
• A clear indication of model maturity: Use a status system to indicate whether the model is still maturing or has reached stability.

🚦 Managing Expectations

Smart data teams implement status systems to communicate model maturity clearly. Rather than binary “in production” labelling, models should carry maturation status:

Production (Maturing) means the model is live and functional but expect changes. Feedback is actively sought, and it’s not recommended for mission-critical decisions yet.

Production (Stable) indicates the model has reached stable change frequency, behaviour is predictable and well-understood, and it’s suitable for automation and critical business processes.

📏 Measuring Your Maturation Period

To understand your organisation’s typical maturation timeline, define model maturity as reaching stable change frequency (once per month or less), then track file modification patterns through git analysis.

A simple approach: track multiple models from initial production deployment, measure time until stable change frequency is reached, and calculate the median to avoid outlier bias. Use this data to plan resource allocation, set stakeholder expectations, and schedule user training for your organisation.

# Track file modification frequency
git log --name-only --pretty=format: --since="production_date" \
  models/your_model.sql | grep -v "^$" | sort | uniq -c

💪 Embracing the Reality

Data models aren’t like software releases: Data Models are like gardens that need tending after planting.

The most expensive bugs often are the ones discovered by users, and generic data quality tests fail to pick up. A model that never changes after production either isn’t being used or isn’t being used correctly.

Understanding and planning for the maturation lifecycle transforms how we approach data projects. Instead of viewing post-production changes as failures or technical debt, we can embrace them as a natural and valuable part of the development process.

The goal isn’t to eliminate the maturation period, it’s to manage it effectively, accelerate it where possible, and set appropriate expectations throughout the organisation. Every mature, reliable data model you depend on today went through this exact same process.

The next time someone asks if your model is “done” because it’s in production, the answer is clear: “It’s live, it’s functional, and now the real work begins.”

Peace and Love.