Software Refactor vs Rewrite: Incremental Modernization for Legacy Systems

Software refactoring improves the structure of code that is already running, while a software rewrite replaces that implementation with a new one. The decision matters because both approaches can consume years of engineering capacity when the underlying problem has been diagnosed incorrectly. Ensono’s 2025 State of IT Modernization Report found that 49% of organizations found that actual legacy maintenance costs exceeded their planned budget last year. Rising maintenance costs should trigger an assessment of the platform before it triggers a replacement decision.

Refactoring preserves the running system and the knowledge already embedded in it. Rewriting creates more freedom to change architecture, but the replacement has to recover business rules, integration behavior, and operational edge cases before it can safely take over. Incremental modernization gives teams a third path by preserving the parts that still work and replacing only the capabilities that block the target state.

This guide explains how to choose between refactoring, selective rebuilding, and a full rewrite. It also shows how incremental modernization reduces migration risk, how the main modernization approaches differ, which transition patterns work in different situations, and how teams can measure whether the platform is actually becoming easier to change.

Key Takeaways:

• Refactor when the platform still supports the product and the main problem is change safety, complexity, or maintainability.
• Rebuild a bounded capability when one part of the platform has become the constraint while the surrounding system remains viable.
• Use a full rewrite when the required target state depends on changing core assumptions that cannot be removed incrementally at an acceptable cost or risk.
• Incremental modernization reduces cutover exposure by moving one production-tested capability at a time, with explicit ownership for every temporary migration layer.
• AI can accelerate analysis, characterization testing, and bounded implementation work while engineers retain architecture, cutover, and risk decisions.
• Measure progress against a baseline and track both improvement in the new system and retirement of the old one.

What Is the Difference Between Software Refactor, Rewrite, and Incremental Modernization?

Software refactoring improves the implementation that already exists, while software rewriting takes a different path by replacing that implementation with a new one. Incremental modernization lets the team make the same preserve-or-replace decision separately for each capability, so both approaches can exist inside one program.

Software Refactoring

Software refactoring changes the internal structure of existing code while preserving the behavior users and connected systems already depend on. Teams choose it when the product model still fits the business, but the code has become difficult to test, understand, or change safely. The work can improve module boundaries, simplify dependencies, strengthen tests, and remove code paths that make routine changes risky.

The main value of refactoring is continuity. Existing business rules, integrations, and operational knowledge remain inside the running system while engineers improve its internal structure. That makes refactoring especially useful when the application contains behavior that is difficult to rediscover from documentation alone.

Software Rewriting

A software rewrite creates a new implementation of the application or of a large part of it. Teams consider a rewrite when the current foundation prevents a required business or technical change and incremental improvements would leave the same structural constraint in place. The new implementation can use different architecture, data boundaries, frameworks, or platform assumptions.

Rewriting buys architectural freedom, and that freedom comes with a larger validation burden. The new system has to reproduce the business behavior that still matters, reconnect integrations, migrate data, and prove that production edge cases have not been lost. A rewrite is therefore strongest when the existing foundation is the problem rather than simply the quality of the code.

Incremental Modernization

Incremental modernization treats the platform as a set of capabilities rather than one replacement decision. A team can refactor a stable area, rebuild a bounded capability, replatform an infrastructure dependency, and leave another area unchanged. Each change still moves toward a shared target architecture while the existing application continues to serve users.

The key strength of incremental modernization is controlled choice. Engineers preserve business behavior where the current system still provides value and replace only the boundaries that prevent the platform from reaching its target state. Production results from one wave then inform the next decision instead of forcing the entire platform into one cutover.

How the Three Approaches Differ in Practice

The practical difference comes down to what the team preserves, what freedom it needs, and where migration risk will sit. Before comparing the approaches in a table, each criterion should be clear:

• Business behavior: The rules, exceptions, and workflows already encoded in the running system. The more undocumented behavior exists, the more valuable preservation becomes.
• Time to value: How soon a change can deliver usable production improvement. Refactoring can ship in smaller increments, while a rewrite usually delays value until enough parity exists for cutover.
• Architecture freedom: How much the team can change system boundaries, data models, or platform assumptions. A rewrite creates the most freedom, while refactoring works mainly within the current foundation.
• Testing and validation: The evidence required to prove that behavior is still correct. Refactoring can compare against the running system directly, while a rewrite needs to reproduce and validate behavior in a new implementation.
• Integrations and data: The contracts, dependencies, and ownership relationships that connect the application to other systems. Deep coupling increases the cost of replacement.
• Rollback: How easily the team can reverse a change after it reaches production. Smaller changes usually keep rollback local, while a rewrite can concentrate rollback risk around a major cutover.
• Team knowledge: The system understanding engineers have built through years of operating the platform. Refactoring keeps more of that context active, while rewriting requires the team to reconstruct it around the replacement.

