What is one thing that you would do differently if you were to start a new project tomorrow?

Create something that helps to the envoriment.

Do something I love. Not just a product that solves other people's problems. But something ethical and in a field I like.

If you are the non-tech founder. This is what I will do: Having done dozens of side projects and collaborated with multiple non-tech and tech (web development in this context). I have come to an understanding of what building a tech project is and is not. Every firm today is a tech and data-driven firm. This goes without saying in today’s world. Despite the ubiquitous nature of tech, it’s weird that non-techies find it hard to reach out to tech folks and make things work. - In today’s age when building the product in a bootstrap fashion, the non-tech folks need to go beyond a mere idea and come back with valid data to able to convince the tech co-founder to work together. You need to validate the market and provide the evidence before the specific tech-founder. - Jobs and Wozniak met at a hacker group for computer nerds. There was a defined and specific need for an integrated computer system. Collaborated to first build the prototype. Steve Wozniak | Biography & Facts | Britannica Source - Doing this exercise as such will allow one to do both the homework and at the same time save valuable time in terms of figuring out what to build. Because, once you define the problem, you can find your tech guy by hanging out in forums, conferences or groups which solve or revolve around the problem-solution space. Customer -> Problem Statement - Even though all firms and businesses are tech-driven, the initiation starts with business and primarily starts with the customer in mind. 90% of my dozen side projects failed because of not starting with the customer in mind. By simply, doing this, one can avoid building something which has no need. - All greats ideas, IMHO start from a deep understanding of the specific customer base and their specific problems. Start with the single pain point instead of trying to solve 4-5 problems on the one go. Post getting a good understanding and a belief that we have a probable use case, the next thing to look for is a well-defined problem statement with clear specifics. This helps us to frame the problem as a hypothesis that we can validate. Problem Statement -> Community/(User Research) - Post an understanding of the problem statement and customer. The next step is to build a small community of users or join them. This can be executed as a user research exercise, where one talks to multiple users (possibly 100+). Not sure how to reach, the first set of 100+ users, you gotta fix this problem first. This helps solve for a couple of problems: Is the pain point genuine and an actual issue for several users. How can one go about reaching out to them? A ready-made user list to test out the beta version of the product. Just carrying out this much of an exercise, allows one to quickly validate key aspects of the problem statement and the distribution. Having this 100+ user base is absolutely necessary to ensure, you are building the right thing. This cannot be emphasised enough. Read this book on how to talk to users. User Research -> Finding a Tech Co-Founder This is the phase, where once can finally embark on finding the tech co-founder. Given that we have a problem statement along with an understanding of the first 100+ users. We know what a working solution will look like.

I would set a future start date for planning to start the project. Let's just say I would create time for the project planning before scheduling the project.

First of allI will research for gain knowledge about the project

Would never touch keyboard to code something (I'm also full stack dev) until business idea is tested somehow :)

Have a proper to do list and people assigned to it!!!

start speaking with prospects much earlier. prior to mvp

Talk to a friend and get opinion.

Research about the idea I have. And get in contact with others who have done the same thing and failed. Learn from their mistakes and try doing better at each step.

Do more research and lay out a plan beforehand

I would start lean. [validate, build, publish]

Launch much sooner, with an embarrassing MVP. Don't keep saying "I can just add this one more feature" and don't be afraid to launch with bugs. Early adopters expect a few bumps, but their feedback and contribution should be sought much sooner.

invest in learning before starting