Let me start with a confession: I haven’t built software from scratch in over a decade. And you know what? Neither have you!
Early in my career, I worked at a company that built everything themselves. Authentication? Custom. Web framework? Hand crafted. Even the CI/CD toolchain was custom written highly specific to that company built over the years. With this custom built stack, it took many months to launch a product. Any new member joining the team would need weeks and months to get up to speed with the tech stack. When the product finally went live, it didn’t get the adoption we wanted. The whole tech stack became fragile, and we faced many production issues as the number of users increased to 100k+. Turns out, rebuilding the wheel is expensive, slow, and often… square.
Years later, I led a team and we were building a system to handle millions of transactions daily. This time, we assembled things together instead of building from scratch. The entire trajectory was different and refreshing. We could ship much faster, tune configuration of components to make it work for growing scale and overall, make our software easier to change.
The car factory analogy (you knew this was coming)
Imagine a car company that mines its own ore, refines steel, and hand-carves pistons. Now, check if any such company exists in the real world? No. Because car makers know what works better. Car makers assemble instead of building from scratch. They source engines from supplier A, tires from supplier B, and infotainment systems from supplier C. So, what’s their job then, you might ask? Integrate, test, and ensure the whole machine works end to end.
Modern Software is no different. Think about it:
Cloud providers (AWS, Azure, GCP) are your engine suppliers.
Kubernetes is the chassis.
React, TensorFlow, FastAPI are your tires, brakes, and GPS.
You may not exactly agree with above analogies, but you get the point. Your role isn’t to forge steel. It’s to pick the right components, bolt them together, and make sure the ride is smooth. The same thing applies in software.
What “assembly” looks like in practice
For one of our recent production use cases, we needed a real-time analytics dashboard. Instead of writing things from scratch, we used pre-built components - both open source and cloud specific, to build the system end to end.
We shipped in 3 months. It worked well for 2 million users. Granted, we had some production issues, but all of those were minor issues that we could quickly fix ourselves with just config changes.
Big companies like Netflix or Spotify assemble too. Netflix runs on AWS. Spotify uses Kafka for streaming. They focus on what makes them unique - recommendation algorithms and UX, not the plumbing.
But wait - what about control?
I get it. Dependency on third-party component feels risky. I once inherited a system held together by an outdated open-source library. When it went unsupported, we spent quite some time untangling it.
Here’s what I learnt: treat dependencies like car parts.
Audit them. Would you buy brakes from a supplier with no crash tests?
Plan for swaps. Design systems so that replacing a component like a database or third party provider is like changing a tire. Straightforward, with predictable API abstractions and most importantly, one that does not require a rewrite.
Own the glue code. The magic isn’t in the parts; it’s in how they’re wired. Spend time understanding how components interact and design the right abstractions.
When should you build from scratch?
Rarely, but sometimes. For example:
If your competitive edge is the tech (e.g. Google’s search algorithms)
If no existing tool solves your problem (e.g. SpaceX’s flight software)
If you know what you’re doing (e.g. you know that building from scratch will give you a 10x price-performance ratio)
For 95% of remaining cases, though? Assemble.
The bigger picture
Software assembly isn’t lazy, it’s strategic. It lets you:
Move faster (why write an authentication library from scratch in 2025?)
Scale smarter (leverage cloud providers’ global infrastructure)
Focus on what matters (your IP, not the boilerplate)
But it requires a mindset shift. Engineers love building. Leaders love efficiency. Your job is to balance both.
Final thought
Next time your team proposes a “ground-up rewrite” or “let’s built this from scratch”, ask: Are we building a car… or just assembling one?
Because you can move really fast, not by building but by assembling things together.
P.S. If you’re moving slow due to hand-coding auth systems or rolling your own CI/CD tool, let’s talk. I’ll buy the coffee and fix things for you :D
Let me start with a confession: I haven’t built software from scratch in over a decade. And you know what? Neither have you!
Early in my career, I worked at a company that built everything themselves. Authentication? Custom. Web framework? Hand crafted. Even the CI/CD toolchain was custom written highly specific to that company built over the years. With this custom built stack, it took many months to launch a product. Any new member joining the team would need weeks and months to get up to speed with the tech stack. When the product finally went live, it didn’t get the adoption we wanted. The whole tech stack became fragile, and we faced many production issues as the number of users increased to 100k+. Turns out, rebuilding the wheel is expensive, slow, and often… square.
Years later, I led a team and we were building a system to handle millions of transactions daily. This time, we assembled things together instead of building from scratch. The entire trajectory was different and refreshing. We could ship much faster, tune configuration of components to make it work for growing scale and overall, make our software easier to change.
The car factory analogy (you knew this was coming)
Imagine a car company that mines its own ore, refines steel, and hand-carves pistons. Now, check if any such company exists in the real world? No. Because car makers know what works better. Car makers assemble instead of building from scratch. They source engines from supplier A, tires from supplier B, and infotainment systems from supplier C. So, what’s their job then, you might ask? Integrate, test, and ensure the whole machine works end to end.
Modern Software is no different. Think about it:
Cloud providers (AWS, Azure, GCP) are your engine suppliers.
Kubernetes is the chassis.
React, TensorFlow, FastAPI are your tires, brakes, and GPS.
You may not exactly agree with above analogies, but you get the point. Your role isn’t to forge steel. It’s to pick the right components, bolt them together, and make sure the ride is smooth. The same thing applies in software.
What “assembly” looks like in practice
For one of our recent production use cases, we needed a real-time analytics dashboard. Instead of writing things from scratch, we used pre-built components - both open source and cloud specific, to build the system end to end.
We shipped in 3 months. It worked well for 2 million users. Granted, we had some production issues, but all of those were minor issues that we could quickly fix ourselves with just config changes.
Big companies like Netflix or Spotify assemble too. Netflix runs on AWS. Spotify uses Kafka for streaming. They focus on what makes them unique - recommendation algorithms and UX, not the plumbing.
But wait - what about control?
I get it. Dependency on third-party component feels risky. I once inherited a system held together by an outdated open-source library. When it went unsupported, we spent quite some time untangling it.
Here’s what I learnt: treat dependencies like car parts.
Audit them. Would you buy brakes from a supplier with no crash tests?
Plan for swaps. Design systems so that replacing a component like a database or third party provider is like changing a tire. Straightforward, with predictable API abstractions and most importantly, one that does not require a rewrite.
Own the glue code. The magic isn’t in the parts; it’s in how they’re wired. Spend time understanding how components interact and design the right abstractions.
When should you build from scratch?
Rarely, but sometimes. For example:
If your competitive edge is the tech (e.g. Google’s search algorithms)
If no existing tool solves your problem (e.g. SpaceX’s flight software)
If you know what you’re doing (e.g. you know that building from scratch will give you a 10x price-performance ratio)
For 95% of remaining cases, though? Assemble.
The bigger picture
Software assembly isn’t lazy, it’s strategic. It lets you:
Move faster (why write an authentication library from scratch in 2025?)
Scale smarter (leverage cloud providers’ global infrastructure)
Focus on what matters (your IP, not the boilerplate)
But it requires a mindset shift. Engineers love building. Leaders love efficiency. Your job is to balance both.
Final thought
Next time your team proposes a “ground-up rewrite” or “let’s built this from scratch”, ask: Are we building a car… or just assembling one?
Because you can move really fast, not by building but by assembling things together.
P.S. If you’re moving slow due to hand-coding auth systems or rolling your own CI/CD tool, let’s talk. I’ll buy the coffee and fix things for you :D
Let me start with a confession: I haven’t built software from scratch in over a decade. And you know what? Neither have you!
Early in my career, I worked at a company that built everything themselves. Authentication? Custom. Web framework? Hand crafted. Even the CI/CD toolchain was custom written highly specific to that company built over the years. With this custom built stack, it took many months to launch a product. Any new member joining the team would need weeks and months to get up to speed with the tech stack. When the product finally went live, it didn’t get the adoption we wanted. The whole tech stack became fragile, and we faced many production issues as the number of users increased to 100k+. Turns out, rebuilding the wheel is expensive, slow, and often… square.
Years later, I led a team and we were building a system to handle millions of transactions daily. This time, we assembled things together instead of building from scratch. The entire trajectory was different and refreshing. We could ship much faster, tune configuration of components to make it work for growing scale and overall, make our software easier to change.
The car factory analogy (you knew this was coming)
Imagine a car company that mines its own ore, refines steel, and hand-carves pistons. Now, check if any such company exists in the real world? No. Because car makers know what works better. Car makers assemble instead of building from scratch. They source engines from supplier A, tires from supplier B, and infotainment systems from supplier C. So, what’s their job then, you might ask? Integrate, test, and ensure the whole machine works end to end.
Modern Software is no different. Think about it:
Cloud providers (AWS, Azure, GCP) are your engine suppliers.
Kubernetes is the chassis.
React, TensorFlow, FastAPI are your tires, brakes, and GPS.
You may not exactly agree with above analogies, but you get the point. Your role isn’t to forge steel. It’s to pick the right components, bolt them together, and make sure the ride is smooth. The same thing applies in software.
What “assembly” looks like in practice
For one of our recent production use cases, we needed a real-time analytics dashboard. Instead of writing things from scratch, we used pre-built components - both open source and cloud specific, to build the system end to end.
We shipped in 3 months. It worked well for 2 million users. Granted, we had some production issues, but all of those were minor issues that we could quickly fix ourselves with just config changes.
Big companies like Netflix or Spotify assemble too. Netflix runs on AWS. Spotify uses Kafka for streaming. They focus on what makes them unique - recommendation algorithms and UX, not the plumbing.
But wait - what about control?
I get it. Dependency on third-party component feels risky. I once inherited a system held together by an outdated open-source library. When it went unsupported, we spent quite some time untangling it.
Here’s what I learnt: treat dependencies like car parts.
Audit them. Would you buy brakes from a supplier with no crash tests?
Plan for swaps. Design systems so that replacing a component like a database or third party provider is like changing a tire. Straightforward, with predictable API abstractions and most importantly, one that does not require a rewrite.
Own the glue code. The magic isn’t in the parts; it’s in how they’re wired. Spend time understanding how components interact and design the right abstractions.
When should you build from scratch?
Rarely, but sometimes. For example:
If your competitive edge is the tech (e.g. Google’s search algorithms)
If no existing tool solves your problem (e.g. SpaceX’s flight software)
If you know what you’re doing (e.g. you know that building from scratch will give you a 10x price-performance ratio)
For 95% of remaining cases, though? Assemble.
The bigger picture
Software assembly isn’t lazy, it’s strategic. It lets you:
Move faster (why write an authentication library from scratch in 2025?)
Scale smarter (leverage cloud providers’ global infrastructure)
Focus on what matters (your IP, not the boilerplate)
But it requires a mindset shift. Engineers love building. Leaders love efficiency. Your job is to balance both.
Final thought
Next time your team proposes a “ground-up rewrite” or “let’s built this from scratch”, ask: Are we building a car… or just assembling one?
Because you can move really fast, not by building but by assembling things together.
P.S. If you’re moving slow due to hand-coding auth systems or rolling your own CI/CD tool, let’s talk. I’ll buy the coffee and fix things for you :D
Let me start with a confession: I haven’t built software from scratch in over a decade. And you know what? Neither have you!
Early in my career, I worked at a company that built everything themselves. Authentication? Custom. Web framework? Hand crafted. Even the CI/CD toolchain was custom written highly specific to that company built over the years. With this custom built stack, it took many months to launch a product. Any new member joining the team would need weeks and months to get up to speed with the tech stack. When the product finally went live, it didn’t get the adoption we wanted. The whole tech stack became fragile, and we faced many production issues as the number of users increased to 100k+. Turns out, rebuilding the wheel is expensive, slow, and often… square.
Years later, I led a team and we were building a system to handle millions of transactions daily. This time, we assembled things together instead of building from scratch. The entire trajectory was different and refreshing. We could ship much faster, tune configuration of components to make it work for growing scale and overall, make our software easier to change.
The car factory analogy (you knew this was coming)
Imagine a car company that mines its own ore, refines steel, and hand-carves pistons. Now, check if any such company exists in the real world? No. Because car makers know what works better. Car makers assemble instead of building from scratch. They source engines from supplier A, tires from supplier B, and infotainment systems from supplier C. So, what’s their job then, you might ask? Integrate, test, and ensure the whole machine works end to end.
Modern Software is no different. Think about it:
Cloud providers (AWS, Azure, GCP) are your engine suppliers.
Kubernetes is the chassis.
React, TensorFlow, FastAPI are your tires, brakes, and GPS.
You may not exactly agree with above analogies, but you get the point. Your role isn’t to forge steel. It’s to pick the right components, bolt them together, and make sure the ride is smooth. The same thing applies in software.
What “assembly” looks like in practice
For one of our recent production use cases, we needed a real-time analytics dashboard. Instead of writing things from scratch, we used pre-built components - both open source and cloud specific, to build the system end to end.
We shipped in 3 months. It worked well for 2 million users. Granted, we had some production issues, but all of those were minor issues that we could quickly fix ourselves with just config changes.
Big companies like Netflix or Spotify assemble too. Netflix runs on AWS. Spotify uses Kafka for streaming. They focus on what makes them unique - recommendation algorithms and UX, not the plumbing.
But wait - what about control?
I get it. Dependency on third-party component feels risky. I once inherited a system held together by an outdated open-source library. When it went unsupported, we spent quite some time untangling it.
Here’s what I learnt: treat dependencies like car parts.
Audit them. Would you buy brakes from a supplier with no crash tests?
Plan for swaps. Design systems so that replacing a component like a database or third party provider is like changing a tire. Straightforward, with predictable API abstractions and most importantly, one that does not require a rewrite.
Own the glue code. The magic isn’t in the parts; it’s in how they’re wired. Spend time understanding how components interact and design the right abstractions.
When should you build from scratch?
Rarely, but sometimes. For example:
If your competitive edge is the tech (e.g. Google’s search algorithms)
If no existing tool solves your problem (e.g. SpaceX’s flight software)
If you know what you’re doing (e.g. you know that building from scratch will give you a 10x price-performance ratio)
For 95% of remaining cases, though? Assemble.
The bigger picture
Software assembly isn’t lazy, it’s strategic. It lets you:
Move faster (why write an authentication library from scratch in 2025?)
Scale smarter (leverage cloud providers’ global infrastructure)
Focus on what matters (your IP, not the boilerplate)
But it requires a mindset shift. Engineers love building. Leaders love efficiency. Your job is to balance both.
Final thought
Next time your team proposes a “ground-up rewrite” or “let’s built this from scratch”, ask: Are we building a car… or just assembling one?
Because you can move really fast, not by building but by assembling things together.
P.S. If you’re moving slow due to hand-coding auth systems or rolling your own CI/CD tool, let’s talk. I’ll buy the coffee and fix things for you :D
Let me start with a confession: I haven’t built software from scratch in over a decade. And you know what? Neither have you!
Early in my career, I worked at a company that built everything themselves. Authentication? Custom. Web framework? Hand crafted. Even the CI/CD toolchain was custom written highly specific to that company built over the years. With this custom built stack, it took many months to launch a product. Any new member joining the team would need weeks and months to get up to speed with the tech stack. When the product finally went live, it didn’t get the adoption we wanted. The whole tech stack became fragile, and we faced many production issues as the number of users increased to 100k+. Turns out, rebuilding the wheel is expensive, slow, and often… square.
Years later, I led a team and we were building a system to handle millions of transactions daily. This time, we assembled things together instead of building from scratch. The entire trajectory was different and refreshing. We could ship much faster, tune configuration of components to make it work for growing scale and overall, make our software easier to change.
The car factory analogy (you knew this was coming)
Imagine a car company that mines its own ore, refines steel, and hand-carves pistons. Now, check if any such company exists in the real world? No. Because car makers know what works better. Car makers assemble instead of building from scratch. They source engines from supplier A, tires from supplier B, and infotainment systems from supplier C. So, what’s their job then, you might ask? Integrate, test, and ensure the whole machine works end to end.
Modern Software is no different. Think about it:
Cloud providers (AWS, Azure, GCP) are your engine suppliers.
Kubernetes is the chassis.
React, TensorFlow, FastAPI are your tires, brakes, and GPS.
You may not exactly agree with above analogies, but you get the point. Your role isn’t to forge steel. It’s to pick the right components, bolt them together, and make sure the ride is smooth. The same thing applies in software.
What “assembly” looks like in practice
For one of our recent production use cases, we needed a real-time analytics dashboard. Instead of writing things from scratch, we used pre-built components - both open source and cloud specific, to build the system end to end.
We shipped in 3 months. It worked well for 2 million users. Granted, we had some production issues, but all of those were minor issues that we could quickly fix ourselves with just config changes.
Big companies like Netflix or Spotify assemble too. Netflix runs on AWS. Spotify uses Kafka for streaming. They focus on what makes them unique - recommendation algorithms and UX, not the plumbing.
But wait - what about control?
I get it. Dependency on third-party component feels risky. I once inherited a system held together by an outdated open-source library. When it went unsupported, we spent quite some time untangling it.
Here’s what I learnt: treat dependencies like car parts.
Audit them. Would you buy brakes from a supplier with no crash tests?
Plan for swaps. Design systems so that replacing a component like a database or third party provider is like changing a tire. Straightforward, with predictable API abstractions and most importantly, one that does not require a rewrite.
Own the glue code. The magic isn’t in the parts; it’s in how they’re wired. Spend time understanding how components interact and design the right abstractions.
When should you build from scratch?
Rarely, but sometimes. For example:
If your competitive edge is the tech (e.g. Google’s search algorithms)
If no existing tool solves your problem (e.g. SpaceX’s flight software)
If you know what you’re doing (e.g. you know that building from scratch will give you a 10x price-performance ratio)
For 95% of remaining cases, though? Assemble.
The bigger picture
Software assembly isn’t lazy, it’s strategic. It lets you:
Move faster (why write an authentication library from scratch in 2025?)
Scale smarter (leverage cloud providers’ global infrastructure)
Focus on what matters (your IP, not the boilerplate)
But it requires a mindset shift. Engineers love building. Leaders love efficiency. Your job is to balance both.
Final thought
Next time your team proposes a “ground-up rewrite” or “let’s built this from scratch”, ask: Are we building a car… or just assembling one?
Because you can move really fast, not by building but by assembling things together.
P.S. If you’re moving slow due to hand-coding auth systems or rolling your own CI/CD tool, let’s talk. I’ll buy the coffee and fix things for you :D
