Founders of no-code and low-code tools often refactor too early, before they have real market feedback. Wait until you've gathered enough data and cash flow to justify rebuilding. Refactoring later costs less because your team is more expert and knows what actually matters.
Build, but don't tinker. I talked to a number of people who are building low-code, no-code tools, and the, there comes a point in the development process in which they're saying, maybe I should refactor this, or maybe I should go rebuild this particular feature or what have you, but they haven't actually made contact with the market. Or maybe they've made a little bit of contact, they've got some feedback, and they're about to go make some really big changes. The bias you should have is towards making more use of your current asset and then getting more market information from it and, and certainly a little bit of cash flow from it as well. The time to refactor is going to be when you have enough information to justify that experience. And also the longer you put off the refactor, the cheaper it's going to get because you'll be more expert and know more specifically what it is you need to do. Those two things will combine to drive down your costs more than linearly, and that will just be the— allow you to make the best economic decisions.
