Forem: codecraft

Hot take: most "AI-powered" products are just regular products with an API call in the middle

codecraft — Fri, 17 Apr 2026 14:09:53 +0000

That's not a diss. It's where most teams start. But there's a real gap between wiring up an LLM and actually building a system that learns from its environment, adapts to changing conditions, and doesn't quietly rot the moment your data drifts.

This is where product engineering starts to matter, especially when AI systems move from experimentation to production.

AI-driven product engineering is a different discipline. It's not about the model you pick. It's about how you design the feedback loops around it.

A few things I keep seeing separate the teams shipping intelligent systems that hold up in production:

Observability is non-negotiable. If you can't see how your model is influencing decisions in real time, you can't debug it, you can't improve it, and you definitely can't explain it to a stakeholder at 9 am when something breaks. Strong product engineering practices make this visibility a built-in capability rather than an afterthought.

Adaptability has to be designed in, not added later. User behaviour changes. Business logic changes. Retraining pipelines, feedback mechanisms, and fallback paths need to be first-class concerns from day one, not things you bolt on after your model goes stale.

Sustainability means more than green compute. It means building systems your team can actually maintain six months from now. That means clean abstractions, documented decision boundaries, and governance that doesn't make engineers want to quit.

The products that compound in value over time aren't the ones with the most sophisticated models. They're the ones built on disciplined engineering around the model.

Curious what patterns others are using to keep AI systems adaptive in production. What's working for your team?

Your AI Pilot worked. So why is ROI still MIA?

codecraft — Thu, 09 Apr 2026 16:39:30 +0000

The gap nobody talks about

Most enterprise AI pilots succeed. The demo is clean, the sponsor is excited, and the productivity numbers look promising. Then it goes to scale and quietly falls apart.

This is the pattern playing out across almost every large organization right now. Adoption is up, investment is up, and sustained ROI is still concentrated in a frustratingly small group of companies.

The models aren't the problem. The execution is.

When AI moves from pilot to production, a few things tend to go wrong fast: nobody owns the outcomes, measurement gets stuck tracking adoption instead of business impact, and governance gets bolted on after the fact when it's already too late to matter.

Complexity scales. Accountability diffuses. ROI flatlines, especially when enterprise AI solutions are deployed without clear ownership or operational alignment.

What separates the companies actually compounding value

It's not the fanciest models or the biggest budgets. It's execution discipline, clear ownership, governance embedded into the workflow from day one, and performance measurement tied to actual business outcomes rather than usage metrics.

AI amplifies what's already there. Strong execution culture gets stronger. Fragmented ops get more fragmented, which is why scaling enterprise AI solutions requires operating model changes, not just better models.

The question for most engineering and product teams right now isn't whether AI works. That's settled. The question is whether your operating model is built to capture the value at scale.

Pilots are easy. Operationalizing is the hard part. That's where the real work is.

Hybrid Work isn’t broken. Your system is.

codecraft — Wed, 01 Apr 2026 15:37:41 +0000

Hybrid work didn’t fail. Bad architecture did.

Most teams didn’t struggle with where people worked, but how the work actually moved.

We over-indexed on tools and underinvested in systems.

A few Video Calls + Chat do not make a distributed enterprise.

Here’s the shift I’m seeing:

Collaboration is no longer a feature layer
It’s an operating system

The real unlock isn’t adding more remote collaboration tools, but
designing how decisions, workflows, and context flow through them.

Because in a hybrid world:

Meetings don’t drive momentum. Systems do.

The teams getting this right design their systems in layers across hybrid work environments:

Collaboration(communication)
Operations(workflow)
Intelligence(insight)

Miss one → friction
Align all three → scale

And that’s where most stacks break.

We keep asking: “Which tools should we use?”
Instead, we should ask: “How should work behave?”

Because in the end, piling on more tools doesn’t fix fragmentation but can rather amplify it. What actually moves the needle is a cohesive system where communication, workflows, and insights are intentionally designed to work together.

That’s the difference between teams that are just connected and the ones that are truly operating as a distributed enterprise.

Your AI Transformation Strategy isn’t Failing. Your Execution Model is.

codecraft — Wed, 25 Mar 2026 16:02:34 +0000

Most enterprises today have an AI transformation strategy.

On paper, it looks solid:

Modern data platforms
AI pilots in production
Cloud-native architecture
Agile teams everywhere

And yet, value realization is slower than expected. Not because the strategy is wrong, but because execution can’t keep up.

The Hidden Bottleneck

Traditional delivery models were never designed for AI-driven transformation.

They rely on:

Linear workflows
Role-based ownership
Manual coordination
Lagging visibility

That might work for predictable systems. But AI transformation introduces:

Cross-functional dependencies
Continuous iteration
High uncertainty
Rapid feedback loops

Execution becomes complex. Coordination becomes heavy. And progress quietly slows down.

Why scaling makes it Worse

The default response to slow delivery is simple: Add more people.

But more people don’t fix execution. They increase coordination overhead. More handoffs. More meetings. More alignment layers.
You don’t get speed. You get friction at scale.

Rethinking Execution: From Teams to PODs

A more effective approach is to organize around outcomes, not roles. Delivery PODs are:

Small, cross-functional units
Aligned to a single business objective
Responsible end-to-end

This removes handoffs and clarifies ownership. But structure alone, however, isn’t enough.

The Real Shift: Intelligence inside Execution

To truly scale an AI transformation strategy, execution itself needs to evolve. AI must move beyond tools and dashboards into the delivery lifecycle, and when intelligence is embedded into execution:

Planning becomes signal-driven, not assumption-based
Risks are identified early, not reported late
Quality improves through continuous validation
Decisions happen in real time

Execution shifts from reactive to predictive, and what this ultimately changes is how execution itself is perceived and managed. Teams move from tracking status updates to operating on real-time signals, from reacting to delays to anticipating them, and from scaling effort to scaling true execution capability.

The reality is, most AI transformation strategies don’t fail in design; they fail in delivery. If execution still relies on manual reporting, reactive governance, and coordination-heavy workflows, the constraint isn’t technology; it’s the way work gets done. AI transformation, therefore, isn’t just about building smarter systems, but about adopting smarter execution models, because while strategy defines direction, execution determines whether you ever get there.

Stop scaling the Wrong Thing

codecraft — Thu, 19 Mar 2026 14:59:34 +0000

At a certain scale, your data stops flowing. It queues.

Requests pile up. Dashboards lag behind. And by the time insights arrive, the decision has already been made somewhere else with a spreadsheet, a guess, or instinct.

Centralization has a Ceiling

The centralized model made sense when data was scarce and teams were small. One warehouse, one team, one source of truth. Clean and controllable. Then organizations scaled. Business units multiplied. And that single team, on which everyone depends, became the most overloaded and under-resourced group in the company.

Data lakes were supposed to fix this. Instead, they mostly created swamps: enormous, ungoverned repositories that nobody could navigate with confidence. The problem was never the architecture. It was still the model.

What Data Mesh actually is

Data Mesh doesn't replace your infrastructure. It replaces your assumptions.

The core idea is to stop treating data like a utility flowing through a central plant, and start treating it like a product owned and maintained by the teams who actually understand it. This shift toward an organizational data mesh model means domain teams own their data end to end. Data is built to be reliable, documented, and discoverable. Teams can then publish and consume without waiting in a queue, and governance stays consistent without everything funneling through a single authority.

The shift sounds structural. It definitely is. But the deeper shift is cultural: accountability moves to where the knowledge already lives.

Why it Works

When contextual knowledge is paired with ownership, quality improves, delivery speeds up, and the organization stops being held hostage by one team's capacity.

Where it Falls Apart

Organizations that treat Data Mesh like a technology rollout usually end up worse off than before. It's basically distributed chaos instead of centralized chaos.

The real obstacles are organizational: Teams that don't want ownership they weren't hired for, skill gaps, and inconsistent standards that quietly erode trust across domains. Without strong foundations, you don't build a mesh. You build fragmentation with better branding.

Successful teams start small, one or two high-value domains, and build the self-serve platform before demanding self-sufficiency. They define data contracts early and enforce them consistently. They let the mesh grow from demonstrated success, not from a reorganization slide.

The Real Question

If your data strategy still requires a central team to be the last mile, that's not a tooling gap but a structural dependency you've normalized.

Data Mesh challenges that dependency directly. For the ones ready to make the organizational investment, not just the technical one, it's one of the few approaches that actually gets better as you grow.

How Temporal.io helps orchestrate complex Microservices Workflows with reliability and scale

