Clean Architecture with Python

Intro

Max Kirchoff: As part of the GOTO Book Club, I'm here with Sam Keen today talking about Clean Architecture with Python. I think it's a pretty radical book that I picked up recently and was able to read. Sam, I'd love for you to introduce yourself and share what your impetus was to write this book.

Sam Keen: Thanks, Max. My name is Sam Keen, and I've been a software developer for 30 years now. I started just before 2000, so the entirety of my experience has been in that web era. I started in Java because back in 2000, if you wanted to write software for a company, Java was the go-to. But I think myself and a lot of people came to the conclusion that web development has got to be easier than that. So I shifted into PHP for quite some time, then rode the Ruby on Rails train for a while. But really, the last 8 to 10 years has been Python as my daily driver, trending into back-end web development. It really checks all the boxes for me.

I've worked across lots of variety of companies, from small startups—that's where I came across Max many years ago—to larger companies. The tail end of where I've worked so far includes Nike, Lululemon, and then AWS for about six years. Since then I've gone back full circle to freelance consulting and a bit of content creation.

The motivation to write the book came when Packt, the publisher, reached out to me in February 2024 with the pitch for doing a clean architecture book in Python. For me, it just really checked all the boxes. I've always been thoughtful of architecture. Clean resonated with me—those onion-type architectures—and I always wanted to write a book. So this is my first book, and it gave me the opportunity to dive deep on a topic. I appreciated that, so I dove in.

Max Kirchoff: I'm Max Kirchoff, CTO at Ginko. We have a very small engineering team, so I'm part principal engineer, part CTO, part technical product person. I have a career across technical products, product leadership, and engineering. Nowadays, I think I call myself a principal technologist, which is probably more confusing than anything. I like to get my hands dirty, but I would not call myself primarily a coder, which makes this whole age of AI even more interesting for someone like me.

The Core Principles of Clean Architecture with Python

I was really interested in this book because, Sam, as you mentioned, we worked together 15 years ago at what was, I think, one of the first social e-commerce platforms. We were exploring digital advertising, social media meeting e-commerce—so many cool ideas. The reason I was interested in the book is because working with you, Sam, I learned a ton of architecture principles that really made me successful throughout my career after that.

I remember we were working in PHP at the time, and you had built your own microservice architecture for RESTful APIs and wrote your own DSL. I really took to that, and it actually led me into working with Flask because it felt very Flask-like in a lot of ways in Python. So you wrote the book, and I was like, I've got to check this out. Sam is definitely a thought leader in this space. Recently I'm working pretty heavily in Python again, and I've got to say, I was really impressed. It was so funny to see again those principles from 15 years ago that you really embedded in me, even more fleshed out and explained and applied throughout the book.

I even saw some hilarious aspects of my own architecture in my current Python backends getting called out as like, hey, if you're having problems here, it's an indication that maybe your code's not in the best place. I definitely went from reading through here to immediately having things that I could apply into my own Python work right now, which I thought was great. What's really for you the core promise of clean architecture with Python?

Sam Keen: Thanks for that intro and the compliments. I appreciate that. The 30-second pitch comes down to dependencies and coming to grips with the fact that you need those. But if you don't approach those thoughtfully, dependencies can really start to fester in architectures that run for a long span of time and start to get those sharp edges. So the promise of the book is really just how to be thoughtful about that. Clean is not a rigid framework, it's just a set of principles. I tried to approach the book so that it's not an all-or-nothing situation. I'm going to show you all the principles, and then depending on your context, you can come to the conclusion about how to apply them.

Max Kirchoff: I felt it was a little shame-free and a little more empathetic to a practical engineer, senior engineer, or principal engineer working in a codebase that they have some control over, but there's also business needs. I love that because I wasn't going to be the villain in this story if I don't have everything implemented.

Python really prides itself on being simple and pragmatic. I remember this from when I first messed with Flask—just the time to get up and go, and the utilities, especially compared to a language like PHP. How does your book on clean architecture apply to those principles of being simple and pragmatic?

Sam Keen: That's a good question because when I heard the pitch for the book, I was like, okay, how am I going to do this and not have people think I'm trying to turn Python into Java? The original Robert Martin, Uncle Bob, pitch of clean was pretty much in the Java/C context. So a lot of people kept with that context and thought, oh, it's for these languages.

