Engineering leadership for complex technology problems. on dplabs — Software Engineering & Technology Consultancy

Trunk-Based Development vs GitFlow: What the Debate Is Actually About

Tue, 28 Jul 2026 00:00:00 +0000

The branching strategy debate is loudly opinionated in both directions. GitFlow advocates point to clean release management and isolated feature development. Trunk-based development advocates point to the evidence that short-lived branches correlate with higher engineering performance. Both sides are often talking past each other.

The useful question is not “which is better” but “which fits our context” — and the context includes team size, release cadence, engineering practices, and the nature of the software being delivered.

The Cost of Clever Code

Mon, 13 Jul 2026 00:00:00 +0000

Every programming language has features that allow you to write dense, sophisticated-looking code. Java has streams, lambdas, method references, and generic type hierarchies. These are useful tools. They’re also regularly used to write code that is harder to understand than the straightforward version with no corresponding benefit.

Clever code has a cost. The cost is paid by every engineer who reads it, modifies it, or debugs it. In a living codebase, that cost is paid repeatedly.

Secure by Default: APIs That Are Hard to Misuse

Mon, 29 Jun 2026 00:00:00 +0000

Security by default is a design principle, not a feature list. An API is secure by default when using it correctly produces secure behavior automatically, and producing insecure behavior requires deliberate effort.

Most security failures are not the result of sophisticated attacks on well-designed systems. They’re the result of developers using APIs incorrectly, making incorrect assumptions about what defaults are safe, or forgetting to add security checks that should have been built in.

Designing Code for Change

Mon, 15 Jun 2026 00:00:00 +0000

Software changes. This is not a contingency — it’s the nature of software development. Requirements evolve. Systems scale. Technologies improve. Teams change. The useful question is not “will this change?” but “when it changes, how expensive will the change be?”

Code that’s designed for change is not over-engineered. It’s code where the natural boundaries of the design align with the natural boundaries of change. When a change is required, it affects a small, predictable, well-bounded area. When it’s not, the design hasn’t added unnecessary complexity “just in case.”

Infrastructure as Code Is Software

Mon, 01 Jun 2026 00:00:00 +0000

Infrastructure as Code emerged as a response to the problem of undocumented, inconsistent, manually-managed infrastructure. Click-ops servers where nobody knows what’s actually configured. Snowflake environments that differ from production in undocumented ways. Infrastructure that can’t be reproduced.

IaC solved these problems by treating infrastructure as code. The irony is that many teams write infrastructure code with none of the engineering rigor they apply to application code. No reviews, no tests, no code quality standards, no documentation. The result: IaC that has the same problems as the click-ops it replaced, plus the added complexity of Terraform state files.

Immutable Infrastructure vs Configuration Management: Choosing Your Operations Model

Mon, 18 May 2026 00:00:00 +0000

Two schools of thought in infrastructure management have different answers to the same question: when the configuration of a server needs to change, what do you do?

Configuration management answer: connect to the server and change it. Tools like Ansible, Puppet, and Chef automate this process.

Immutable infrastructure answer: build a new server with the desired configuration, route traffic to it, terminate the old one. The server itself is never modified after provisioning.

How to Evaluate Architecture Without Falling in Love With Solutions

Mon, 04 May 2026 00:00:00 +0000

Every engineer who has spent significant time in architecture discussions has seen the same dynamic: a proposed solution is presented, its proponents defend it, critics pick at details, and the group gravitates toward whichever solution has the most enthusiastic advocate rather than the best trade-off profile.

This is not evaluation. It’s preference arbitration.

Effective architecture review requires a framework that separates the emotional investment from the analysis — that forces explicit engagement with dimensions like cost, risk, and reversibility that advocates tend to minimize and critics tend to ignore.

The Security Risks of AI-Enabled Applications

Tue, 21 Apr 2026 00:00:00 +0000

Integrating AI into applications introduces security risks that traditional application security doesn’t address. Most security frameworks were designed for deterministic systems. LLMs are not deterministic — their outputs depend on inputs in ways that are difficult to predict, test, or constrain.

This doesn’t mean AI applications are inherently insecure. It means you need to think about security differently when LLMs are in the loop.

The Core Problem: LLMs Process Text as Instructions

In a conventional application, there’s a clear distinction between code and data. A SQL injection attack tries to blur that boundary — to get user input interpreted as SQL commands. You prevent it by parameterizing queries, by treating user input as data rather than code.

