Hacker News Reader

Comment by onion2k | Hacker News Reader

"Too much building and not enough selling" is the major mistake in the list. It's the reason for my first startup failure too. You need to be generating revenue within a few months of starting. If your product solves a real problem people will pay money for less than the minimum product just to make sure your company survives long enough to build the minimum product.

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.

View on HN

Extremely important corollary: Build pipelines, autoscaling, CI, unit test, et al are not a real problem customers want you to solve. Not a single penny is going to roll into your coffers because you have tremendous infrastructure in place.

NB: I'm not talking about selling a product for build pipelines, I'm talking about allocating excessive resources into internal tooling pre-traction.

You can get testing on pull request + deploy to Heroku on master going with GitHub in less than an hour.

Or use Gitlab and have a CI/CD (to Kubernetes) for the cost of a Dockerfile.

or just run npm test / make test locally without setting up anything. But I feel like writting the tests takes usually more time than setting up CI/CD.

I pretty much agree with you, but the stronger counter-argument would be that having those things makes recruiting a lot easier.

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.

You're talking about two different scales: if you're at the stage where you're choosing between selling and building on a daily basis, worrying about your recruiting pipeline is a second-order problem (if not a third-order problem).

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.

Or could attract those who like to find fault / rip apart your processes and impose order. That person might be what you need..

Ignoring the "eat your vegetables" part of software engineering isn't a savvy startup hack, it's a deliberate taking on of tech debt for short term product velocity boost. It's also pretty dangerous for you engineering culture - most engineers don't like to work in this environment and good ones don't have to.

It's really all about making principled choices when it comes to how much jankiness you can tolerate for a short term velocity boost.

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.

I applaud this attitude, but I think you are wrong about the specifics. If you are serious about this craft, you should have a stock build/test/ci harness you can spin up without effort. Even if it's just "copy some boilerplate from a previous project". This is just basic software literacy, like using git.

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.

I think there is a core truth you're point to that when you're working on the initial months of a start-up, knowledge and time to acquire it are massive weaknesses. If you're using that time to learn how to build your CI pipeline, that's probably not the best allocation of that critical time. An entrepreneur would be best served by CI practices they can employ off their own shelf and focus their attentions on the billable problem solving.

This. It took us three months to market back then, mostly because we skipped everything nonessential. Like, really everything. Sure, these days we have CI/CD with static checking, ChatOps, full observability, all the nice stuff that attracts good developers. But all of that is completely irrelevant to customers. It's just relevant to scaling a dev team.

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.

100% and I see this kill startups from time to time. Particularly ones with very technically sharp but unwise founders.

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.

This this this

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.

I've had to clean up from this once the product matures into maintenance mode.

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.

Yes, I agree. But it's easier doing the structure while you're getting money in the bank.

Customers pay for velocity. You can get velocity by installing a freight elevator, or by jumping off the side of the building every time.

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 was more talking "We don't have a single customer yet, but we have an industry standard set of redundant freight elevators, with automatic load balancing and travel optimization" versus "We have 120 paying customers, and still take the stairs".

> You need to be generating revenue within a few months of starting. If your product solves a real problem people will pay money for less than the minimum product just to make sure your company survives long enough to build the minimum product.

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.

It seems unrealistic that you'd have a prototype that anyone would be comfortable paying for within a few months

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.

Be careful not to confuse consumer hardware with business hardware. There are plenty of business hardware use cases where customers are definitely willing to pay money for something that amounts to a few hundred dollars worth of off the shelf components, custom PCBs, well-written control logic, and fanatical customer support. You just probably don't encounter this kind of hardware because it's out of the public eye in manufacturing, logistics, etc. operations and getting to those customers requires knowing the target industry (or knowing people who do).

I've got a real life case I can provide an anecdote for. I recently got to try out a candy depositor with a temperature controlled hopper. The machine costs about $12000.

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.

I work in this area and the customers are still very picky. A lot of our funding has come from a few very large purchasers that are okay with a farther horizon, but most customers don't care about the product no matter how good it will be in the future. They want it good now.

Maybe in US there are not many hardware startups, but look at Shenzhen/China: https://www.youtube.com/watch?v=SGJ5cZnoodY

This is why I advise people to develop a working prototype in their free time while they're still employed.

I see this a lot but I feel its quite difficult to actually pull off. Even though your mvp can and should be shitty sometimes it still takes a lot of effort and talking with potential customers to even figure out what you should be building, and its extremely difficult to do when your still trying to work a full time job. Maybe someone who has actually done this before can offer their perspective

I kind of disagree with this. I started building my previous startup while working full time in another job. It is easier than one might think

It resonates with me a lot. I have this idea I would like to test. But once I'm done with my work (I'm a PM under french lockdown, I spend my whole day in front of my computer), I really need to disconnect, spend time with my 3 kids and wife, or exercise.

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...

I also was thinking like you but at the end I understood that I shouldn't have huge expectations. I decided that I just need 1h each day for implementing MVPs. After 3 months, I get used to this and can't imagine day without this hour.

I'm in a similar situation, although with only 1 kid yet. I think you're spot on that building a working prototype in your free time will be either slow or exhausting.

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.

But most college students don't have enough domain knowledge to bring innovation

Do 4 hours every Saturday evening after all have gone to bed for 6 months and you will have an MVP.

This trade-off doesn't go away when you start a company. It actually gets worse because not only do you lose that personal time, but you also have 100x the amount of stress.

"Too much building and not enough selling" is very common. For example see how many of these failed projects blame a lack of marketing: https://successfulsoftware.net/2010/05/27/learning-lessons-f...

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.

Not only horrible unhealthy lifestyles, but horrible unhealthy codebases.

So true. Are they showing their code to their customers? Nope.

No - bad coding practices for a company are like bad personal health practices like eating junk food and sitting on the couch all day. It won't hurt too much when you're young, but you sure pay for it later.

The vast majority of startups fail and usually they fail early. Increasing your early chances of success at a cost in the future (which you may never need to pay if you fail) is a net gain.

Alternatively, learn to write code well in a paid job, and start a company when you know how to do things right.

The right thing is whatever the business needs to succeed and spending more time on cleaner code isn't it for startups. You're assuming employees don't know how to write cleaner code rather than them choosing not to for the sake of lower time to market.

My experience of startups isn't that the code is terrible because they were in a hurry, it's because they were inexperienced or learning to code on the job. Experienced coders might cut corners but they'll make good foundations to fix things layer.

I'm willing to bet most startups have horribly unhealthy codebases, at least that has been my experience. However, it ultimately doesn't matter much. The things that matter are the things that gain and retain customers, like stability, uptime and functionality. While it's unlikely you'll have stability and uptime in a bad codebase, they're not mutually exclusive.

Technical debt is only bad if you don't plan to pay it back.

Spot on.

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.)

Agree. One can have very unhealthy lifestyle and still make shit loads of revenue. But I wouldn't recommend it to anyone.

Correct. The other thing selling does is give you very instant feedback on whether your product actually solves a problem at all and if you are marketing the value proposition correctly. You have product <> market fit if and only if people are paying you. Alphas and Betas are fine to point you in directions but money talks.

> 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 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.

Reply on news.ycombinator.com