Stupid mistakes I made while building my first startup
sooraj.io
sooraj.io
Ultimately, money is the only thing that can keep a startup going. That means either sales and revenue or investment, and getting investment is a lot easier if you have sales and revenue.
Eating more healthily, getting more sleep, and doing some exercise are useful for staying focused and selling better, but the number of successful startups whose founders had horribly unhealthy lifestyles yet still managed to sell their product is significantly higher than the number of startups with healthy founders who didn't sell anything.
I'm afraid that if I spend my evening and nights into trying my idea, I would either 1/ not get results fast enough and hence loose faith in the project or 2/ get burned out and hence disgusted by the project.
Or maybe it's just the lies I like to tell myself to be comfortable with keeping on procrastinating this...
But most of this start-up advice seems to be geared at single college students, and they'll have enough free time to pull it off.
The only thing I'd extend this with - but with some hesitation - is demonstrated traction. People are using your product, even a very very early version. (The reason for the extension is many social media apps don't monetize for a long while, and users seems as adequate substitute for revenue here.)
No wonder nobody does hardware startups. It seems unrealistic that you'd have a prototype that anyone would be comfortable paying for within a few months, unless you're selling something as simple as a pre-programmed Arduino in a box.
If you're thinking "No one would pay for that" without asking customers then you're doing it wrong. Let the customer decide what they're happy to pay for. Some of them will give you money even after you've made very little progress.
The machine consists of a base depositor that can be purchased on its own for about $2000-$3000. The heating elements consist of a few metal plates worth maybe a couple hundred dollars, a couple of off the shelf temperature controllers worth less than $100 each and some housing and circuitry for the controllers that's can't be worth more than $1000. Overall, I'd say the temperature controlled depositor has maybe about $7000 worth of parts in total, being generous.
That's a decent markup for something comprised nearly entirely of off the shelf parts.
NB: I'm not talking about selling a product for build pipelines, I'm talking about allocating excessive resources into internal tooling pre-traction.
Top-talent engineers are going to be a lot more reticent to join a startup where the systems are constantly on-fire and held together by duct tape. The first few hires set the standards and corporate culture, so this can have a real impact on the company's long-term viability.
Once you, as a founder, have the luxury of hiring (presumably because you've done step one correctly), your time is then a choice between selling and recruiting, and in the early stages of that, recruiting isn't going to be much more than trying to convince good people you already know to join your team. These people aren't going to say no based on your CI system.
Having made the mistake myself (multiple times), OP is 100% correct, and it's one of those messages that can't have any nuance, or people won't do it right. It's a treacherous vortex of failure for programmers-turned-founders: coding is much easier and more familiar than selling, so you find all sorts of reasons to write code when you should be talking to customers.
Doing awful things to rapidly try out an idea and see if it warrants further investment is good, as long as you kill the ugly as soon as you understand that your POC is good and you are going to invest further or you know it's not a wise place to invest further.
But there are definitely places where you know you're going to need sanity no matter what. This is anything you know you're going to do a lot, especially under a time crunch. For SaaS work, deployment is one example. In these cases, it's worth investing in building a low friction solution that meets your needs.
If you are using something like Google app engine or heroku, all that autoscaling and other devops stuff is taken care of for you. There is no reason to go without.
The very first version we launched publically, we checked out, compiled and deployed through SSH directly on the servers. My first monitoring tool was htop in 3 screens plus some CloudWatch dashboards. A lot of credentials and endpoints were hardcoded. Not because we didn't know better, just to save time.
The number one thing pure techies completely get wrong is opportunity cost. Especially in the beginning, almost nothing beats time to market to validate product/market fit.
That said I think that investing in a minimal, quick and dirty CD system can be valuable for very early startups that need to move very fast on the road to product/market fit.
Ship it
I don't care if you're installing it by retyping the code into your server (hyperbolic example, sure), but ship it.
Can you get payed? Can the customer use the product, even if it's a basic version? Ship it
The rest is fluff. Of course do worry about them, after you start having money go into your bank account.
It's fine to start this way but people have to realise they will need to put some structure in place. At some point you'll struggle to get new features out on time without a ton of bugs.
Tooling is tooling, not a religion. But if you've ever looked at the regimen of an elite professional athlete, you'd be hard pressed to discern it from a religion. It is necessary, but insufficient, and I don't think most people get that.
I see the point you are making, but I'm skeptical of this; if we ignore the health factor entirely, the number of startups that sold any significant amount is probably a very small fraction of the total number of all startups.
I'd be more interested the proportion of founders with healthy lifestyles in the pool of "successful startups that have sold a nontrivial amount of product", versus the proportion of healthy people in the _general_ population (either all founders, or all people).
My completely uneducated guess is that there would be two competing effects for the "successful startup" pool: the "dedication at all expense" factor would result in a negative correlation between success and health, and the other obvious effect would be healthier living causing better decision-making and execution. Of course, this is just a guess and I could very likely be wrong.
But the right approach depends on your goals. If your only metric is money, then you should probably spend a lot more effort on marketing than engineering. But if it is a lifestyle business and you prefer the engineering, do a more than optimal amount of engineering. Just make sure you do enough marketing to pay the bills!
I definitely agree about exercising.
> We shipped features at a tremendous pace. But we never talked to enough users to identify if it was something necessary. We assumed things and kept building – in a few months, we had a product which was an engineering marvel – but nobody cared to use.
I am curious because the YC application needs one to clearly articulate who ones target customers are, what they do today, why is it such a pain, and what one is building to solve that pain-point. And it looks like you folks at Marketfox did have it figured out [0]. It is interesting to me, then, that you'd cite this as a key mistake. What am I missing?
> We were very naive to think that building software is the hardest part of building a startup.
Well, there's a balance here: Both are equally hard. Writing code is less hard if you're a software professional and same goes if you're a Sales or Marketing professional. You did say you shipped features at a break-neck pace... but usually, for an enterprise SaaS, isn't that the bread and butter anyway? I am curious why you'd consider this a mistake. Not every (SaaS) product is novel anyway, and learning from your competitors is a shortcut to the otherwise long arduous road of defining a category / industry / market. Assuming that you folks did not build a feature in a vacuum (that is, you'd have would thought a feature was necessary only after looking at competitors do it better or a paying customer ask for it), was it the case of feature mis-prioritization / building too many bespoke features that only one or two customers wanted?
[0] https://blog.ycombinator.com/yc-w17-launch-lively-scaphold-m...
The surface area of products like Hubspot(our competition) is huge - and we tried to catch up with them in terms of feature and this was a mistake. We didn't try to identify a niche.
I think this is one of those things that is easy in theory and hard to practice.
2: Agree that both are hard. I'm still happy with the pace which we shipped at. Looking back at it I think we were not shipping the right features. There are a few reason for this: - We got a bit desperate at some point and started building features for single customers(which we thought would be useful to others, but was not). And this spiraled downwards and our product started doing things that we initially didn't intend to. (Like email automation, push notifcations, website builder, form builder, inapp messaging, blogging platform, social media management etc) - At some point we blindly started copying features, without thinking why we need to build it. (I know this sounds really stupid now, hence the title) - We were young and we thought we could brut force(or hustle) our way out of every problem.
I hope that helps. Happy to explain more if you have questions :)
Thanks for sharing.
Once we started building we got the opportunity to talk to a users(Other YC companies in the same batch) - which thinking of it now was not the ideal user persona.
Funnily enough, I was about to cite the example of Freshworks (in that building SaaS companies from India gives one an unfair pricing advantage; and also that focusing on one product for a large but under-served (read: small companies) market that can be sold "repeatably" (read: feature set everyone needs) is the "key" before moving "upmarket" to large enterprises [0]) but it looks like you are an ex-employee and so you'd know all of this already!
That out of the way, a few follow-ups:
> ...we "assumed" people who used our competitors would use our product too. And when we were not able to sell, we thought It was because of lack of feature.
I mean, I'd naively think it to be true as well-- that not being able to sell (to target customers) would be usually be due to lack of features. If not that, what, you think, were some reasons Marketfox couldn't?
> At some point we blindly started copying features, without thinking why we need to build it.
You mean Marketfox didn't know if a missing feature (that a competitor had but Marketfox didn't) was important / critical but expended engineering resources on it anyway? If so, what you'd have done in its stead? How else you'd approach figuring out what to build?
Also, I am assuming Marketfox had access to founders/mentors who had done SaaS before... why you'd think that didn't make a difference (given your analysis that the mistakes you enumerated were avoidable)? What'd you, in the light of that, do differently?
Thanks.
Re: Selling to customers: This was not easy as we thought. Most people just doesn't switch to a new product based on features. Either the new product needs to be substantially better - so that it overcomes the pain of the switch.
This means we had to build a product that is much better than existing products - and we failed placing our product correctly. Marketing is an area with a lot of verticals. Content, Digital, Email etc.
We tried to do a lot of things at the same time. For example we could have focused on just email marketing, or just content marketing. Instead we tried to do all of these together and they were mediocre. I guess that was not enough to force the switch. After a point we couldn't tell who were we competing against - The email marketing solution, the push notification solution or the enterprise marketing solution.
If I were to rebuild it today I would have focused on a single thing and built a great product out of it.
About mentorship - I'd say I didn't have enough "access" to mentors or the network due to several "internal reasons" (Slightly touching upon this on the decision imbalance)
If it was solely up to me, there are things I would have done different back then too.
At least now, I have wonderful people helping me through my startup journeys. And I'm a big believer of having the right mentor. At the startup I co-founded last (Carrom - which was acquired https://money.yahoo.com/oyster-acquires-carrom-accelerate-gl...) I had the opportunity to work with some great people and this was something I did right in terms of mentorship.
Which in my opinion is the hardest part. If you don't know what you're doing, it doesn't matter if you're selling or not, it doesn't matter if you're building or not. That comes later.
But that's not it. How do you know what you're doing, or going to do? It doesn't happen by sitting down with buddies or co-founders and having a brainstorming session. This is where 'you have to be at the right place and the right time' but also 'you have to have spent the right amount of time thinking about it'
The right amount of time could be 1 week, or could be 10 years. Yes sometimes you need 10 years to get to the point where when you found a company, you start generating sales within a matter of months.
I really appreciate you taking the time to write this down and allowing us to read it. Thanks again.
Glad it helped! :)
It's especially nice when sales get back from a demo and reports about jaws being picked up from the floor. Or when the base you made allows you to whip up a solution to a pressing customer issue in 5 minutes.
It's not always fun to write that code, but it can fun to have written that code.
I was in a similar situation as author, only in Chicago 'burbs. We were working hard to build our product, and there was free unlimited fizzy sugar water in the kitchen.
I drank so many MtDews that when I got back home, to the house we rented where I was living with 3 other startup members, and passed out in bed, I ended up peeing myself in my sleep for the first time as an adult. Worse, it happened again the next night!
It didn't happen after that, to my knowledge, but I've sworn off both MtDew and doing more than 10 hours per workday since then.
It also made me realize that if a startup can't make it without taking a huge toll on health and happiness, it's not sustainable by definition, and should be modified. There are occasional exceptions, but most of the time this rule stands.
I think anything that is not sustainable over a period of time is not a good idea. It is ok to try and do things that don't scale in the beginning. But it shouldn't come at the cost of physical and mental health.
Looking back at everything that lead up to him having to leave, I've come up with the one mistake I regret doing:
Splitting up duties.
We were technical founders but we decided one of us would handle the business side and one of us would handle the technical side.
I think this ended up isolating us rather than having us work together as a team. As we grew I hired account managers, sales, etc and he hired devs. We chose to start a company together but never really worked together.
Now 4 years later I'm working in the backend for the first time. I wish I would've spent more time pair coding with him and discussing architecture together. We worked at 3 other companies together and went to university together and I think we missed our opportunity to truly work together on something WE want to build.
I remember Marketfox really well because I've never seen a team build so many things so quickly! The execution speed was legendary and it made us feel so slow in comparison. :D Good luck with your next startup!
How did your office hours go?
Thank you for sharing!
I think under pressure we made a lot of stupid decisions. We were inexperienced and we were doing that for the first time.
I don't think these are harder to practice - My second startup was recently acquired and I think I did a decent job there. The reason why YC emphasise about these mistakes are probably the same - they have seen a lot of first time founders make the same mistake.
Everyone knows the second hardest part is figuring out what products to make.
Everyone knows the hardest part is finding customers who are actually buying your products.
I'm not saying the easier tasks are unimportant but if you don't solve the hardest problem your business won't go anywhere, no matter how good you are at the first two. Meanwhile someone with a good sense of business can often delegate the first two to someone else.
But that doesn't guarantee all the future ventures will be a success.
I have not repeated any of those mistakes I mentioned in the post. I think that itself was enough to take us to a good place. Apart from that it was good timing, a lot of luck and market I knew down under.
Another thing was consistency - we also had lot of ups and down, in fact we stopped operations at some point. But kept going to come out of it. Consistency was the most important thing there.
I find this true whenever I decide to take on a new endeavour. If you can learn from someone else's mistakes, you're better off than 80% of the competition in ANY MARKET.
So many people have an idea to make money, look at the competition, and give up. But if you keep going just a bit further, you find out that most of the competition, which looked so daunting at the start, is actually awful.
Nobody wants to build a product in vaccum that has no users, no matter how brilliant the idea.
Moreover, the energy(ie money ) to sell will be lost if you try to sell a not-baked-product whereas spending to upgrade the product is never lost... So yes, this building vs selling is to be nuanced ....
I guess they aren’t too heavy handed about it.
Also the coding on the floor thing, wow.
But after all is said and done, major props for getting to be a YC startup to begin with!
YC is as good as what you can make out of it. It can be anything from average to great, depending on how much effort you put into learn from smart people.
There's an IKEA in East Palo Alto. Sleeping on the floor for extended periods of time is ridiculous. Even a $30 inflatable air mattress is better than that. Come on. It's not like SV carpets are tatami mats.
Surprisingly, programmers don’t require a lot of room to work. Just a small table and a laptop. And multiple monitors are a great productivity tool.
People say this, but what features?
If you've built something that's buried under 3 menus, then that's not going to have great returns. Every feature added is is another node in a graph with multiple branches to any related features. This includes non-code related things like ux, maintenance cost, marketing, tie-in with product vision (i.e. how well does it fit into that brief description of your product, and if it doesn't how to do you communicate it).
Building the software is the hard part. It takes a few hours to talk to dozens of customers. People will use your product if it solves a pain point. It takes 100x more time to actually implement that feature.
Actually, finding those customers is the hard part.
It sounds like all the other problems are just derivatives of this because all of the time was spent head down and "working" and no time spent being strategic, creative or learning what your customer base actually wants.
I also notice that in the past few years, there are a flurry of new products in this space offering lifetime deals as well. This makes it so that a traditional saas offering needs to incorporate some sort of up sell later on.
Yep. And it is still romanticized by the investor class looking for tireless worker bees and some successful founders who believe that because they built startups that way, it's the only way.
Is this how most ycombinator funded companies general work? You have to move California even if you are sleeping on the street? Wouldn't staying in home country make more sense until profitibility is discovered?
I want to make it clear that YC definitely recommends a healthy life style and this was strictly our choice.