codecraft — Tue, 20 Jan 2026 15:08:13 +0000

Microservices make it easier to scale development, but they also make workflows harder to manage. As systems grow complex in nature, even simple business processes start spanning multiple services, databases, and external dependencies. Failures become inevitable, and coordinating retries, timeouts, and state consistency quickly turns into a major engineering challenge.

As organizations move from a handful of services to dozens or hundreds, coordination logic starts to spread across the system. What begins as a simple sequence of calls often evolves into long-running processes that must survive partial failures, restarts, and unpredictable delays.

Why workflow orchestration becomes a problem at scale

In many distributed systems, workflows are stitched together using events, queues, or direct service calls. While this works initially, complexity increases as soon as workflows become long-running or failure-prone.

Without dedicated workflow orchestration tools, teams often end up embedding coordination logic directly into services. This leads to tightly coupled implementations that are difficult to reason about, test, and evolve.

What Temporal.io changes in this model

Temporal.io approaches this problem by treating workflows as durable code. Instead of relying on external coordination logic or brittle state machines, workflows are defined explicitly and executed by the Temporal platform.

Each workflow has a well-defined execution history that is persisted automatically. If a service crashes or a dependency becomes unavailable, execution does not need to be reconstructed manually.

Key characteristics include:

Workflow state is persisted automatically
Execution resumes from the last known state after failures
Retries, timers, and error handling are handled by the platform

This shifts the responsibility for reliability away from individual services and into a purpose-built workflow engine.

Reliable workflow orchestration by design

The real value of Temporal becomes visible when things go wrong. Services crash, networks fail, and external systems slow down or time out. In a typical microservices setup, these scenarios require defensive coding everywhere.

With Temporal:

Workflows do not lose state when services restart
Failed steps can be retried safely without duplicating work
Long-running workflows remain consistent over hours or days

Instead of building custom recovery logic repeatedly, teams gain reliable workflow orchestration as a built-in capability.

How does this help?

By centralizing orchestration logic, teams establish clearer boundaries between business processes and service responsibilities.

Common benefits include:

Cleaner service code focused on single responsibilities
Easier debugging through complete workflow execution history
Better testability using deterministic workflow replay

Rather than coordinating behavior through implicit contracts and event chains, workflows become explicit, durable, and easier to reason about.

When Temporal.io is a good fit

Temporal is especially useful when:

Workflows span multiple services or external systems
Processes are long-running or stateful
Failure handling and retries are becoming complex
Consistency matters more than raw throughput

In these scenarios, general-purpose tooling often falls short, and specialized orchestration becomes essential to system reliability.

As microservices ecosystems grow, coordination becomes as important as computation. Reliable workflow orchestration is no longer optional for systems that must operate at scale and recover gracefully from failure.

Temporal.io provides a practical way to model workflows as durable executions, helping teams move reliability concerns out of application code and into the platform itself.

Stop treating MongoDB like just another Database

codecraft — Thu, 15 Jan 2026 15:34:48 +0000

Let’s be honest for a second.

Most of us first hear about MongoDB and think, “Cool, NoSQL. Flexible. JSON-ish. Got it.” And then we start using it, and suddenly we are not so sure we actually got it.

MongoDB looks simple on the surface, but it behaves very differently from traditional databases. Once you understand that difference, things start to make sense. Until then, it can feel a bit confusing.

So let’s talk about MongoDB the way developers really experience it, including what MongoDB is used for and why the whole MongoDB vs SQL debate even exists.

MongoDB is not trying to be SQL

This is where most confusion starts.

MongoDB is not here to replace MySQL or PostgreSQL. It is not trying to play by the same rules. It exists to solve a different set of problems.

When people argue about MongoDB vs. SQL, what they are really comparing are two different approaches to thinking about data. SQL databases focus on structure, relationships, and strict schemas. MongoDB focuses on flexibility, speed of change, and document-based storage.

Neither is “better” by default. They are just built for different situations.

Documents are the Whole Point

In MongoDB, everything revolves around documents.

Each document is a flexible collection of fields and values, and not every document has to look the same. One document can have extra fields, another can skip them entirely, and MongoDB is completely fine with that. This is usually the moment when developers start to understand what MongoDB is used for in real projects.

It works especially well when:

Your data structure changes often
Different users have different types of data
You are still figuring things out as you build
Instead of fighting the database, you let the data evolve naturally.

The Data types you actually care about

MongoDB supports a wide range of data types, but in practice, you deal with a small core set most of the time.

Text, numbers, true or false flags, dates, lists of values, nested objects, and unique IDs. That’s really it.

The important part is not the types themselves, but how easily you can combine them in one place without rigid rules getting in the way.

So, What is MongoDB used for in the Real World?

This is the question most developers actually care about.

MongoDB shines when structure becomes a limitation instead of a benefit. It is commonly used for:

Applications where requirements keep changing
User profiles with different attributes
Product catalogs with inconsistent fields
Content-heavy platforms
Event and activity tracking

In these cases, forcing everything into fixed tables can slow development down. MongoDB removes a lot of that friction.

MongoDB vs SQL: Why the Debate Never Ends

The MongoDB vs SQL discussion usually comes down to trade-offs.

SQL databases are great when:

Relationships are complex
Data integrity must be strict
Structure rarely changes

MongoDB works better when:

Flexibility matters
Speed of iteration is important
Data does not fit neatly into tables

Choosing between them is less about trends and more about understanding your problem.

It’s Not Magic, and That’s Okay

MongoDB is powerful, but it is not the right tool for everything.

If your application relies heavily on complex joins, strict transactional behavior, or rigid schemas, MongoDB might feel uncomfortable. And that does not mean MongoDB is bad. It just means the tool does not match the job. Good developers choose tools based on context, not hype.

The Big Takeaway

MongoDB works best when flexibility is a feature, not a risk.

It allows developers to focus on building and evolving products instead of constantly adjusting schemas. That is why it fits so well with modern application development.

But like any tool, it works best when you understand both its strengths and its limits. MongoDB is not just another database you swap in for SQL.

Once you stop treating it like one and start using it for what it is good at, it becomes far more enjoyable to work with. And honestly, far more forgiving.

If you are building something that needs to grow and change quickly, MongoDB is worth serious consideration.

When Labels are Missing, Validation becomes the Real Problem

codecraft — Fri, 09 Jan 2026 13:28:11 +0000

Most teams worry about training when labels are missing. In practice, training is often the easier part.

The real challenge shows up later. How do you decide whether a model is good enough to ship when accuracy and precision cannot be measured? How do you compare the two models? This situation is increasingly common in production systems that rely on large volumes of unlabeled data.

Why Standard Metrics Stop Working

Traditional validation pipelines assume one thing above all else. Someone has labeled the data.

In live systems, labels arrive late or not at all. Data distributions change faster than validation datasets can be updated. By the time labels exist, the model may already be outdated.

This creates a blind spot where models appear to function correctly, even as their real-world performance drifts.

A Shift in How Validation is Approached

At this point, the problem shifts from training to machine learning model validation under uncertainty. Instead of asking how accurate a model is, some teams ask a different question. Does this model behave like models that generalize well?

That shift opens the door to meta learning approaches. Rather than validating against labels, the system learns from prior tasks what good generalization looks like and uses those patterns to evaluate models running on unlabeled data.

Validation becomes an inference problem rather than a direct measurement.

What this Unlocks in Real-World Scenarios

Models can be compared before labels exist. Weak experiments can be stopped early. Validation no longer blocks iteration just because annotation pipelines lag behind.

For developers, this shortens feedback loops and reduces guesswork when labeled data is scarce.

As machine learning systems move closer to real-world constraints, validation has to adapt. Labels remain useful, but they cannot be the only signal.

By rethinking machine learning model validation and incorporating meta learning approaches, teams gain a way to reason about model quality even when validation is missing.

Software Blueprints: Why they matter and how they drive better builds

codecraft — Fri, 02 Jan 2026 16:11:40 +0000

In software development, building without a plan is one of the fastest ways to create rework, delays, and fragile systems. You might ship something quickly, but scaling, maintaining, or evolving it becomes painful.

That’s where a software blueprint plays a critical role in the software development lifecycle. It acts as the foundation that connects business intent with technical execution. Before code is written, a blueprint defines how the system should work, how components interact, and how decisions today affect the product tomorrow.

What is a Software Blueprint?

A software blueprint is a structured, high-level plan that guides development from concept to release. It brings clarity to what is being built and how it should be built, ensuring teams are aligned before implementation begins.