The goal was to have it resonate with a Python audience. Use what's there. So there's a whole chapter on type hints leveraging that. Sticking with what batteries are included in Python, so ABCs—abstract base classes—and even more so, we see people start to use protocols. Sticking to that, and then the overall messaging was that it's not a binary choice. The book will lay out all the principles and how to apply them in Python, but it also starts to talk about, okay, for certain contexts, here's how you might dial down the whole gamut of principles to make better sense.

Back to your question, there's definitely an effort throughout the book, and it was a learning process through the book writing it, of how to keep it Pythonic. Hopefully that resonates with readers.

Max Kirchoff: I know that you really deliberately did not want to write a "learn Python" book—there's a lot of them. In really focusing on architecture and developer experience, which I think for some people might not seem intuitively like those things are balanced together or come together, how did you think about striking that balance? Like writing something that was fundamentally about architectural principles, but really about making the development experience better and more usable?

Sam Keen: That was a tough balance. It is an architecture book in the title, but you want it to resonate with a wider audience, be applicable for a wide audience. To your point, there's plenty of "learn Python" books and resources out there. Real Python—I mean, if you're new and learning Python, go to that site, sign up, you'll be set. So I didn't see a need to fill that void, but there did seem to be less of a corpus that's architecture-focused in a Python context. So I felt I could contribute there.

I kept the book on that theme. If you look back to Uncle Bob's original book, there's really no code in that book, it's all theory. But that kind of makes sense because he was introducing the concept, so it had to stay theory-heavy. This book, I'm glad to say there are no UML diagrams in this book. That was a deliberate choice.

I tried to keep it approachable but bring in enough code so that when it made sense to show an example of a principle in the book using code, we definitely did that. But I kept it terse, just enough to show the principle. Then to balance that, there is a companion app—a to-do application—that evolves throughout the book. For each chapter, you can go to GitHub and find the more extensive functional code that represents that chapter. So for those who want a little more code, they can go to GitHub and see that. But I didn't want to cloud the book with pages and pages of fully rendered classes. Hopefully I struck a good balance.

Max Kirchoff: I know it did for me, for anyone who I think would think about programming architecture the way I do. I feel like I'm equal parts philosophical but also very practical and want to see how the sausage is made. Even just some of the inline examples you provided throughout the book, it was great because it helped me take that principle or that idea or that implementation and put something solid to it that I could see and understand. So I thought that was great. Kudos on that.

The Onion Model: Strict Inside, Flexible Outside

Max Kirchoff: I'd love to get into testing, but first I really wanted to talk about this principle, this idea of the strict inside, flexible outside. It feels crucial to your thoughts on it.

Sam Keen: You mentioned in the book that we're not saying you have to apply everything of clean to your context. It depends. The book starts out with base core principles. There's a whole chapter on SOLID, a whole chapter on type hints, these sorts of things. But then it gets into implementing.

If you've done a little research on clean, you've seen that bullseye diagram they call it, sort of an onion layer structure. There's those inner layers which are your core domain objects. Then you shift out into an application layer. There are four layers total. The application layer is how you apply the core business rules—how do you manage the state of those inner domain objects? Then you go out into the adapter layer, and beyond that is the frameworks layer. The adapter layer is to keep those inner two layers decoupled from that outer frameworks layer.

So that being the case, I tried to make the point in the book that if you're going to approach clean, focus on those internal layers first, because that's the most important. A lot of this comes from the thoughts from domain-driven design. Be very thoughtful about those inner layers, getting that design key. That's where you're having those conversations with the business partners to make sure you understand the business domain, and you're codifying that with little to no dependencies in the domain layer. No dependencies. In that application layer, few dependencies.

Then as you get out, how you apply that adapter layer is very context-specific. The book gets into that. First we're doing a CLI application, then a web application, then we get into how would you build a more straightforward API. That's where we start to talk about, okay, here's how you can kind of thin down that adapter layer because in this case, this context, we don't have a true view. So we can start to pull stuff out and not have accidental complexity, which is key to success in software development, I think.

Max Kirchoff: I was just having a conversation the other day with a colleague who was working on integrating a startup that had been acquired by their startup, and they had noted that someone had implemented GraphQL on top of a key-value store that was not a graph. Just going back to what you're saying, introducing complexity in that interface layer was just a very cute way to implement GraphQL that was totally unnecessary. It had nothing to do with those base domain objects—they're not actually on a graph. It just introduced a level of complexity that nobody wanted to support.