The table shows why a rewrite should be driven by a structural requirement rather than frustration with the current codebase. Refactoring usually has the advantage when production behavior and integrations are valuable. Rewriting becomes more attractive when preserving the existing foundation prevents the business from reaching the required target.

Read more: .NET Application Modernization: WinForms, WPF, MAUI, Blazor, and AI-Safe Refactoring and What Is AI Code Refactoring? Best Ways to Modernize Enterprise Software in 2026.

When Should You Refactor, Rebuild, or Rewrite?

Refactor when the foundation still fits the product, rebuild when the problem is isolated to one capability, and rewrite when core assumptions in the platform conflict with what the business now needs. The decision should follow the location of the constraint rather than the age of the codebase or the amount of technical debt.

Refactor When the Foundation Still Works

Choose refactoring when the application still represents the right business model and can reach the required target through bounded structural improvements. Common signs include weak test coverage, excessive coupling, duplicated logic, or modules that are difficult to change even though the overall architecture remains viable.

Refactoring is most valuable when preserving production behavior matters more than gaining architectural freedom. The team can improve change safety and maintainability without rebuilding integrations, migrating data, or asking users to move to a replacement system.

Rebuild When the Problem Is Bounded

Selective rebuilding fits when one capability has become more expensive or risky to repair than to replace, while the surrounding platform remains useful. An obsolete customer portal, unsupported reporting engine, or pricing component built around outdated requirements can often be replaced behind a stable boundary.

A bounded rebuild keeps the replacement focused on the capability that actually causes the constraint. The rest of the system retains its business logic, data relationships, and integrations, which prevents one local problem from turning into a system-wide migration.

Rewrite When the Foundation Is the Constraint

A full rewrite becomes defensible when the current application cannot support a required target without changing most of its core assumptions. For example, a platform designed around one account per customer may struggle to support organizations with shared billing, permissions, and collaboration when that assumption is embedded across the code and data model.

The decision becomes stronger when the limitation is structural and appears in production requirements rather than only in code quality. A 2025 HFS Research Pulse survey of 305 enterprise leaders found that 36% identified inability to scale systems to meet growing business demands as a significant impact of outdated or inefficient technology. The useful question is whether the current architecture causes that limit or whether bounded improvements can remove it.

How to Read the Decision Matrix

The matrix below maps observable signals to the strategy they tend to support. Each signal answers a different part of the decision:

• Architecture: Whether the existing structure can support the required target after reasonable improvement. A fundamental architecture constraint provides stronger evidence for replacement than ordinary code complexity.
• Platform support: Whether the runtime, framework, or vendor stack has a viable path forward. End-of-life technology matters most when there is no supported migration route.
• Domain knowledge: How well the team understands the business behavior that must survive modernization. Complex or undocumented behavior increases the value of preserving the running system.
• Business-model fit: Whether the application still represents how the product and customers work today. A change to the core product model can justify deeper replacement than a local feature gap.
• Integrations and data: How tightly other systems and data ownership depend on the current implementation. Deep live dependencies usually increase migration complexity.
• Operating continuity: How much disruption users and connected systems can tolerate. Continuous-service requirements often favor smaller, reversible changes.

The matrix is useful when one signal clearly dominates. A platform with poor code quality but a viable architecture still points toward refactoring. A platform with a clean codebase but a product model that cannot represent the next business requirement can still justify a rewrite.

What Is Incremental Modernization for Legacy Systems?

Incremental modernization changes an established platform in production-sized waves while the rest of the system continues operating. Each wave moves one capability toward a defined target state, validates the result under real conditions, and retires the old path once the replacement is ready.

Incremental Updates

Incremental updates improve the current system without necessarily changing where the platform is going. A dependency patch, database upgrade, or framework update can reduce operational risk and keep the application supported. These changes are valuable maintenance work even when the architecture and capability boundaries remain the same.

