3 ms·

> Code doesn't matter IN THE EARLY DAYS. > This is similar to what I've observed over 25 years in the industry. In a startup, the code doesn't really matter; t

> Code doesn't matter IN THE EARLY DAYS. > This is similar to what I've observed over 25 years in the industry. In a startup, the code doesn't really matter; the market fit does. > But as time goes on your codebase has to mature, or else you end up using more and more resources on maintenance rather than innovation. Counterpoint: Code does matter, in the early days too! It matters more after you have PMF, but that doesn't mean it doesn't matter pre-PMF. After all, the code is a step-by-step list of instructions on solving a specific pain point for a specific target market.

kstenerud 7mo ago
That hasn't been my experience. What I've found worked is: 1. Find a potential customer who's excited about the idea of what you're going to build. 2. Build just enough to make them a mostly happy, paying customer while you secure more customers. 3. Now that you have a few customers, you have a better idea of where your architecture and business flow doesn't fit their needs. 4. Adapt to this reality, and make things robust enough that you're not spending too much time on customer support.
- lelanthran 7mo ago
  I follow that too, when I try a new venture, but what does that have to do with "The Code Is/Isn't Important"? What you listed is important, but those findings are distilled into the source code of the product. If you open the source, you are providing step-by-step instructions on solving some problem that other people are prepared to pay to solve. Basically, you come up with a recipe for success for $FOO - why would you give that recipe away unless you've already capitalised on it?
  - kstenerud 7mo ago
    None of what I said even speaks about source code. It could just as well be run by a bunch of people with notebooks, sending emails from time to time. All that matters is that the product works, and we have a scaling path once we find a market fit. Yes, that's likely to involve source code, but I've no qualms with tossing out the MVP code and starting over from scratch. Or adapting the quickie we put together, if it happens to contain a kernel of value. Whether I open source it or not depends on where our moat lies. But regardless, the new reality is that anyone can decompile your code with an AI and duplicate it. So merely putting an app out there opens the door for someone to copy it. So really, your moat better be something besides the code!
    - lelanthran 7mo ago
      > It could just as well be run by a bunch of people with notebooks, sending emails from time to time. And does that give all your startup competitors the findings that make your solution something that others pay for?
UqWBcuFx6NV4r 7mo ago
Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS.
- lelanthran 7mo ago
  >> Counterpoint: Code does matter, in the early days too! >> It matters more after you have PMF, but that doesn't mean it doesn't matter pre-PMF. >> After all, the code is a step-by-step list of instructions on solving a specific pain point for a specific target market. ---------------------------------- > Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS. Did you perhaps reply to the wrong comment?
keeda 7mo ago
I'm probably missing something. Pre-PMF code by definition is not yet proven to solve a specific pain point, so why does it matter? I think the crux here is the OP means the "quality of code" doesn't matter until PMF, only the utility matters (to the extent it helps you find PMF), in which case you're both in violent agreement. But even then you don't need code. I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually. The "code" as such was a bunch of templates in a doc for each of those. Once they actually started getting paid they moved to writing code.
- lelanthran 7mo ago
  > I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually. Right, and in that case there is no step-by-step recipe for the product. When all that is implemented in code, that is a set of step-by-step instructions for solving the pain points.
  - keeda 7mo ago
    But the manual workflow was the step-by-step recipe the founders iterated on until they got traction; the product that came later was just an embodiment of that workflow as code.
    - lelanthran 7mo ago
      > But the manual workflow was the step-by-step recipe the founders iterated on until they got traction; Okay, and did they publish that under an MIT license? Did they give those manual workflows away for free to other startups?
      - keeda 7mo ago
        I don't see how that is relevant? I thought the point under discussion was that code does not matter until PMF, and that this would be an illustrative example because there was no code until PMF. Like, from the users' perspectives they were interacting via text messages both before and after PMF, until later down the line they were migrated to an app. At this point, the change was largely aesthetic, the core idea was the same. Maybe we're using different definitions of terms like "PMF" here?

kstenerud 7mo ago

That hasn't been my experience. What I've found worked is: 1. Find a potential customer who's excited about the idea of what you're going to build. 2. Build just enough to make them a mostly happy, paying customer while you secure more customers. 3. Now that you have a few customers, you have a better idea of where your architecture and business flow doesn't fit their needs. 4. Adapt to this reality, and make things robust enough that you're not spending too much time on customer support.

lelanthran 7mo ago
I follow that too, when I try a new venture, but what does that have to do with "The Code Is/Isn't Important"? What you listed is important, but those findings are distilled into the source code of the product. If you open the source, you are providing step-by-step instructions on solving some problem that other people are prepared to pay to solve. Basically, you come up with a recipe for success for $FOO - why would you give that recipe away unless you've already capitalised on it?
- kstenerud 7mo ago
  None of what I said even speaks about source code. It could just as well be run by a bunch of people with notebooks, sending emails from time to time. All that matters is that the product works, and we have a scaling path once we find a market fit. Yes, that's likely to involve source code, but I've no qualms with tossing out the MVP code and starting over from scratch. Or adapting the quickie we put together, if it happens to contain a kernel of value. Whether I open source it or not depends on where our moat lies. But regardless, the new reality is that anyone can decompile your code with an AI and duplicate it. So merely putting an app out there opens the door for someone to copy it. So really, your moat better be something besides the code!
  - lelanthran 7mo ago
    > It could just as well be run by a bunch of people with notebooks, sending emails from time to time. And does that give all your startup competitors the findings that make your solution something that others pay for?

UqWBcuFx6NV4r 7mo ago

Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS.

lelanthran 7mo ago
>> Counterpoint: Code does matter, in the early days too! >> It matters more after you have PMF, but that doesn't mean it doesn't matter pre-PMF. >> After all, the code is a step-by-step list of instructions on solving a specific pain point for a specific target market. ---------------------------------- > Nope. That’s what self-important engineers will tell themselves, but it doesn’t make it remotely true. You’re patting yourself on the back for throwing together a CRUD app and burning through a bajillion dollars on AWS. Did you perhaps reply to the wrong comment?

keeda 7mo ago

I'm probably missing something. Pre-PMF code by definition is not yet proven to solve a specific pain point, so why does it matter? I think the crux here is the OP means the "quality of code" doesn't matter until PMF, only the utility matters (to the extent it helps you find PMF), in which case you're both in violent agreement. But even then you don't need code. I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually. The "code" as such was a bunch of templates in a doc for each of those. Once they actually started getting paid they moved to writing code.

lelanthran 7mo ago
> I briefly worked for a startup that found PMF by calling people, sending text messages, creating social media posts, measuring engagement to create reports, and sending invoices... all manually. Right, and in that case there is no step-by-step recipe for the product. When all that is implemented in code, that is a set of step-by-step instructions for solving the pain points.
- keeda 7mo ago
  But the manual workflow was the step-by-step recipe the founders iterated on until they got traction; the product that came later was just an embodiment of that workflow as code.
  - lelanthran 7mo ago
    > But the manual workflow was the step-by-step recipe the founders iterated on until they got traction; Okay, and did they publish that under an MIT license? Did they give those manual workflows away for free to other startups?
    - keeda 7mo ago
      I don't see how that is relevant? I thought the point under discussion was that code does not matter until PMF, and that this would be an illustrative example because there was no code until PMF. Like, from the users' perspectives they were interacting via text messages both before and after PMF, until later down the line they were migrated to an app. At this point, the change was largely aesthetic, the core idea was the same. Maybe we're using different definitions of terms like "PMF" here?