That's probably the biggest mistake I have ever seen—when you get into that interfacing application layer of just really mangling things up in ways that they just don't make a lot of sense. I think there's a way, especially in a startup where businesses are complex and things are changing and you're growing, where stuff is changing daily potentially. There's a way to hack it together and then go back and fix it. But I think most of us forget to go back and fix it, and it just gets deeper in the onion.

Testing is Key for Healthy Software Architecture

Max Kirchoff: Which I think is a great segue into testing. Personally, if I were to go into a new company tomorrow and they were like, hey, we have great architecture, I think the first thing I would say is, show me your tests. Because I think really great clean architecture is very testable. You make that point quite a bit. If you're unable to write tests in all the different layers of the testing pyramid, then there's something wrong with the architecture.

Your chapter on that, I think chapter eight, really stands out. I know that I myself struggle with this too. You build a project, you get moving, you need tests. You don't want to read architecture on the project because you realize, oh, I can't write unit tests for these things, I can't write integration tests for these. So you end up writing these end-to-end tests that are slow, flaky, have all of these problems. I deal with those all myself. Why do you feel like so many Python developers really struggle to get testing in a good place? Is it the architecture? Is it just the strategies that they're using?

Sam Keen: I think test friction is kind of a gauge of architecture health. Unfortunately, a lot of times it shows struggles in the architecture. If you think about it, a test is just a client of your codebase. It's a bit contrived, but that's what it is. So if it's difficult to write a test, that's kind of emoting that it's difficult to leverage your codebase. That can be a signal that there's an issue there. I always tell people if it's difficult to write a test, don't blame the test framework or the architecture—start to look into what's causing that friction.

To your point, you see this story all the time. It happened to me. I remember you go to Martin Fowler's blog and you see this test pyramid, and he's got plenty of corpus on the panacea of that sort of situation. It resonates with everyone. It's like, I should have this large base of fast unit tests, and then I know that integration and end-to-end tests are more expensive to maintain and brittle, so I should have fewer of those. But then they go to trying to apply that, and it's a struggle.

You see the story of, okay, let me write a unit test for the user model, which sounds simple enough. You get done and you've got 200 lines of setup code and mocks to mock out AWS and SQLAlchemy and all this stuff. Then you've got four lines that's changing state, make an assertion. The hope is that clean can help to alleviate that with some of the principles.

Max Kirchoff: I'd love to walk through that, especially the testing pyramid. It's very funny that you said the tests are clients because I literally have a quote here that I had pulled up in front of me from the book that is, "Tests are nothing more than clients of our code. If we find that our tests are difficult to write or require complex setup, this often signals that our production code needs improvement." I love that quote. It hurt my feelings quite a bit, but I'm sure after reading your book, I can help remediate that in our own Python.

I'd love to walk through that because it really felt like you're able to demonstrate the onion model and the testing pyramid and actually really combine them in the clean architecture to enable that kind of testing. I'd love to hear your walkthrough on those layers.

Sam Keen: I think at the core, clean is built on the shoulders of giants. The foundation of domain-driven design and SOLID principles, those kinds of things, are called out in the book. But another principle that it brought to the forefront is what they called the dependency rule. That's that bullseye diagram. It's just a simple rule that code in any given layer only has dependencies pointing in. So the domain layer, being the most inner layer, has by definition no dependencies because it's not viewing anything below, just what comes with Python. Then as you move out, the frameworks layer is the most outer, so it has visibility to all of it. That's why that's a bit more of a chaotic layer code-wise.

Back to testing. To get away from the test ice cream cone—what a lot of people call the inverted pyramid where you have a bunch of end-to-end tests and maybe someone tried to write a unit test at some point—what clean brings to this is, if you think about what we talked about earlier, that domain layer has no dependencies. So that example of testing the user model with 200 lines of setup, that all just goes away and your test is now four lines long. It's just build the user model, change state, assert the change.

That benefit continues out into the application layer. You're using, you're coding against interfaces. So you're using things like the repository pattern. The application layer doesn't know about SQLAlchemy. It just has a persistence interface that then in the adapter layer you have implemented a concrete SQLAlchemy class that implements that interface.

So in that case, the tests for the application layer are quite simple to mock. You can build something that implements that interface for the test. You can do that as a mock or you could even do that as a memory persistence implementation for tests that's much quicker. You don't have to boot up a Postgres database.

That's how it fulfills that promise of the test pyramid. It makes what is most important to your codebase—we talked about that strictness on the domain—very testable. So it enables that true test pyramid. But you still need integration and end-to-end tests on core features like checkout, things that are tied directly to revenue. But the population of those tests is vastly reduced. They're still brittle and expensive to maintain, but you have ten versus 200 of those. That's how clean makes the test pyramid possible.