An update becomes part of a modernization program when it removes a known constraint or prepares a capability for the target architecture. The defining factor is the role the change plays in the larger transition, rather than the size of the change itself.

Incremental Modernization

Incremental modernization uses a sequence of bounded changes to move the platform toward a different target state. A wave may refactor code, replatform a dependency, rebuild a capability, or change ownership boundaries. Each wave has a reason for existing, a production validation method, and a clear condition for retiring the old path.

The approach gives teams a way to learn while the running system remains available as a reference. Production evidence from one capability can expose undocumented dependencies or validation gaps before the same approach is applied to the next capability.

The Practical Difference

Incremental updates improve the platform that exists today, while incremental modernization uses bounded changes to move the platform toward a defined future state. An update can remain standalone maintenance work, whereas a modernization wave should contribute to the target architecture or remove a constraint that prevents the target from being reached.

Why Incremental Modernization Reduces Risk

A change that affects too much of the system at once makes failures hard to isolate and reverse. Smaller migration boundaries keep the blast radius manageable. The team can validate production behavior before committing to the next wave, and unexpected dependencies surface while the old implementation is still available for comparison and rollback.

This changes the risk profile from one large cutover to a sequence of smaller decisions. Each decision has its own evidence, owner, rollback path, and retirement condition, which makes it easier to stop or change direction before too much of the platform is affected.

The Cost of Coexistence

Old and new paths often need to run together during migration, which adds infrastructure, adapters, synchronization, and support work. That cost is justified only while coexistence helps the team validate the replacement or control cutover risk. Every temporary component should have a named owner and a retirement condition before it enters production.

How Do Rehost, Replatform, Refactor, Rearchitect, Rebuild, and Rewrite Differ?

These approaches differ by the layer of the system they change and by how much of the current implementation they preserve. The order below moves from changes around the application to changes that replace more of the application itself.

Rehost

Rehosting moves the existing application to different infrastructure with minimal code change. The application architecture and business behavior usually stay the same, so rehosting is useful when hosting, hardware, or infrastructure support is the immediate constraint. It can reduce infrastructure risk quickly, but it does not remove application-level design problems.

Replatform

Replatforming changes an important platform dependency such as the runtime, database, middleware, or managed service while preserving most application behavior. Teams use it when the surrounding platform limits support, operations, or scale. The main challenge is compatibility work that appears when the application depends on platform-specific behavior.

Refactor

Refactoring changes the internal structure of existing application code while preserving expected behavior. It is appropriate when maintainability, coupling, or change safety is the problem and the current foundation still fits the product. Refactoring improves the implementation without requiring a replacement cutover.

Rearchitect

Rearchitecting changes system boundaries, ownership, or the way components communicate. It is useful when the main constraint comes from how responsibilities and data are divided across the platform. The work can create clearer independent capabilities, but new boundaries also introduce coordination and distributed-system complexity.

Rebuild

Rebuilding replaces the implementation of one bounded business capability while the rest of the platform remains in place. It fits when one area has become uneconomical to repair or cannot support its next requirements. A rebuild stays safer when its boundary is stable, and the replacement does not expand into unrelated parts of the system.

Rewrite

A rewrite replaces most or all of the application implementation and gives the team the greatest freedom to redesign the foundation. It is appropriate when the existing platform cannot reach the required target through bounded change. The trade-off is the largest migration and validation burden because the new system must reproduce the business behavior that still matters before cutover.

How to Compare the Options

The table below compares the same approaches across 4 questions. The questions keep the comparison consistent instead of switching criteria from one pair of terms to another:

• What changes: Identifies the layer of the system the approach modifies.
• What usually stays: Shows how much of the current implementation and behavior can remain in place.
• Use it when: Connects the technique to the type of constraint it is designed to remove.
• Main risk: Shows the failure mode the team needs to control before choosing that approach.

A modernization program can sequence several of these approaches. A team may rehost to leave unsupported infrastructure, replatform a database, refactor modules to create clearer seams, and rebuild one capability whose implementation has become the limiting factor. The sequence should follow dependencies and production risk.

When Does the Strangler Fig Pattern Make Sense for Incremental Modernization?

The Strangler Fig pattern works when a capability can be isolated behind a routing boundary and moved to a new implementation while the rest of the application keeps running. The new implementation gradually takes production traffic until the old capability is ready for retirement.

The pattern is valuable because replacement and cutover happen at different times. The team can learn from one capability in production before the rest of the platform depends on the same migration approach.