Building AI Features Without Losing Control of Your Architecture

Mon, 06 Apr 2026 00:00:00 +0000

AI features are getting added to production systems quickly — often quickly enough that the usual architectural discipline gets skipped. The integration is direct: OpenAI SDK in the service, API calls scattered through business logic, prompts hardcoded in the calling code.

This works for a proof of concept. At production scale, with real operational requirements, it creates a class of problems that are expensive to fix after the fact.

The Vendor Lock-in Problem

Directly using the OpenAI SDK, the Anthropic SDK, or any provider’s client library throughout your codebase creates tight coupling to that provider’s interface. When you want to:

Building Reliable AI Agents: Beyond the Demo

Mon, 23 Mar 2026 00:00:00 +0000

AI agents are compelling in demos. A language model that can use tools, retrieve information, take actions, and chain multiple steps together appears to solve problems that weren’t solvable before. Then you try to ship one and discover that the demo success rate was 80%, which means 1 in 5 operations fail silently.

Production agents require the same engineering discipline as any other distributed system. The failure modes are different, but the principles — observability, error handling, testing, graceful degradation — are the same ones you apply everywhere else.

AI Engineering Is Software Engineering

Mon, 09 Mar 2026 00:00:00 +0000

There’s a tendency to treat AI features as different from other software. Different enough that normal engineering practices don’t apply, or apply differently, or can be deferred. This tendency produces AI systems that are unreliable, unobservable, expensive to operate, and difficult to improve.

AI systems built with the same engineering discipline as other distributed systems are more reliable, cheaper to operate, and easier to improve. The disciplines aren’t different. The application is.

MCP: The Interface Between AI Models and the Rest of Your Systems

Mon, 23 Feb 2026 00:00:00 +0000

The Model Context Protocol (MCP) is a specification introduced by Anthropic in November 2024 that standardizes how LLM applications connect to external data sources and tools. It has since been adopted broadly — by OpenAI, Google, and major developer tooling vendors — and is becoming the standard interface layer between AI systems and the services they interact with.

Understanding MCP requires understanding the problem it solves, because the protocol itself is not complex.

Multi-Agent Systems: Useful Architecture or Complexity for Its Own Sake?

Mon, 09 Feb 2026 00:00:00 +0000

Multi-agent systems have become a popular architectural pattern in AI applications. The idea is appealing: if one agent is good, multiple agents working together must be better. Specialized agents for different subtasks. Agents reviewing each other’s work. Parallel execution across agents.

The appeal is intuitive. The implementation is often a mess of non-deterministic coordination, cascading hallucinations, and debugging nightmares where a problem in one agent produces a subtly wrong result that propagates through three others before producing a visible failure.

Evaluating LLM Applications: Beyond Vibe Checks

Mon, 26 Jan 2026 00:00:00 +0000

Most teams evaluate their LLM applications by asking them a few questions and deciding whether the answers look right. This is not evaluation — it’s a vibe check. It doesn’t scale, doesn’t catch regressions, and doesn’t provide any basis for measuring improvement over time.

Systematic LLM evaluation is harder than evaluating deterministic software. The outputs are probabilistic, quality is multidimensional, and the correct answer often isn’t a single string. These are difficulties, not reasons to skip evaluation.

RAG vs Fine-Tuning: Choosing the Right Tool for LLM Customization

Mon, 12 Jan 2026 00:00:00 +0000

“Should we use RAG or fine-tuning?” is a question teams ask when they need an LLM to work better for their specific use case. It’s often the wrong question — they’re different tools that solve different problems and can be combined.

Getting this wrong is expensive. Fine-tuning a model to “know” information that should be retrieved leads to a model that’s expensive to update and confidently answers with stale data. Implementing RAG when the problem is actually about model behavior leads to a system that retrieves correctly but still behaves wrong.

Database Migrations in Continuous Delivery

Mon, 04 Aug 2025 00:00:00 +0000

Every CI/CD guide covers application deployment. Very few cover the harder problem: database schema changes in a system that can never be offline.

The challenge is that application and database deployments are not atomic. During a rolling or blue-green deployment, old and new application versions run simultaneously against the same database. A migration that’s incompatible with the old version causes the old version to fail — precisely during the deployment window when you can least afford failures.

Spring Boot Dependency Injection Without Losing Your Architecture