Max Kirchoff: In reflecting on that, I have a bit of work to do myself. I think that leads me to my next thought. Working in a very small early startup, it feels like right now, not just in Python but in many languages, there's lots of packages and libraries that really try to add features and integrate a lot inside of a codebase that previously you would have had to have different dependencies managing different things.

I'll speak really specifically to myself. We use Supabase, which is great. We have auth through Supabase, we use RPC functions, we use edge functions, all kinds of things. Their client makes it very easy. They even have a vector client for AI/ML stuff. The problem I find myself having, going back to testing and the onion model, is I'm just implementing the Supabase client all over the place. Because it's fast, it's easy, has all the built-in stuff.

But I know, recognizing what you're saying about testability and longevity, there probably needs to be some abstraction there. My code shouldn't be using Supabase, it should be using a class or abstraction layer on top of Supabase that has Supabase inside of it as an adapter. How do you think about moving to that method and implementing clean architecture in the strategy you're talking about? Do you feel like there's a right balance of investing in that kind of complexity of architecture earlier on, or is it like just get functional and get moving and then worry about it later? How do you think about that?

Sam Keen: Bringing in a framework like clean, these sets of principles—to your point, you're making—it's adding layers and that's a form of complexity. So you have to thoughtfully apply that. I think overall, and I learned this as a key principle at AWS: What's the problem you're solving? I always start with that. It's all about risk.

In your case with Supabase, you're thinking about it, so there's probably some risk here. The way that's implemented is in your mind, you're attributing some sort of risk to that. But you've got to be pragmatic. Development teams only have so much capacity. So it's like, where does that coupling risk line up with other risks the company has? Think deeply about, okay, this seems to be a risk, but why? What's the problem?

The risk might be that, well, Supabase is the hotness for this year. Who knows? Is that risk factor enough to where it's beneficial for you to add that abstraction? To have a persistence interface where you've implemented a Supabase concrete class? That's the question.

If you're a company that's using Django and that's your model and it works well with your customer base, you're crushing it, keep doing it. You don't have a problem to solve, so there's not a reason to pull in clean at that point. I think the key is it's always start with what's the problem you're solving. Then it's all about lining up that discovered risk with all the others.

Clean Architecture in the Age of AI

Max Kirchoff: I'd love to talk about AI a little bit, because we're talking about Python, so I'm surprised it hasn't come up. I know that AI was sort of exploding as you were already finishing the book. I'd love to just understand how that may have changed as the AI explosion has happened and continued to happen. How do you feel like clean architecture applies to an AI-friendly codebase or makes it more AI-friendly?

Sam Keen: I think so. It's a crazy moving space. The timing was kind of odd. The book content was pretty locked in by January 2024. I tried to make much change at that point—the editors probably would have killed me. But that's after that when the reasoning models came to the forefront, and then shortly after that, agentic coding assistants beyond Copilot came out. So the landscape's drastically changed since I started the book. There's really no mention of AI in the book.

That being the case, though, to the question you asked about if you have or are considering a clean architecture, is that going to work well with coding agents or kind of work against? I think it's going to work well, because from the testing and experimentation I do—I do a lot of content creation around AI and coding agents—even though your agent has a context window of a million tokens, it has a very difficult time effectively and consistently leveraging that.

Chroma DB did a really good writeup on this recently called "Lost in the Middle." They talk about the challenges there. I've also done experiments with spec-driven development where you get these huge specs and they have trouble with it. So clean, again back to those layers—that's four layers. The first benefit is that you can scope problems and solutions by layer, so you can focus the AI on "let's work on the domain objects." That reduces that context and makes it more effective. Then you can shift over to the application layer, those sorts of things.

Another benefit is that it gives you a foundation. I think you could literally put this book in the context, but I'm not sure what would happen there. But you can use the book and related works to start to build that system prompt for guiding your architecture for your Claude Projects or agents in the cloud. I think building applications of significant breadth or size in 2025 with AI, you still need a plan and kind of a rulebook. So I think this works well with that, just as it would help humans build something.

I keep getting—and this is an answer I give this year, next year this can change—but what you can do to help the humans seems to really help the AI as well. So I think there's correlation there.

Max Kirchoff: One of the great benefits to a lot of the AI implementation, the agentic approaches to coding and implementation, is if you're working with it as an architect, it seems to be a much more effective way to work with it. Because it's a probabilistic machine, it can't do critical thinking and metacognition very well, if at all.