Route Through a Facade

The transition needs something to stand between the caller and both implementations. A proxy, gateway, or routing layer decides whether a request reaches the old or new implementation. The facade exists only for the transition, so its owner and retirement condition should be defined when it is introduced.

Replace by Business Capability

Choose migration boundaries that keep related behavior together. If pricing moves, the rules, data ownership, compliance logic, and reports that belong to pricing should move with it. A technical-layer migration can split one business workflow across old and new systems and recreate the coordination problem the modernization was meant to remove.

Shift Traffic Gradually

Begin with limited production exposure and expand when evidence supports the next step. Feature flags, canary releases, and percentage routing all send a small share of real traffic to the new implementation while the old one stays live. That controlled exposure lets teams compare behavior, observe errors, and keep rollback local while confidence grows.

Decommission the Old Slice

The wave finishes when the old capability and its temporary migration paths are removed. Infrastructure, integrations, data paths, and support work should disappear as ownership transfers to the replacement. Keeping the old path indefinitely adds another permanent layer to the platform.

When the Strangler Fig Pattern Is a Poor Fit

The pattern works poorly when the application has no stable routing seam or when transactions are too tightly coupled to move independently. Direct replacement may also be simpler for a small system, while a hard decommission deadline can make a long coexistence period impractical.

Which Patterns Support Incremental Modernization?

Strangler Fig depends on a way to redirect traffic at the application boundary, while many modernization problems sit deeper inside the codebase. Other transition patterns create a controlled seam inside the system so a new implementation can be built and validated before it becomes authoritative.

Branch by Abstraction

Branch by Abstraction places a stable interface between callers and a component that needs replacement. Old and new implementations can exist behind the same contract while callers move gradually. It is useful for internal components such as authentication, pricing, or shared calculations.

Parallel Run

Parallel Run gives the old and new implementations the same inputs while the old system remains authoritative. The team compares outputs before transferring control, which makes the pattern useful for pricing, payments, eligibility, and other workflows where business results must match before cutover.

Event Interception

Event Interception lets a replacement consume existing business events before it becomes the system of record. The pattern helps teams build or validate a new capability alongside the old one, but event order, duplicates, replay, and data ownership need explicit rules.

API Facades

An API facade gives dependent systems a stable contract while the implementation behind it changes. Consumers can continue using the same interface, which reduces coordination and lets the underlying capability modernize on a different schedule.

How Should Teams Build an Incremental Modernization Roadmap?

Build the roadmap from the target state backward. The team first needs to understand the current system, then make change safe and define the destination. Next, choose one bounded capability and validate the migration method in production. Finish the wave by removing the old path.

Each phase should end with evidence that allows the next decision. Activity alone does not prove that the platform is ready to move forward, so the roadmap needs explicit outputs and exit criteria.

The Roadmap Sequence

1. Assess the Current State: Map capability boundaries, dependencies, data ownership, change hotspots, and areas where production behavior is poorly understood. The output should identify where the system can change independently and where hidden coupling creates migration risk.
2. Build the Safety Net: Characterization tests capture how the existing system behaves before anything changes. Add them alongside observability, a repeatable build, and a tested rollback procedure. These controls give the team a way to detect behavior changes and recover before a migration wave affects too much of the platform.
3. Define the Target Architecture: Set the destination and the rules every migration wave should follow. Ownership, runtime, data boundaries, deployment, and security decisions need enough clarity that separate teams do not modernize in different directions.
4. Select the First Capability: Choose an area the team understands well enough to validate and small enough that a failed migration remains manageable. The first slice should still be meaningful enough to test whether the modernization method works under real conditions.
5. Migrate and Validate: Run the new capability in production, compare behavior, and expand exposure only when the evidence supports it. The team should know which metrics, parity checks, and failure conditions determine whether traffic can increase.
6. Cut Over and Decommission: Transfer ownership deliberately after production validation and keep the rollback window open for a defined period. Once the decision is final, remove the old implementation and temporary migration paths so the platform actually becomes simpler.

For a deeper assessment process, our Application Modernization Assessment Checklist for CTOs covers the areas teams should review before choosing what to modernize.

Evidence and Exit Criteria

The table uses the same 6 roadmap phases described above. Each row summarizes the objective of the phase, the evidence that should exist, and the condition that should be met before the team moves forward.

