Your daily does of #DotNet videos. We cover a wide variety of topics like #AspNetCore, #Blazor, EntityFramework Core, software architecture and so much more. You'll also find here regular live coding sessions.
So, how do you grow from engineer → architect → and beyond?
I’ve been through that journey and here’s the truth:
👉 Most people focus on the WRONG thing.
The transition isn’t about how much code you write, how many design patterns you know, or how many programming books you’ve read.
It’s about how you think. It's about systems and people.
Here are the 3 biggest mindset shifts that will help you get there 👇
🧠 1️⃣ From solving tickets → to defining problems.
As a developer, you execute.
As an architect, you shape what should exist.
As a CTO, you define why it should exist in the first place.
Your leverage comes from clarity, not lines of code. Whatever you’re building, try to see it through these lenses:
execution → design → strategy.
If “engineering” = “writing code” in your mind, you’ll never reach the next level.
⚙️ 2️⃣ From building systems → to building systems that build systems.
Architecture isn’t about elegance, it’s about repeatability!
The best architects don’t design software once; they design environments where great software emerges consistently.
And that’s where leadership comes in, because people are part of that “system that builds systems.” Your mission is to drive synergy, not confrontation.
🚀 3️⃣ From being right → to getting buy-in.
You can have the perfect design, but if no one follows it, it collapses.
Real influence is when others carry your principles even when you’re not in the room. That’s what true thought leadership looks like.
These are the shifts that actually matter. Learn them early and you’ll move faster in one year than most people do in a decade.
During my 15 years in tech, I’ve seen this world from many angles. 💻
✅I've seen how supporting services and consultancy are run
✅I wrote code.
✅I designed systems.
✅I learned from incredible people.
✅I’ve been part of building products that made a real difference.
✅I've been lucky enough to lead the way for a lot of incredible people
And in the last few years, I was lucky enough to be on the forefront of infusing AI, not only into the products we built, but also into the way we engineered them. 🤖
For a while now, I’ve felt the pull to take the next step: to take full ownership of strategic technology decisions. The idea of composing my own symphony instead of just playing violin in a piece that was written by somebody else was very appealing.
I tried to make that happen many times and in many ways AND I FAILED!
But now it seems everything aligned:
☑️the right idea 💡
☑️the right people to build it 👥
☑️and the right people to back it 💰
So after 15 years of stability, I made the leap. And after 15 years of being employed I transitioned to be my own boss.
There’s joy.
There’s excitement.
And yes, a bit of anxiety too. 😅
But that’s okay.
Because the last two years have been about learning self-leadership: from being overweight my entire life to completing two marathons 🏃♂️🏅 and two ultra-marathons this year.
That journey taught me how to stay on course, even when it feels impossible. It has taught me that consistency is more important than volume and that discipline is more important than motivation. And I think these are exactly the lessons I still needed to learn and most of what I learned will actually apply in this new endeavor.
💪100 people already joined my Substack in the first week.
And I’m not writing “newsletters.”
I’m documenting what it actually means to be a founding CTO - the architecture, the AI workflows, the trade-offs, the parts that hurt, navigating investor due dilligence, balancing costs and much more.
Thank you for being early. The next chapter is coming fast. More to be announced on Nov 3rd!
🙏 If you are one of the early subscribers and found any value in the first newsletter you received, please like and share this post! I'll remain eternally grateful!
When you’re the only engineer, the temptation is to build features fast.
I did the opposite.
My first weeks as a CTO were spent creating the foundation where high-quality speed is possible and where AI agents actually help instead of creating chaos.
Over the last 15 years, I’ve been lucky to experience engineering from many angles.
💻 I wrote code for products that scaled.
🧩 I became the person who others asked, “How should we build this?”
🏗️ I learned how architecture guides teams, not just systems.
🤖 And recently, I’ve been part of shaping how engineering operates at scale, including how AI changes both what we build and how we build it.
That combination changed how I see my work:
It’s not just about building software anymore.
It’s about building the system that builds the software — the teams, the practices, the clarity.
And I’ve realized… I’m ready to take full ownership on that.💪
🚀 So, I'm starting my next chapter as a CTO and co-founder of a startup that will change the life of 1 million people.
🔥 But here's the thing: I WANT TO BRING YOU ALONG ON THIS JOURNEY.
✅The real conversations.
✅The reasoning behind decisions.
✅The experiments that work — and the ones that don’t.
If you’re curious about what it looks like to build engineering organizations that think clearly, move fast, and scale intelligently — stay close.
I’ll be sharing the journey here and in more depth on my new newsletter ↓
I’ve been building systems AI-assisted for a while now — and here’s the biggest lesson: 👇
❗The quality of what you get from AI depends 90% on the context you give it.
💡 So instead of writing better prompts, I started writing better context.
In every repo I have multiple CLAUDE.md files:
🧩 At the root → high-level architecture, dependencies, testing rules, CI/CD expectations.
🧩 Per subfolder (like iac/, backend/, frontend/) → language-specific guidelines, design patterns, and “what good looks like” examples.
🧩 Per domain → business context, boundaries, and key entities.
This way, when I ask the model to add a feature or fix something, it already understands the system — not just the syntax.
The result?
✅ Less prompting.
✅ More reasoning.
✅ Consistent code that feels like it came from the same engineer.
The real productivity boost isn’t from writing faster. It’s from teaching your AI how your system thinks.
Codewrinkles
So, how do you grow from engineer → architect → and beyond?
I’ve been through that journey and here’s the truth:
👉 Most people focus on the WRONG thing.
The transition isn’t about how much code you write, how many design patterns you know, or how many programming books you’ve read.
It’s about how you think. It's about systems and people.
Here are the 3 biggest mindset shifts that will help you get there 👇
🧠 1️⃣ From solving tickets → to defining problems.
As a developer, you execute.
As an architect, you shape what should exist.
As a CTO, you define why it should exist in the first place.
Your leverage comes from clarity, not lines of code. Whatever you’re building, try to see it through these lenses:
execution → design → strategy.
If “engineering” = “writing code” in your mind, you’ll never reach the next level.
⚙️ 2️⃣ From building systems → to building systems that build systems.
Architecture isn’t about elegance, it’s about repeatability!
The best architects don’t design software once; they design environments where great software emerges consistently.
And that’s where leadership comes in, because people are part of that “system that builds systems.” Your mission is to drive synergy, not confrontation.
🚀 3️⃣ From being right → to getting buy-in.
You can have the perfect design, but if no one follows it, it collapses.
Real influence is when others carry your principles even when you’re not in the room. That’s what true thought leadership looks like.
These are the shifts that actually matter. Learn them early and you’ll move faster in one year than most people do in a decade.
The technical skills get you started. The strategic mindset keeps you growing.
#Leadership #CTO #Engineering #Architecture #CareerGrowth #BuildInPublic
14 hours ago | [YT] | 1
View 1 reply
Codewrinkles
The hardest part about leading in tech right now isn’t AI. It’s focus! 🎯
Everyone’s chasing new tools, frameworks, and features. Every week, there’s a new “must-use” model or product.
But real progress rarely comes from adding more. It comes from cutting noise, until only what matters remains.
As engineers, we often think in terms of velocity. But as leaders, what really matters is direction.
In the last few months, I’ve learned that focus is a skill.
It’s built the same way as endurance, one disciplined decision at a time.
Because in the age of AI, attention is the new leverage. 🧠
#Leadership #CTO #AI #Engineering #Focus #BuildInPublic
1 day ago | [YT] | 8
View 1 reply
Codewrinkles
During my 15 years in tech, I’ve seen this world from many angles. 💻
✅I've seen how supporting services and consultancy are run
✅I wrote code.
✅I designed systems.
✅I learned from incredible people.
✅I’ve been part of building products that made a real difference.
✅I've been lucky enough to lead the way for a lot of incredible people
And in the last few years, I was lucky enough to be on the forefront of infusing AI, not only into the products we built, but also into the way we engineered them. 🤖
For a while now, I’ve felt the pull to take the next step: to take full ownership of strategic technology decisions. The idea of composing my own symphony instead of just playing violin in a piece that was written by somebody else was very appealing.
I tried to make that happen many times and in many ways AND I FAILED!
But now it seems everything aligned:
☑️the right idea 💡
☑️the right people to build it 👥
☑️and the right people to back it 💰
So after 15 years of stability, I made the leap. And after 15 years of being employed I transitioned to be my own boss.
There’s joy.
There’s excitement.
And yes, a bit of anxiety too. 😅
But that’s okay.
Because the last two years have been about learning self-leadership: from being overweight my entire life to completing two marathons 🏃♂️🏅 and two ultra-marathons this year.
That journey taught me how to stay on course, even when it feels impossible. It has taught me that consistency is more important than volume and that discipline is more important than motivation. And I think these are exactly the lessons I still needed to learn and most of what I learned will actually apply in this new endeavor.
I can’t wait to share what’s coming next. 👀
#Leadership #CareerGrowth #CTO #AI #PersonalDevelopment #BuildInPublic #Technology
2 days ago | [YT] | 9
View 2 replies
Codewrinkles
💪100 people already joined my Substack in the first week.
And I’m not writing “newsletters.”
I’m documenting what it actually means to be a founding CTO - the architecture, the AI workflows, the trade-offs, the parts that hurt, navigating investor due dilligence, balancing costs and much more.
Thank you for being early. The next chapter is coming fast. More to be announced on Nov 3rd!
🙏 If you are one of the early subscribers and found any value in the first newsletter you received, please like and share this post! I'll remain eternally grateful!
If not, don't miss out!👇
architecttocto.substack.com/subscribe
#BuildInPublic #CTO #AI #EngineeringLeadership
3 days ago (edited) | [YT] | 10
View 0 replies
Codewrinkles
Quality has always mattered in engineering.
But in the age of AI-assisted development… quality matters more than ever.
💡 You can’t expect AI agents to write safe, scalable code if you haven’t built the guardrails first.
The foundations that enable speed today are things like:
✅ Strong automated testing
✅ Proven architecture patterns
✅ Continuous security checks
✅ Clean designs and reusable components
✅ CI/CD with real quality gates
❓Are these concepts new? Of course not.
But for AI-assisted engineering, they act as feedback loops.
Which means:
☑️ If you have quality guardrails, AI will scale quality
☑️ If you have chaos, AI will scale chaos
So why do many projects still lack quality?
❗Because quality used to be expensive upfront.
But now - with AI coding assistants - we can build quality faster than ever. Even around legacy or brownfield systems.
We did exactly this at my former workplace - on 30-year-old core systems, written in a niche language (ABL), using niche technology.
💪And the impact was real.
So before worrying about how AI writes code… ask how your system keeps code good.
AI doesn’t create speed.
Quality creates speed.
And AI amplifies whatever you already have. 🚀
Quality or chaos - that part is up to you.
#AI #Engineering #Quality #SoftwareDevelopment #CTO #FutureOfWork
4 days ago | [YT] | 5
View 3 replies
Codewrinkles
When you’re the only engineer, the temptation is to build features fast.
I did the opposite.
My first weeks as a CTO were spent creating the foundation where high-quality speed is possible and where AI agents actually help instead of creating chaos.
I just wrote about why that matters, and what I’m learning from building this way: 👇
architecttocto.substack.com/p/engineering-alone-bu…
If you care about scalable engineering from day one, this might be worth your time. And make sure to subscribe to not miss any future insights.
#Engineering #AI #CTO #StartupLife
6 days ago (edited) | [YT] | 10
View 1 reply
Codewrinkles
Over the last 15 years, I’ve been lucky to experience engineering from many angles.
💻 I wrote code for products that scaled.
🧩 I became the person who others asked, “How should we build this?”
🏗️ I learned how architecture guides teams, not just systems.
🤖 And recently, I’ve been part of shaping how engineering operates at scale, including how AI changes both what we build and how we build it.
That combination changed how I see my work:
It’s not just about building software anymore.
It’s about building the system that builds the software — the teams, the practices, the clarity.
And I’ve realized… I’m ready to take full ownership on that.💪
🚀 So, I'm starting my next chapter as a CTO and co-founder of a startup that will change the life of 1 million people.
🔥 But here's the thing: I WANT TO BRING YOU ALONG ON THIS JOURNEY.
✅The real conversations.
✅The reasoning behind decisions.
✅The experiments that work — and the ones that don’t.
If you’re curious about what it looks like to build engineering organizations that think clearly, move fast, and scale intelligently — stay close.
I’ll be sharing the journey here and in more depth on my new newsletter ↓
✉️ Subscribe here: lnkd.in/d-ssEkWj
Also, I'll reveal more about the startup on November 3rd, so stay tuned! 👀
hashtag#Engineering hashtag#Leadership hashtag#CTO hashtag#SoftwareDevelopment hashtag#CareerGrowth hashtag#Architecture hashtag#AI
1 week ago | [YT] | 16
View 0 replies
Codewrinkles
Here's what I've learned during the past year as divisional Software Architect at The Access Group 👇
⚙️ Complexity compounds quietly.
If you design a sophisticated architecture for a product that doesn’t need it yet,
you’re not being visionary — you’re being expensive.
I’ve seen apps with a few hundred users burning five figures monthly in cloud costs,
just because the setup looked enterprise-grade.
Keep it simple until the pain tells you otherwise.
—
🧩 Architecture is communication.
A great architecture isn’t something you enforce — it’s something people believe in.
Every design needs buy-in — from the CTO to the newest dev.
Without that, it’ll hold only as long as you’re around to police it.
—
🧠 Testing is continuity.
Tests aren’t just about confidence — they’re the bridge between past intent and present change.
They let teams move fast without losing collective memory.
—
🤝 Scaling teams > scaling code.
Code scales with rules.
Teams scale with trust.
The best systems I’ve seen weren’t the most advanced —
they were the ones everyone understood and cared to protect.
—
These are the things I wish I’d understood earlier.
They changed the way I think about architecture, leadership, and building in general.
#SoftwareArchitecture #Engineering #Leadership #Scalability #TechStrategy
1 week ago | [YT] | 19
View 0 replies
Codewrinkles
I’ve been building systems AI-assisted for a while now — and here’s the biggest lesson: 👇
❗The quality of what you get from AI depends 90% on the context you give it.
💡 So instead of writing better prompts, I started writing better context.
In every repo I have multiple CLAUDE.md files:
🧩 At the root → high-level architecture, dependencies, testing rules, CI/CD expectations.
🧩 Per subfolder (like iac/, backend/, frontend/) → language-specific guidelines, design patterns, and “what good looks like” examples.
🧩 Per domain → business context, boundaries, and key entities.
This way, when I ask the model to add a feature or fix something, it already understands the system — not just the syntax.
The result?
✅ Less prompting.
✅ More reasoning.
✅ Consistent code that feels like it came from the same engineer.
The real productivity boost isn’t from writing faster. It’s from teaching your AI how your system thinks.
#SoftwareEngineering #AI #Architecture #CleanCode #DevTools
2 weeks ago (edited) | [YT] | 12
View 2 replies
Codewrinkles
The most underrated skill in the AI era isn’t prompting. 👇
It’s abstraction — the ability to move between detail and meaning.
For decades, we’ve built software by abstracting complexity.
💡 Now, we’re learning to abstract reasoning.
That’s the real shift — and it’s going to separate those who make sure to acquire this skill from those who don't.
❗ In other words, AI won't replace your job; it will redefine what your job is!
❓ Where do you think engineers will need to grow most in this new world — technical depth or systems thinking? 👇
#AI #SoftwareEngineering #Leadership #Technology
2 weeks ago (edited) | [YT] | 11
View 0 replies
Load more