I was curious, do you feel similarly about the symbiosis there? How would you think about implementing clean architecture? Let's say I'm an architect or principal engineer, I'm just going to let the AI be the implementer—the golem—whether that's Cursor or Claude or whatever. What do you feel like is the best way to leverage clean architecture and Python? Is it me saying, here's the book in the RAG? Is it me saying, go ham, now here's the principles, can you adopt that code into these principles? How would you approach it?

Sam Keen: I think the kids are saying YOLO these days. To your question, how do you approach that? I think, and this is changing in the last few months, but it's shown that AI is a capable planning partner in addition to coding. You see a lot of—I think Amazon's latest IDE, Cairo, is fully based around spec-driven development.

So I think we're realizing that. People have kind of shot themselves in the foot building stuff really quick and it works but doesn't scale and has issues, security issues. So we're circling back and realizing that we can use AI to help build a thoughtful plan of how to approach the architecture. That still makes sense to do. The human as the domain expert is guiding that AI in building the plan, telling them what's working, what's not.

So we start there and then you can leverage its coding capabilities to do the boilerplate. Clean works well there. There's a lot of disruption in software development. A lot of developers are concerned they're going to lose the ability to write code. Here you can still invest in writing out those domain objects, those interfaces. That makes sense for your company because you as a human best know that. But then the boilerplate of implementing those interfaces—like, okay, here's the persistence interface, Claude, go implement a Postgres adapter that respects that interface—that's the not-as-exciting work. So that's something you can shift off to an AI. I think an AI is more capable of following that well-scoped plan versus just saying "go build an application."

Max Kirchoff: That's great. I appreciate that. In many ways, I think part of the reason—I'm just going to lay on the praise for your book—it is clean architecture for Python, sure, and I know you didn't invent clean and application, but I think some of the thinking here is really a guidebook on being a principal engineer in some ways. Even what you just said, weighing the risk against adaptability, how to move fast. I mean, that's the thing, especially in the startup world, but I think that's true in large enterprises too. Being able to speak to that and think like that is critical. I appreciate that quite a bit.

Max Kirchoff And, like, even what you just said, weighing the risk against, you know, adaptability, how to move fast. I mean, that's the thing, especially in the startup world. But I think that's true in large enterprises, too. It's like being able to speak to that and think like that is critical. So yeah, I appreciate that quite a bit. I love to talk about AI a little bit, because, we talked about Python. Surprised hasn't come. I know we're talking about Python.

Sam Keen It's 20, 25. Yeah.

Max Kirchoff I know that, that, you know, I was sort of exploding as you were already finishing the book and, I I'd love to just understand, like, how that may have changed as the AI explosion has happened and continued to happen. So, like, how do you feel like the clean architecture applies to, like an AI friendly AI code base? It's more AI friendly and friendly.

Sam Keen Yeah, I think so. And again, it's a crazy moving space. The timing was kind of odd. The book content was pretty locked in, like January 2024. I tried to make much change at that point. The editors probably would have killed me so much that, but again, that's after that is when kind of the reasoning models came to the forefront. And then shortly after that it's or a genetic coding assistance beyond, could complete came out. So yeah, the landscape's drastically changed since I started the book. There's really no mention of AI in the book. That being the case, though, to your to the question you asked about if you have or considering a clean architecture, is that going to work well with, coding agents or kind of work against.

Yeah. And I think I think, yeah, it's it's going to work. Well, because I see the testing I do and I, I mentioned to do content creation. So a lot about this experimentation in AI, coding agents, those sorts of things. So the experimentation I see is that even though your agent has a context, when you have a million tokens, it's it has a very difficult time effectively and consistently leveraging that. So, chroma DDB did a really good write up on this recently called, context raft. They talk about, you know, the challenges there. So and in I've also I've done experiments with specter in development which you see issues there with you get these huge specs and they, they, I had trouble with it. So clean again back to those layers. That's four layers. That's like the first kind of, benefit is that you can scope, problems, solutions by layer so you can focus the AI on let's work on the domain objects. And that reduces that context and makes it more effective. And they can shift over to the application layer, those sorts of things. Another benefit is that,