What Makes Data Migration and Cutover Difficult During Modernization?

Shared data ownership is the main reason incremental application migration becomes difficult. Request routing can move gradually, but old and new systems cannot remain equally authoritative for the same data indefinitely. The migration therefore needs a controlled period of coexistence followed by an explicit transfer of ownership.

The difficult work happens before the final switch. Teams need to understand which capabilities read, write, calculate, and report on the same business data so the new boundary reflects actual ownership rather than assumptions from the code structure.

Shared Database Dependencies

Shared schemas can couple capabilities that appear separate in the application layer. One module may update data another module assumes it owns, so the migration boundary needs to account for those cross-domain writes before production traffic moves.

Synchronization During Coexistence

Old and new systems may need to read the same information for a period, while write ownership remains explicit. Changes can arrive out of order, be duplicated, or be interpreted differently, which means reconciliation rules should be designed before coexistence begins.

Data Parity

Data parity means that the old and new systems produce the same business outcomes for the capability being moved. Matching row counts gives only a structural check, while balances, prices, eligibility results, and reports show whether the business behavior is actually equivalent.

Source-of-Truth Cutover

The final write-routing change should be treated as a formal decision gate. The team confirms synchronization, monitoring, rollback timing, and ownership before switching the source of truth, then retires the old write path when the rollback window closes.

Where Can AI Safely Accelerate Incremental Modernization?

AI coding agents are most useful in modernization work that has a clear way to verify the result. They can accelerate the bounded implementation work that follows a preserve-or-replace decision, while engineers retain the judgment calls that determine what should change and what should not.

That separation matters in an established platform because code can look technically plausible while still violating behavior learned through years of production use. AI should reduce mechanical effort while the team keeps the same evidence standard for changes that reach business-critical paths.

Codebase Understanding

Coding agents can trace call paths, summarize modules, and suggest likely dependency seams. Their output should be validated against runtime behavior, logs, and production evidence because static analysis can miss reflection, configuration-driven behavior, and dynamic coupling.

Characterization Tests

AI can help create tests that capture how the existing system behaves before modernization starts. Domain experts still need to confirm expected results for critical workflows so the suite does not preserve behavior that was already wrong.

Teams using AI on a live codebase can follow our AI Coding Workflow Optimization guide for safe, reviewable Claude workflows.

Bounded Refactoring

Framework upgrades, API replacements, dependency remediation, and small module extractions fit AI-assisted work when each change can be reviewed and reversed independently. Large generated change sets expand the review surface and remove the safety advantage of incremental execution.

Human-Owned Decisions

Domain boundaries, data ownership, cutover approval, and risk acceptance remain engineering and business decisions. AI can prepare evidence and execute bounded work, while accountable people decide what the platform should become and when production ownership should move.

Our internal data from modernization projects shows that AI is most effective when it handles predictable discovery and implementation work. In these projects, we’ve found that these tasks can account for around 30% of a developer’s sprint. This gives AI a clear opportunity to reduce low-leverage work. We use human validation when changes affect shared state or critical paths, so engineers can verify how those changes propagate through the application.

How Should Teams Measure Modernization Success?

Measure modernization against the condition of the platform before the work started. A successful program should make modernized areas easier and safer to change while reducing the amount of legacy technology the organization still has to operate.

The measurement model needs to cover several outcomes at the same time. Before the table, these are the areas that matter and what each one tells the team:

• Delivery: Shows whether modernized capabilities move through development and release faster than their own baseline. Lead time, deployment frequency, and review cycle are useful only when segmented between modernized and legacy areas.
• Reliability: Shows whether the new implementation can be changed without increasing production risk. Change failure rate, incidents, rollback frequency, and recovery time reveal whether faster delivery is creating more operational cost.
• Business outcome: Connects modernization to the reason the investment was approved. Processing time, operating cost, revenue impact, or customer outcomes should improve in the workflow the modernization was meant to change.
• Legacy retirement: Reveals whether the old platform is actually shrinking. Retired modules, jobs, licenses, adapters, infrastructure, and data paths prevent the program from adding a new architecture layer while keeping all of the old cost.

These measures need to be read together because faster delivery has limited value if incidents rise or the old capability remains in production indefinitely. Legacy retirement also has limited value when the replacement fails to improve the business or engineering constraint that justified the migration.

What Are the Most Common Modernization Failures?