Mon, 21 Jul 2025 00:00:00 +0000

Spring’s dependency injection container is one of the most mature and capable DI frameworks available. It’s also capable of enabling architectures that are deeply coupled to Spring internals, impossible to test without a full Spring context, and opaque about their dependencies.

The patterns that produce good Spring Boot architectures are not complicated. They require deliberate choices about when to use Spring and when to step back from it.

Constructor Injection Is Non-Negotiable

Spring supports three injection mechanisms: constructor, setter, and field injection. Field injection (@Autowired on a field) is the most common and the worst.

Code Reviews: Reviewing Design, Not Formatting

Mon, 07 Jul 2025 00:00:00 +0000

Code review is one of the highest-leverage practices in software engineering. Done well, it catches defects before they reach production, distributes knowledge, and improves the overall quality of the codebase. Done poorly, it’s a bureaucratic checkpoint that blocks delivery while catching only superficial issues.

The difference is usually what the reviewer focuses on.

What Automated Tools Should Catch

The first principle of effective code review: don’t spend human review time on things that tools can detect.

Java Performance: Stop Guessing, Start Measuring

Mon, 23 Jun 2025 00:00:00 +0000

Most Java performance work starts in the wrong place. An engineer identifies “the application is slow,” forms a hypothesis based on code familiarity, and makes changes based on intuition. Sometimes it works. More often, the actual bottleneck was elsewhere and the optimized code is now more complex with no performance benefit.

The methodology matters: measure, identify the bottleneck, optimize, measure again. In that order. Not “optimize the thing that looks suspicious, then measure.”

Building Resilient Spring Boot Services

Mon, 09 Jun 2025 00:00:00 +0000

Resilience patterns exist to handle the failures that are guaranteed to occur in distributed systems. Downstream services become unavailable. Networks time out. Databases become overloaded. These are not exceptional events — they’re normal operating conditions that a production service must handle correctly.

The mistake is adding resilience patterns everywhere as a precaution. A circuit breaker on a service that never fails adds overhead without value. A retry on a non-idempotent operation can cause duplicate side effects. Resilience patterns should be applied deliberately, to specific failure modes that matter for your system.

Security Is an Architecture Concern

Mon, 26 May 2025 00:00:00 +0000

Security gets treated as a feature set: authentication, authorization, input validation, encryption. Implement those features and the system is secure. This framing is wrong and produces systems that are secure in obvious ways while vulnerable in non-obvious ones.

Security is an emergent property of architectural decisions: where trust boundaries are placed, how data flows between components, what permissions components have, how failures are handled. These decisions are made during design, not during a security review at the end.

Deployment Strategies: Blue/Green, Canary, and Rolling Deployments

Mon, 12 May 2025 00:00:00 +0000

A deployment strategy is not just a technical implementation detail. It determines how much risk you take with each release, how quickly you can recover from problems, and what infrastructure you need to support it. Choosing without understanding the trade-offs is choosing accidentally.

Rolling Deployments: The Default

Rolling deployments incrementally replace old instances with new ones. At any point during the deployment, both old and new versions are running simultaneously.

Structured Concurrency in Java: Fixing Unstructured Concurrent Code

Mon, 28 Apr 2025 00:00:00 +0000

Java’s concurrency model has been functional for decades. ExecutorService, Future, CompletableFuture — these tools work. They also have a persistent problem: when you submit tasks to an executor, the relationship between the spawning thread and the spawned tasks is not represented in the code. Errors are easy to lose. Cancellation doesn’t propagate automatically. Resources leak when tasks outlive their intended scope.

Structured concurrency, finalized in Java 24 (JEP 505 after multiple preview rounds), fixes this. The core principle: concurrent tasks should have lifetimes that are scoped to the block of code that spawned them, just as try-with-resources scopes resource lifetimes.

Terraform: Modules, State, and the Hidden Complexity

Mon, 21 Apr 2025 00:00:00 +0000

Terraform is the dominant infrastructure as code tool for AWS, GCP, and Azure workloads. Getting started is straightforward. Operating it at scale — across multiple teams, environments, and hundreds of resources — surfaces complexity that the getting-started tutorials don’t address.

This article focuses on the operational lessons: state management, module architecture, and the patterns that keep Terraform manageable as infrastructure grows.