It, it gives you a foundation. Again, we talked about huge context. So I think you could literally put this book in the context, but the effect of that do that. I'm not sure what would happen there. So but you can use the book and related works to kind of start to build that system prompt, for guiding your architecture. You know, that plot in detail or agents in the cloud. So I think it's building, applications of significant breadth or size in 2025 with AI, you still need a plan and kind of a rule book. So I think this works well with that, just as it would help humans build something. You see, I keep getting and again, this is an answer I give this year. Next year this can be yeah. These are so what you can do to help the humans seems to really help. The AI is also. So I think there's, correlation there.

Max Kirchoff Yeah. Yeah for sure I know you know, again, who knows when this will change. But one of the great benefits that I think, to a lot of the AI implementer is AI genetic approaches to coding and implementation is like, if you're working with it as an architect, it seems to be a much more effective way to work with it. Because, you know, it's a probabilistic machine. It can't do critical thinking. And metacognition very well, if at all. And I was curious, like, what do you do you feel similarly about sort of the symbiosis there and, and like how I guess, how would you think about implementing clean architecture? Let's say I'm, architect, principal engineer. I'm just going to let the AI implement implementer golem, you know, whether that's cursor or cloud code or whatever. What do you feel like is the best way to leverage, clean architecture? Python? Is it me saying, here's the book in the rag? Is it me saying, go ham? Now here's the principles. Can you, like adopt that code into these principles? How would you approach it?

Sam Keen Ham, that one's new to me. Is that like you? Oh, yeah.

Max Kirchoff Yes.

Sam Keen Okay. I want to look that one up. It's very old.

Max Kirchoff It's an old, old expression. No, it's not a new one.

Sam Keen I got it. Yeah, I think the kids are saying yolo. So your question, how do you approach that? I think, and again, this is changing in the last few months, but it's shown that AI is a capable, planning partner. In addition to coding. So and you see a lot of, I think Amazon's latest IDE, Cairo is like fully based around spec driven development. So I think we're realizing that. And again, people with kind of shot themselves in the foot and building stuff really quick and it works but doesn't scale and has issues, security issues. So we're kind of circling back and realizing that, well, we can use AI to help build a, thoughtful plan of how to approach the architecture. So that still makes sense to do that. And again, the human as the domain expert is guiding that AI to building the plan, telling them what's what's working, what's not. So we start there and then and then you can, leverage its identity coding capabilities to kind of do the boilerplate, and claim works. Well, there is, you know, there's a lot of disruption in software development. A lot of developers are concerned they're going to lose the ability to write code. So, here you can still invest in writing out those domain objects, those interfaces. That makes sense for your company because you as a human best know that. But then the boilerplate of implementing those interfaces like, okay, here's the persistence interface, Claude, go implement, a Postgres that respects that interface. So and that's, you know, that's kind of the not as exciting work. So that's something you can shift off to an AI. It's more I think an AI is more capable of following that. Well scoped plan versus just saying go build an application.

Max Kirchoff Yeah, yeah, I, agree. I'd love to sort of close, with just, one more quick question. I really appreciate the time team. This has been really great to chat with you about this. And I feel like we could probably tighten up on our, but whether whether someone's, you know, principal engineer at a really big tech company, a hacker at a scrappy startup. What do you feel like is just the one takeaway from the books that they they have?

Sam Keen I think it's a kind of a summary answer to what we talked about in the book. It's there in them today. It's really that for a lot of it was for me to when I first came across, you know, that recalibration of the value of your product, which is a software application, is in the understanding and the, codification. I'll make up a word of that domain. It's those conversations with your business partners yourself. If you're part of that business tier, and making sure that that's clear and concise and isolated. And then the other part of that recalibration is that flask or Django or, you know, Acme Super Base, they're all just details. And again, I remember in, Bob's book, when I first read that, I was like, oh, that's not the case. But then it's like, these things are important. But then he he convinced me as I read through the books like, yeah, they're just details. They're going to change. It's the value is in. What does a customer mean to you? What does a product mean to you? How does the software manage that state?

Max Kirchoff Awesome. Yeah, I appreciate that and I do I think that rings true for me too, in my experience, is especially if you think about working in the data world, all of those dependencies are just, you know, they're they're, they're fun. They have fun tools and all kinds of things with, you know, whatever that tool is. But inevitably you're gonna have to replace it at some point because the scale you're operating at or whatever you're doing is going to change enough that like the fun part of that changes. And just having those layers to separate that is critical. Yeah. So yeah, I appreciate it. Sam, thanks so much for chatting today. And, I hope folks check out your book because it is deeply insightful.

Sam Keen Thanks, Max. You know, I had a great time. Appreciate it. Thank you.