Most modernization failures begin with a poor disposition decision or an unfinished migration. Teams can rewrite before proving that the foundation is the constraint, refactor without a target state, choose boundaries that split business behavior, or keep temporary migration architecture long after it has served its purpose.

Each failure creates the same outcome in a different way: the organization spends engineering capacity without removing the constraint that started the modernization program.

Deciding to Rewrite Too Early

A new codebase can reproduce the same business and data constraints as the old one when the team has not identified what prevents the target state. The rewrite then spends time recreating behavior while the original bottleneck survives in a different implementation.

Refactoring Without a Target State

Code cleanup can improve maintainability without changing the platform constraint that triggered modernization. Refactoring needs a defined outcome, such as making a capability independently deployable or removing a dependency that blocks scale, so the work has a clear completion point.

Migrating Technical Layers Instead of Capabilities

Moving an entire UI, API, or database layer can split one business workflow across old and new systems. That increases coordination and makes parity harder to validate, while capability boundaries keep related behavior and ownership together.

Allowing Permanent Coexistence

Facades, duplicate stores, adapters, and compatibility code can become permanent when retirement is left outside the migration plan. Every wave should include decommissioning in its definition of done so temporary architecture disappears as the replacement takes ownership.

How Does GoGloby Modernize Established Software Through Forward-Deployed Engineering?

GoGloby is an Applied AI Engineering partner that helps established software companies put Claude into production without risking the codebase. For modernization, the work starts with a benchmark rather than a predetermined rewrite plan. We use that benchmark to help you determine whether an established system should be refactored or rewritten. Then we forward-deploy an AI Solutions Architect inside your pipeline to address the constraints that make the platform expensive or risky to change. 

That sequence fits the decision model in this article. The AI Development Intelligence Layer establishes the client’s delivery baseline, while the AI Solutions Architect combines that operating evidence with codebase assessment and production behavior. The result is a modernization path based on what should be refactored, selectively rebuilt, or preserved, with progress measured against the same baseline rather than against a generic productivity claim.

Benchmark Before Choosing the Modernization Path

The AI Development Intelligence Layer deploys inside the client’s VPC and connects to the engineering tools the team already uses. It makes AI adoption, engineering spend, cost per shipped feature, and delivery bottlenecks visible before modernization accelerates. For an established platform, that benchmark adds a delivery and cost view to the technical assessment, so the first modernization slice is chosen with both system evidence and operating evidence.

Forward-Deploy the Right Engineering Roles

GoGloby’s embedded engineers work through the client’s repos, backlog, pipeline, and review process rather than operating as an outside project team. AI Solutions Architects set up or adapt the Agentic SDLC and measurement layer. They add Claude-specific depth when Anthropic models are central to the environment and handle hands-on feature and modernization delivery.

Measure Each Wave Against the Client’s Baseline

The goal is not to prove that modernization activity happened. Each wave should show whether the affected capability became easier to change, whether delivery or cost improved, and whether the old implementation was actually retired. GoGloby measures progress against the client’s own benchmark so engineering leaders can see what changed in delivery and what the AI investment produced as the modernization program moves forward.

Read more: How to Choose an AI-Native Engineering Partner for Your Business in 2026 and What Is Data Leakage in AI and How to Prevent It in 2026. 

Conclusion

A modernization decision should begin with the constraint the platform needs to remove. Refactoring fits when the existing foundation can still reach the target. Selective rebuilding fits when one capability blocks progress. A full rewrite becomes justified when the required target depends on changing core assumptions across most of the system.

Incremental modernization gives teams a way to make those decisions capability by capability. The running platform remains available as a source of production behavior, each migration wave can be validated before the next begins, and the old system becomes smaller as ownership moves to the replacement.

Start by mapping the current system and defining the target state. Choose one capability where the modernization method can be proved safely, establish the tests and rollback controls before changing production behavior, and use the evidence from that wave to decide what should move next.

FAQs

Sergey Matikaynen / CTO

Article author

Sergey Matikaynen is Co-Founder and CTO of GoGloby, where he owns the engineering standard behind 4x Applied AI Engineering. He has spent 16+ years building and leading software teams for companies across the US, Canada, and Europe — software architecture, agile delivery, and engineering leadership. At GoGloby, he sets the technical bar that Applied AI Software Engineers are vetted against, including certified Agentic SDLC mastery. He is a LinkedIn Top Voice in software development.

View profile