Note: Terraform is developed by HashiCorp under the BSL license. OpenTofu is the open-source MIT-licensed fork, API-compatible with Terraform 1.5. For teams that require a fully open-source toolchain, OpenTofu is the alternative to evaluate.

Abstraction Is a Cost, Not a Free Feature

Mon, 07 Apr 2025 00:00:00 +0000

Software engineering culture values abstraction. Interfaces, layers, generalization, frameworks — these are treated as inherently good. The more abstract your code, the more flexible and reusable it is.

This is partially true and partially a way to build systems that are harder to understand than they need to be.

Abstraction has real benefits. It also has real costs. The question is whether the benefits outweigh the costs in a specific context — not whether abstraction is good in the abstract.

Spring Boot Observability: Metrics, Tracing, and Logs That Actually Help

Mon, 31 Mar 2025 00:00:00 +0000

Spring Boot 3.x has strong observability support built in. Spring Boot Actuator, Micrometer for metrics, Micrometer Tracing (built on OpenTelemetry), and structured logging all work out of the box with minimal configuration.

The gap between “instrumented” and “observable” is wider than it looks. Adding dependencies and enabling endpoints is instrumentation. Being able to answer “why are 3% of requests failing between the payment service and the inventory service, and since when?” is observability.

Authentication vs Authorization: Two Problems People Keep Conflating

Mon, 24 Mar 2025 00:00:00 +0000

“Authentication” and “authorization” are often used interchangeably. They’re not the same problem, they’re not the same solution, and conflating them produces security architectures that fail in predictable ways.

The Definitions That Matter

Authentication: verifying who someone is.

A request is authenticated when the system has verified that the claimed identity (user, service) is legitimate. After authentication, you know who is making the request.

Authorization: determining what someone is allowed to do.

Technical Debt: Not All Debt Is Bad

Mon, 03 Mar 2025 00:00:00 +0000

Ward Cunningham introduced the technical debt metaphor to explain to non-technical stakeholders why code needed to be refactored. The analogy to financial debt was deliberate: sometimes you borrow money to move faster, and the interest compounds over time until the debt needs to be paid.

Over time, the metaphor has been stretched to cover every imperfect thing in a codebase. This is not useful. Not all debt is the same. Not all debt should be paid down.

Spring Boot Testing: What Should Actually Be Tested and How

Mon, 10 Feb 2025 00:00:00 +0000

Spring Boot’s testing support is extensive and well-designed. It’s also easy to misuse in ways that produce slow, fragile test suites with poor diagnostic value.

The core question is not “how do I test with Spring Boot?” but “what needs to be tested, and at what level?”

The Testing Pyramid Applied to Spring Boot

The testing pyramid principle: favor many fast, isolated unit tests over fewer slow integration tests. Each level of the pyramid is slower and more expensive to run but tests more of the system.

Staff Engineers Don't Just Write Better Code

Mon, 03 Feb 2025 00:00:00 +0000

Most senior engineers who become staff engineers don’t change what they do — they do more of the same, better. They write more code, review more PRs, solve harder technical problems. They’re surprised when their promotion doesn’t materialize.

The confusion is understandable. Senior engineering is primarily about individual technical excellence. Staff engineering is primarily about multiplying the technical effectiveness of the organization around you.

These require different skills and, more importantly, a different mental model of what your job is.

Records and Sealed Classes: Better Domain Models in Java

Mon, 27 Jan 2025 00:00:00 +0000

Java domain modeling has historically been verbose and error-prone. Entity classes with dozens of getter/setter pairs, boolean fields that encode state (isActive, isCancelled, isPending), and null fields used to represent the absence of a value all create code that’s hard to understand and easy to misuse.

Records and sealed classes address this. They’re not cosmetic improvements — they change what kinds of mistakes the compiler can catch for you.

Records: Immutable Data Carriers

A record is a class defined by its components. The compiler generates the constructor, accessors, equals, hashCode, and toString automatically:

Pattern Matching in Modern Java: Records, Switch, and Exhaustiveness

Mon, 20 Jan 2025 00:00:00 +0000

Pattern matching in Java 21 is the culmination of several interconnected features: instanceof patterns (Java 16), sealed classes (Java 17), switch expressions (Java 14), and switch patterns (Java 21). Understanding them individually is useful. Understanding how they compose is where the real power is.

The Baseline: Pattern Matching for instanceof

Before Java 16, checking and casting looked like this:

Object shape = getShape();
if (shape instanceof Circle) {
    Circle c = (Circle) shape;  // Redundant cast
    return c.area();
} else if (shape instanceof Rectangle) {
    Rectangle r = (Rectangle) shape;
    return r.area();
}

Java 16 introduced pattern variables in instanceof:

Clean Code Is Not About Pretty Code

Mon, 13 Jan 2025 00:00:00 +0000

“Clean code” has become a proxy for “code that looks like the author read Clean Code.” Short methods named with specific patterns. Classes that follow certain principles. Comments removed because “code should be self-documenting.”

This misses the point. Clean code is not a style. It’s code that manages complexity effectively — that can be understood, changed, and extended without surprising consequences.

What Complexity Actually Costs

Every line of code has carrying costs. It needs to be understood before it can be changed. Changed before it can be trusted. Tested before it can be deployed. These costs compound.

Monolith vs Microservices: Starting With the Right Question

Mon, 06 Jan 2025 00:00:00 +0000

The monolith vs microservices debate has produced more heat than light over the past decade. Both sides have oversimplified. “Monoliths don’t scale” is demonstrably false — StackOverflow ran a monolith for years serving massive traffic. “Microservices are only for large teams” ignores the many small teams that have shipped them successfully.

The real question is not which architecture is better in the abstract. It’s which architecture fits your current constraints: your team size, your organizational structure, your operational maturity, and your actual scaling requirements.

Event-Driven Architecture: When Events Help and When They Hurt

Mon, 23 Dec 2024 00:00:00 +0000

Event-driven architecture has become fashionable, which means it’s being applied in situations where it doesn’t fit. Events are a powerful architectural tool for specific problems. They’re a significant operational burden when applied indiscriminately.

Understanding when events help and when they hurt requires understanding what problems they actually solve.

Events vs Commands

The distinction matters more than most tutorials acknowledge.

A command expresses intent: “place this order,” “cancel this payment,” “reserve this inventory item.” It’s addressed to a specific recipient and implies that recipient is responsible for handling it. Commands can be rejected. They have an expected response.

Java 17 to 21: Modern Java Is a Different Language

Mon, 16 Dec 2024 00:00:00 +0000

Java 21 is the current long-term support release as of late 2024, and it represents something unusual: a Java that looks substantively different from Java 8. Not just faster or more convenient — different in how you model domains and reason about concurrency.

This article focuses on the features that arrived between Java 17 and Java 21 (covered separately) and the cohesive picture they form together.

Pattern Matching for Switch (Finalized Java 21)

Pattern matching for instanceof arrived in Java 16. Java 21 extended pattern matching to switch — and this is where the power becomes apparent.

Modern Spring Boot Architecture: Beyond the Three-Layer Application

Mon, 02 Dec 2024 00:00:00 +0000

The three-layer architecture — controllers, services, repositories — is how most Spring Boot tutorials present application structure. It’s a reasonable starting point. It’s also a pattern that breaks down as applications grow.

The problems are predictable: services become God classes with hundreds of methods, repository calls leak into controllers, domain logic spreads across multiple layers, and changing anything requires understanding the entire application at once. The layered architecture doesn’t enforce boundaries — it suggests them. Suggestions decay under deadline pressure.

CI/CD Is a Feedback Loop, Not a Deployment Tool

Mon, 25 Nov 2024 00:00:00 +0000

Most CI/CD implementations optimize for the wrong thing. They treat the pipeline as a deployment automation tool — a mechanism for running tests and pushing artifacts to production. The tests pass, the deploy runs, work is done.

This framing misses the fundamental value of continuous integration and continuous delivery: compressing the feedback loop between writing code and understanding its consequences.

The faster that loop runs, the faster defects are caught, the smaller the blast radius of errors, and the more confidence engineers have when deploying. Everything else follows from this.

Architecture Decision Records: Making Technical Decisions Explicit

Mon, 11 Nov 2024 00:00:00 +0000

Every significant technical decision your team makes will be questioned later. When the original authors have left. When the context has changed. When someone proposes replacing the system. When a new engineer asks “why does this work like this?”

Most teams have no good answer to these questions. The reasons behind decisions live in people’s heads, in Slack threads that are impossible to find, or nowhere at all.

Architecture Decision Records are a lightweight practice that fixes this. They capture not just what was decided, but why — including what was considered and rejected. The investment is small. The return compounds over time.

Virtual Threads in Java 21: What They Solve and What They Don't

