diff --git a/README.md b/README.md
index 1621800..1f0c51b 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,13 @@
-# Git Practice
-A simple project to practice a few git/github workflows.  Replace the contents of this file with the contents indicated in the [instructions](./instructions.md).
\ No newline at end of file
+# Technical Debt and the Cost of Changing Software
+
+**Article:** [Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html) by Martin Fowler
+
+## What I Find Interesting
+
+What I find interesting about this article is that code quality affects how quickly a team can deliver future changes, even when the software already works. Fowler describes the extra effort caused by confusing code as interest on technical debt. That makes the tradeoff between shipping a feature and cleaning up its implementation easier to understand. A shortcut might save time today, but if every later change requires working around it, the team keeps paying for that decision. I think this is a useful way to discuss maintainability because it connects code structure to the actual work needed to develop a project.
+
+I also like the idea of improving code gradually in the areas that change most often. An awkward module that rarely changes may be less urgent than one that slows down every new feature. For a team project, this suggests making small, focused improvements as part of regular development instead of waiting for a complete rewrite. I would want those improvements to be easy for teammates to review, with clear commits and pull requests explaining why the changes help.
+
+## Comment from Krishiv Seth
+
+The interest metaphor is the part of Fowler's article I keep coming back to. Debt on a file that changes every week costs a lot. Debt on a file nobody has opened since 2019 costs close to nothing, so cleaning that file up is wasted work even though the code is ugly. That gives a team a real answer to the question "should we refactor this?" Ask whether the mess slows down the change you are about to make this sprint. If the answer is no, leave the mess alone. In a team project I would put that reasoning in the pull request itself, with one line naming which upcoming feature the cleanup makes easier.