diff --git a/README.md b/README.md
new file mode 100644
index 0000000..dd4a4d6
--- /dev/null
+++ b/README.md
@@ -0,0 +1,39 @@
+# eulerbooks
+This is a collection of Jupyter notebooks containing solutions and discussions
+for the first 100 [Project Euler problems](https://projecteuler.net) using
+[SageMath](https://www.sagemath.org).
+
+My main goal with these notebooks is not simply to provide working code for
+solving the problems. Frequently, solutions to these problems are short, but
+they're not always easy to follow without understanding some important
+mathematical principles. Therefore, my aim is to provide insight into the
+underlying algorithms and mathematical concepts that make an efficient solution
+possible. I personally find that these topics are frequently even more
+interesting than the problems themselves, which I see as mainly existing to
+provide situations to apply the concepts after learning about them. In short,
+it's more about the journey, not the destination, so these notebooks mainly
+exist to discuss the former.
+
+## Approach
+Frequently, either Python or SageMath provide functions and libraries that make
+it trivially easy to write a solution. I don't have a problem with presenting
+solutions that use these, since for practical purposes, it's better to use
+what's already available than to reinvent the wheel. It also tends to lead to
+code that is easy to read and understand, which is the best kind of code.
+
+However, when a function already exists that does the heavy lifting, I also
+tend to provide my own basic implementation and an explanation of why it works.
+This is especially true if a solution or algorithm is based off of an important
+mathematical concept that is not especially intuitive.
+
+When not especially tedious, I like writing up solutions that do not require
+programming at all, since these approaches often require interesting
+mathematical techniques.
+
+Another thing to note is that I don't prioritize a solution's performance above
+all. When a solution is fast enough (using Project Euler's own "one-minute
+rule" as a rule of thumb), I instead usually focus on making the code easy to
+read. You can basically always optimize, but there are frequently diminishing
+returns, and it tends to negatively impact readability. Once a solution is fast
+enough to solve the problem at hand, I only consider optimizing further if the
+concepts are reusable.