21 mistakes I made with my startup
Some mistakes can be informative, but definitely avoid these ones
My startup had three founders, none of whom were technical. Well, I had been a software engineer, but the last time I was actively coding, the cool languages were C/C++ and SQL 🤣
After building a very limited and unstable MVP, we quickly decided we needed real expertise, not my hacky Ruby on Rails skills picked up from a book, to build a credible product. Did we get a technical co-founder? Nope, we hired a developer studio and cloud provider to build and host our product.
There were many dumb things we did along our startup journey, but that decision has to rank near the top. Not only were they not that good (our UX was pretty dismal), they were slow to ship features, non-responsive during outages, and doing everything in their power to extract money from us.
The startup journey is one paved with many mistakes.
The lesson learned? If you are a tech startup, you should probably own the tech. It not just a matter of cost, the biggest issue is alignment. When you own the tech, the incentives are clear. When someone else owns the tech, their motivation is money. That’s true even if equity is used for compensation.
Mistakes can be incredibly valuable. After all, many successful startups started with one idea before eventually realizing it was the wrong path and changing gears. It is more fair to say that mistakes are micro-learnings that get you closer to the right path.
Then there are the truly boneheaded mistakes. There is an Amazon saying that there is no compression algorithm for experience. I would rephrase it as there is no compression algorithm for mistakes, as I felt I made every conceivable mistake, each taunting me for our naivete.
Many of the mistakes we make are self-inflicted.
Fortunately, I have two traits in overabundance. I am incredibly stubborn and am relentless about winning. This kept us going way longer than we deserved to (long enough to get to an exit) despite running into brick wall after brick wall.
So in the hopes of helping you avoid the bonehead mistakes and focus on the useful mistakes, here are 21 things I generally recommend you avoid in order to position your startup for success:
Do not outsource tech – It should go without saying for any tech startup. You need to own your tech. Even if you use outside help for an MVP, get a tech co-founder ASAP.
Paying for investor access – This used to be a thing outside Silicon Valley, even in NYC. We did this and of course got no results. With the funding downturn, regrettably this is returning.
Going to startup pitch events – We spent way too much time pitching to audiences that were neither customers or investors. Be very choosy with the events you participate in.
Obsessing on pitch decks – We took every comment on our pitch, made numerous edits, and ended up with a thousand decks. Some change is useful, but do not over index on this.
Cold outreach to investors – None of us had any networks into the VC world, so we did cold outreach. VC’s marked it as spam or ignored it. Hugely non-productive.
Undervaluing network to open doors – Despite our limited networks, we knew a lot of well-connected people, that we never reached out to for help. Your network is your opportunity.
Not maintaining cap table discipline – We gave away equity like it was candy to anyone that helped, and our cap table was a mess. This scares investors and quickly dilutes your stake.
Choosing the wrong co-founders – We were absolutely not compatible, but too far along to see we were not a good team. Vet your potential co-founders thoroughly before starting.
Founders that were not full-time – One co-founder was working full-time, poisoning our team dynamic. Everyone should be all-in, otherwise it’s not a startup, it’s a hobby.
Painfully slow decision making – Each of the founders had different personalities and we were all opinionated. This meant every decision was a debate or argument, slowing us down.
Allocating time on non-productive work – We spent time on office space, logos, color schemes & other non-essential matters that were papercuts that flushed away a lot of time.
Neglecting culture – This never even came up when we started. Taking even a half-day to align on what we valued could have saved us tons of time from decision making to hiring.
Making dreadful hires – Because we had no culture or hiring process, we lagged on good candidates and rushed poor candidates onboard. Bad hires are 3x more expensive.
Spending money on things with no ROI – We were mostly frugal, but still managed to flush away money with no return on things like PR, branding, marketing tactics & swag.
Overvaluing PR – PR is useful, but mostly at the scale phase. Early on it was costly, ineffective & a drag on our limited resources because we did not have a “sellable” story yet.
Overinvesting in marketing early on – Marketing is a scale motion. Before you have product-market fit, most marketing effort is wasted. Focus on more targeted acquisition.
Focusing purely on enterprise – We were 100% focused on enterprise, but sales cycles were 12 months long. Going mid-market would have accelerated our growth and cash flow.
Customizing too much for customers – Enterprises are slow moving and come with lots of needs, which lengthened implementation times and ate into margin.
Wasting time with partnerships – Every potential partner lead was all talk, lots of meetings, no revenue. Outside of limited instances, most partnerships result in no business.
Not prioritizing user experience – Not owned our tech contributed to a poor UX, but frankly we did not prioritize it, making it an even harder sell and implementation.
Implementing Kubernetes – Just kidding, it was not invented at the time, but if it had been, I am pretty sure we would have used it 😂
Obviously, there is a lot going on behind the scenes with each of these (other than Kubernetes, which you should never be implementing as an early stage startup). We will revisit some of these in future newsletters and also some videos on our YouTube channel to dive into how to avoid these pitfalls.
There may be things you see on this list that hit home. There may also be points made above where you have a different experience. Let us know, we would love to hear your experiences on mistakes that you have made, how you course corrected, and what you learned in the process.
Three interesting things came to our attention this week on the topic of Generative AI. In this fast-moving space, the three areas we are closely tracking are the development of open source AI tooling, enhancements to developer productivity, and availability of GPU’s, and that is exactly what we saw.
CB Insights recently published an article on the current state of open source AI and mapped out 70 plus vendors. As fun and easy as something like ChatGPT is to use, enterprises and governments have strict requirements on security, privacy, regulations, and IP that requires a more delicate approach to using AI. This area of the AI market will see the most near-term growth as these organizations jump on board to experiment with AI.
Recently Paul Graham, Co-founder of Y Combinator, tweeted about one YC company that is tackling the area of developer productivity. The results we have seen using these tools to provide usable code however has been 50-50 at best. Phind is like Stack Overflow on AI, allowing developers to search for answers, and they touted that their model is now gets higher quality answers, is faster than ChatGPT, and allows for 16k tokens. We have already seen AI coding assistants like Amazon CodeWhisperer save developers up to 40% in time, and there is much more opportunity ahead to help developers.
One challenge that many companies are facing is the availability of GPU’s to run workloads. This issue is a blocker for many that are building with AI, so AWS announced Amazon EC2 Capacity Blocks earlier this week. This is a new consumption model that enables any customer to access GPU compute capacity to run short duration machine learning (ML) workloads. With EC2 Capacity Blocks, customers can reserve hundreds of NVIDIA GPUs co-located in Amazon EC2 UltraClusters designed for high-performance ML workloads. Access to high-end compute resources using NVIDIA H100 Tensor Core GPUs will continue to be constrained, and this will go a long way to alleviating the blockers, especially for startups.
We recently shared on LinkedIn a program called AWS Women’s Demo Week, a week-long series of in-person events highlighting the work of women startup founders! The events feature demo days across 17 cities worldwide with panel discussions, networking, and of course startup pitches! If you want to join us, the events run from November 6-10 and you can sign up for AWS Women’s Demo Week and register for the event happening in a city near you.
While a bit navel-gazing, we are also excited to have published our 25th edition of this newsletter last week! We managed to maintain our weekly cadence except for one week when both Basil and I were totally swamped. So, we think we can officially declare that Founders in the Cloud is a thing 😁
Given this modest accomplishment, we would love to have YOU involved and turn this newsletter from just the two of us, to something that is supported by this community of readers. If you have ideas to share or strong opinions on a tech startup topic or know of events that would be beneficial for our readers to be aware of, please reach out! You can ping us at this email address. Thanks!