Blueprints typically cover architecture, workflows, integrations, and technical constraints. Instead of relying on assumptions or traditional knowledge, teams use the blueprint as a shared reference throughout the software development lifecycle, from design and development to testing and deployment.

Why Blueprints matter in Modern Software Development ?

As systems grow more complex, especially in cloud-native and distributed environments, skipping structured planning creates long-term risk.

A well-defined blueprint helps teams:

Align early and often
Developers, product managers, and QA teams work from the same understanding, reducing miscommunication and rework.

Make better technical decisions
Frameworks, APIs, data models, and integrations are chosen intentionally, not reactively.

Support agile execution
In agile software development, blueprints do not slow teams down. They provide guardrails that allow teams to move faster within sprints, with fewer surprises and less churn.

Reduce technical debt
By thinking through dependencies and scalability upfront, teams avoid patchwork fixes later in the lifecycle.

What a Strong Software Blueprint includes

While formats vary, effective blueprints usually include:

Business goals and use cases
Clear alignment between user needs and technical outcomes.

Architecture overview
System diagrams that show how services, modules, and data flows connect.

Requirements and technical specs
Functional requirements, non-functional requirements, and integration details.

Development Roadmap
Phases, milestones, and dependencies are mapped across the software development lifecycle.

Roles and Ownership
Clear accountability across engineering, design, and testing teams.

Blueprints and agile Software Development

There’s a common misconception that planning and agile software development are at odds. In reality, blueprints and agile practices work best together.

A blueprint does not lock teams into rigid decisions. Instead, it provides a flexible structure that supports iteration. Teams can adapt features sprint by sprint while staying aligned to the overall architecture and long-term vision. This balance helps agile teams move quickly without compromising stability or scalability.

From Blueprint to Code

In practice, a blueprint turns abstract ideas into actionable development work. It reduces ambiguity, speeds up onboarding for new engineers, and provides a reference point when trade-offs need to be made.

For distributed or cross-functional teams, blueprints become a single source of truth that keeps execution consistent across environments and releases.

Why Blueprints are worth the effort

Skipping the blueprint phase might feel faster initially, but it often leads to delays, refactoring, and growing technical debt. Investing time upfront pays off across the entire software development lifecycle, from cleaner implementations to more predictable releases.

For teams committed to building scalable, maintainable software, blueprints are not optional. They are a strategic advantage.

Federated Machine Learning and the Future of Data Privacy

codecraft — Fri, 26 Dec 2025 13:43:25 +0000

Machine learning systems today are powered by data, and most traditional models rely on centralizing it in large servers where training happens. While this approach has driven major breakthroughs, it also introduces serious privacy risks. Sensitive data moves across networks, gets stored in centralized systems, and becomes vulnerable to misuse, breaches, or regulatory violations.

As users grow more aware of how their data is handled and as data privacy regulations become stricter, this centralized model is beginning to falter. Developers and organizations are now being forced to ask a hard question. Can we still build intelligent systems without collecting raw user data?

And Federated machine learning seems to offer a promising answer.

How it Works

Learning evolves with training. Instead of moving data to a central model, the model is sent to where the data already exists. Training happens locally on devices such as mobile phones, edge servers, or on-premise systems. Once training is complete, only model updates are sent back to a central coordinator.

These updates are aggregated to improve the global model. At no point does raw user data leave its original location. This shift alone significantly reduces privacy risk and makes data misuse far harder.

From a developer's perspective, this approach aligns well with the idea of data minimization. You only move what is absolutely necessary. In this case, that means learned parameters instead of sensitive records.

Why Privacy is the Real Driver

Privacy is not just a legal concern anymore. It is a trust issue.

Users are increasingly cautious about where their data goes and how it is used. Industries such as healthcare, finance, and telecommunications deal with data that cannot simply be centralized without major compliance overhead. Federated machine learning allows these sectors to extract value from data while respecting privacy boundaries.

This is especially important in regions with strict data privacy regulations. Keeping data local simplifies compliance and reduces exposure. Instead of building complex anonymization pipelines, federated learning makes privacy part of the system design.

Not theoretical and already in production.

One of the most well-known examples is Google’s keyboard prediction system. User typing data never leaves the device. The model improves through local training and shared updates. This allows better predictions without collecting personal text data.