Mon, 04 Nov 2024 00:00:00 +0000

Virtual threads were the most anticipated Java feature in years. Project Loom’s promise was simple: write blocking code that scales like non-blocking code. Java 21 delivered them as a finalized, production-ready feature. They work. The caveats matter.

The Problem Virtual Threads Solve

Traditional Java concurrency has a fundamental constraint: platform threads are expensive. Each platform thread maps 1:1 to an OS thread. OS threads consume roughly 1MB of stack space by default and are expensive to create and context-switch.

Distributed Systems: The Problems You Get for Free

Mon, 28 Oct 2024 00:00:00 +0000

Every system that communicates over a network is a distributed system, and distributed systems fail in ways that single-process applications don’t. This is not opinion — it’s physics. Networks drop packets. Clocks drift. Services restart. Disks fail. These things happen regardless of how carefully you write your application code.

The teams that get distributed systems right don’t eliminate these failures. They design so that their systems remain correct despite them.

RAG Is Not a Database Query

Mon, 21 Oct 2024 00:00:00 +0000

Retrieval-Augmented Generation has become the default answer to “how do we make an LLM answer questions about our data.” The concept is simple enough to explain in one slide: embed your documents, store them in a vector database, retrieve the relevant ones at query time, pass them to the LLM.

The problem is that the one-slide version produces one-slide-quality results. Good RAG systems are significantly harder to build than the demos suggest, and the failures are often subtle — the system produces confident, plausible-sounding answers that are wrong in ways that are hard to detect without systematic evaluation.

The Modular Monolith: An Architecture Pattern That Deserves More Attention

Mon, 14 Oct 2024 00:00:00 +0000

The software industry has a microservices fixation. Over the last decade, “monolith” became almost a pejorative, and teams moved to distributed architectures before they had the scale, team size, or operational maturity to justify them.

The result has been widespread over-engineering: systems that are harder to understand, harder to debug, harder to change, and more expensive to operate — not because distributed systems are inherently bad, but because the problems they solve weren’t actually present.

Java 9 to 17: The Language Features You Should Actually Be Using

Mon, 07 Oct 2024 00:00:00 +0000

Java 8 was a turning point. Lambdas and streams changed the language substantially. Then came a long stretch where each release felt like maintenance work — modules in 9 were important but painful, and the subsequent releases improved the language incrementally without a clear headline.

That changed with Java 14–17. The features that landed in this window — records, sealed classes, pattern matching for instanceof, text blocks, switch expressions — are not conveniences. They change how you model domains and reason about code.

About

Mon, 01 Jan 0001 00:00:00 +0000

Engineering-first consultancy

dplabs is an independent software engineering and technology consultancy based in Amsterdam, Netherlands.

The work focuses on difficult technical problems: systems that need to scale significantly, architectures that have become hard to change, teams that need to make better technical decisions, and organisations that want to adopt AI in a way that actually delivers value.

How I work

Most consultancies promise transformation. I prefer to focus on specific, tractable problems and solve them well.

AI to Production

Mon, 01 Jan 0001 00:00:00 +0000

AI changed who can build software. It didn’t eliminate the need for software engineering.

Tools like Cursor, Lovable, Bolt, Replit, v0, ChatGPT, and Claude have done something remarkable: they’ve made it possible for a founder, product person, or entrepreneur with a clear idea to build a working application — without a team of engineers.

That’s a genuine shift. What used to take months and significant budget can now take days.

Consultancy

Mon, 01 Jan 0001 00:00:00 +0000

Helping engineering teams build systems that last

Your system works today. The question is whether it’ll hold up under 3× the load, after the team doubles, or when that critical service you’ve been papering over finally breaks.

I work with engineering teams on the problems that matter most: systems that are hard to change, architectures that don’t scale, reliability issues that are eating engineering time, and technical debt that’s slowing everything down.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

Fractional CTO

Mon, 01 Jan 0001 00:00:00 +0000

Senior technical leadership, without the full-time cost

You’ve built an engineering team. They’re capable. But somewhere along the way, the technical decisions have started to pile up, the architecture has drifted, and the team is spending more time fighting fires than building product. Or perhaps you’re scaling fast and the team needs someone who’s done this before.

A fractional CTO gives you experienced technical leadership — the kind that typically costs €200K+ per year as a full-time hire — on a part-time basis that fits your current stage.