diff --git a/content/en/building/overview.md b/content/en/building/overview.md
index a2e2195..4ba7b5a 100644
--- a/content/en/building/overview.md
+++ b/content/en/building/overview.md
@@ -12,7 +12,7 @@ This chapter will therefore guide you through how to manage and measure what we
 
 There is a wealth of information online about the [Software Development Lifecycle](https://en.wikipedia.org/wiki/Systems_development_life_cycle). Consequently, there is some variation in terms of the various steps of the lifecycle. We do not take an opinionated approach on this; for pragmatic reasons, we will use these high-level steps in the rest of of this chapter:
 
-<img src="img/sflc.svg" class="mx-auto" style="min-height: 2rem;"/>
+<img src="/img/sflc.svg" class="mx-auto" style="min-height: 2rem;"/>
 
 ### Existing frameworks: DORA Metrics
 
@@ -58,4 +58,4 @@ Not suprisingly, the signals we favor display opposite features compared to the
 
 - **It focuses on inputs**, in the form of bottlenecks, slow-downs and other inefficiencies at every step of the SDLC. This type of metric is more specific and actionable, and usually harder to misuse or "game". It also clearly puts the focus on improving the developer experience as opposed to measuring individual performance.
 - **Its definition is simple to understand**. For someone with "average context" about the situation at hand, it should be easy to intuitively understand how the metric is defined and what may cause it to move in different directions. Again, it optimizes for actionability and it reduces the potential for "interpretation battles".
-- **It supports drill-downs**. The metric should be easy to aggregate at various resolutions (team, department, organization) and it should support multiple ways to filter or group (e.g. by repository, by service, etc.). This is critical in terms of making it easy to debug problems and iterate on solutions.
\ No newline at end of file
+- **It supports drill-downs**. The metric should be easy to aggregate at various resolutions (team, department, organization) and it should support multiple ways to filter or group (e.g. by repository, by service, etc.). This is critical in terms of making it easy to debug problems and iterate on solutions.