Similar patterns are emerging in healthcare diagnostics, fraud detection, and systems where data sensitivity is high. As edge computing becomes more common, this model will only become easier to adopt.

Challenges Developers should know

It is not a free win.

Training across distributed devices introduces new complexity. Devices may be offline, slow, or unreliable. Data across users is often not evenly distributed, which can affect model accuracy. Communication costs also matter, especially when updates happen frequently.

There are also security considerations. While raw data is not shared, model updates can still leak information if not handled carefully. Techniques like secure aggregation and differential privacy are often used alongside to mitigate these risks.

For developers, this means thinking beyond just model accuracy. System design, update frequency, and fault tolerance become equally important.

Why it will matter in the Future

As machine learning systems expand into everyday products, the pressure to build responsibly will only increase. Centralized data collection does not scale well in a world where privacy expectations are rising.

For developers building the next generation of intelligent systems, understanding federated machine learning is no longer optional. It represents a shift in how we think about data ownership, system architecture, and user trust.

The future will not just be about smarter models. It will be about those whom users are willing to trust.

Sustainability in retail is a Software Problem Now

codecraft — Fri, 19 Dec 2025 14:46:25 +0000

Most retail platforms were built to optimize for speed, scale, and revenue. Environmental metrics were rarely part of the original design. When sustainability requirements enter the picture, teams quickly encounter gaps that are hard to bridge.

Some of the most common challenges include fragmented supply chain data, limited visibility across third-party vendors, inconsistent reporting standards, and legacy systems that resist change. These often surface at the system level, where engineering teams are expected to deliver answers without the right data foundations in place. Understanding sustainability in retail depends on understanding how products move from sourcing to fulfillment. That means connecting inventory systems, logistics platforms, warehouse operations, and customer-facing applications into a coherent data flow.

From a technical standpoint, this usually involves event-driven architectures, data pipelines that normalize supplier inputs, analytics layers for emissions and waste tracking, and APIs that expose sustainability metrics to internal stakeholders. Without this level of visibility, sustainability goals remain disconnected from everyday operational decisions.

Designing Systems That Can Adapt

Building systems that support sustainability is not about adding a reporting layer at the end. It requires architectural choices that assume change over time. Regulations evolve, reporting frameworks shift, and business priorities adapt.

Developers can support this by designing modular services, treating sustainability data as a first-class concern, and avoiding hardcoded assumptions about regions, suppliers, or compliance rules. Flexibility at the system level reduces long-term technical debt and allows sustainability initiatives to scale without constant rework.

Where Developers Make the Biggest Impact
Engineering teams have more influence on sustainability outcomes than they are often given credit for. Decisions about data ownership, integration patterns, and system boundaries directly affect how quickly retailers can respond to sustainability expectations.

Teams that invest early in adaptable architecture are better positioned to support both business growth and responsible operations without sacrificing one for the other.

To Conclude

Sustainability in retail is no longer just a business or policy discussion. It is a systems challenge that requires thoughtful engineering. Developers who understand the intersection of technology, data, and operations are becoming central to how sustainable practices are implemented at scale.

Shipping Features is Easy. Engineering them is Tough

codecraft — Fri, 12 Dec 2025 16:01:47 +0000

Ever feel like you’re moving fast but somehow still rewriting the same things every quarter?

That’s the gap digital engineering is trying to close.

For a long time, product innovation meant shipping features faster. But speed without structure creates fragile systems. The real question today isn’t how fast you can ship. It’s:

Can your product scale without breaking?
Can it adapt without a rewrite?
Can teams learn from real usage, not just dashboards?

Digital engineering flips the script. Engineering doesn’t start after product decisions are made, but it shapes them. Architecture, observability, automation, and data feedback loops become first-class citizens, not afterthoughts, an approach which is increasingly associated with digital engineering for scalable product innovation.

Think about your last release.
Was resilience designed in or patched later?
Did analytics guide decisions or just report problems?

Modern product teams are moving from project-based builds to platform-driven ecosystems, reflecting a broader shift toward digital-platform engineering models. The ones that evolve continuously, learn from users, and scale intelligently will be able to ensure long-term success.

This isn’t about adding more tools. It’s about engineering products that think ahead.

So here’s the real challenge:

Are you just delivering features or building systems designed to grow, adapt, and innovate over time?