Here's how you can avoid the common mistakes software engineers make when starting their own ventures.

I often work with founders and what they all share is a frustration about something. It drives them to build a solution to solve this issue. But just because you are frustrated with an issue, that does not mean others are equally frustrated. Or want to pay money for this solution. So before you start building, even an MVP, ask question. Find out if others are as frustrated as you are, or consider it a mere nuisance. Ask them if they would be willing to pay to resolve it. People are always dazzled by toys, but would they still use it when it comes at a cost? You'll only find out by having conversations and asking as many questions as you can. You will learn everything you need to design a useful product.

A good way to start is to have a mock-up showing the design and functionality of the MVP. The mock-up will also serve as a step to think about UI design and making the customer experience better. The mock-up tools such as Figma, provide the ability to show the actual functionality without any coding. Once the mock-up is ready, identify a sample set of users/customers representing the potential market, and do a walk-through of the mock-up. Take in all the feedback, adjust the mock-up and get another round of inputs. Remember, one can't satisfy everyone, so focus on the inputs pertaining to the main functionality only. Without this step if a product is developed, it may not meet the requirements of the target audience and won't get used.

One effective technique is the Wizard of Oz method, which involves presenting a facade of the working product to users while manually handling operations behind the scenes. This strategy is particularly useful for validating complex features without fully developing them, thereby gauging user interest and functionality viability before committing significant resources. By combining these methodologies, software engineers can more effectively navigate the initial phases of their endeavor and set a solid foundation for future growth.

Start with an MVP mockup and present it to the potential customers. See if any of them would sign up for a proof-of-concept at a nominal fee. Such a sign-up validates the product idea, and makes sense to start with the development. Having a paying potential future customer will also help in validating the design and implementation ideas of the product along the way. By the way, this was the suggested approach in a startup conference 6-7 years ago at Las Vegas. The insistence was more on getting the product idea validated before writing a single line of code. One caveat is that the potential customer might highjack the implementation with too many inputs, hence watch out not to steer away from the core idea of the product.

Definitely have at least 6-8 months of runway and then some. When we usually calculate our one month requirement, we underestimate the numbers -- do not do this when planning your runway.

Building a strong and collaborative team is a very important step. Though the general perception is to have highly talented coders, it will be useful to remember that if all players are Tom Brady, that football team might not be the best. There is a need for a talented quarterback like Tom, but you need wide receivers, line backers, running backs and corner backs to make a proper team. Having all high hitters, on many occasions, makes it only difficult for the team to get a consensus on technologies, approaches and issues. So try to have a balanced team that can stay aligned towards the mission of the product without compromising on the values you set forth.

It is very important to know if the market the product will serve is governed by state and/or federal regulations and are there mandatory compliance requirements that the product/service will have to meet. At the minimum, the developer should be aware of regulations such as PII/PCI/Sox/HIPAA/GDPR/CCPA, and design the systems to obfuscate any and all identifiable data to protect their users. Follow the proper legal process for setting up the company, drafting company policies, writing job offers and setting up compensation structure to ensure non-discrimination and avoid any potential lawsuits. Special attention needs to be paid while writing 3rd party contracts to protect IP and not to infringe on others IP as well. No shortcuts please.

It's easy for those with a solid technical background to get caught up in the technical aspects of the business. Focusing too much on concerns like future technical challenges can be a critical mistake. While having a solid technical foundation is essential, it's equally important to prioritize areas related to the business domain and design realistic roadmaps. Many startups tend to immerse themselves in the nitty-gritty details of their product or service, often neglecting the broader business perspective, which can lead to a lack of focus on identifying the target market, understanding customer needs, and developing a sustainable business model, causing even the most technically impressive product to struggle to succeed unavoidably.

Do not hire any full timers until absolutely necessary as it is a big expense if funding a start up with little to know money. Instead try your best to do it on your own for as long as possible, with perhaps the goal of seeking external funding to achieve personnel growth.