Ask HN: Important nonobvious startup/business lessons you've learned?

Know when to walk away. Be aware of the signs you should, and heed them. When the people you respect are all leaving, there is likely a solid reason to do so, yourself.

And when you're leaving, if the company suddenly feels compelled to grant you more stock options, or increase your salary, keep walking away.

You have it completely reversed, a rock solid codebase is much more important in an agile environment than a waterfall one. In waterfall you just need to tick the feature boxes. In Agile you not only need code that readily accepts changes, but you need to provide visibility to the business side about the state of your technology so they know not only the opportunities but also the costs of the problem.

The only reason why this becomes a phase that burns developers out is that writing high quality software is hard, under-appreciated and needs to be painstakingly learned by experience and guidance by experienced mentors. But most projects in the industry are complete shitheaps where the seniors need to spend all their time fighting fires instead of teaching the craft to juniors. No wonder developers get burned out.

> Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion.

Thanks for your awesome reply! Means a lot to me! Let me dive along! To make this discussion more interesting from the start, I'm going to say that we managed to raise $2M with an MVP written in 4 months, and now I have to rewrite everything because the business team pivoted 180 degrees. Bear with me a little.

> Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.

The only failure I feel is that I haven't really managed to employ the right people for the right job. This forces me to take care of everything - really, like I have to refactor Typescript interfaces or CSS for other people, which are trivial things but time consuming. On one hand, I have to move fast and deliver features as a team, but on the other hand, I have to teach people how to properly do their job.

> For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.

The expression 'building cool rock-solid code' might've been just me venting my frustration - it's not that hard to do a good job it if you know what you're doing. But you're 100% right: I'm wasting resources if I don't implement the business needs in a timely manner. I actually managed to pull that off before raising the money.

But I'm also aware that difficult problems have more than ordinary solutions. I took care of our infra, from Proxmox, docker, Google Cloud, Jira, Confluence, Cloudflare, to Slack, emails, Jira, Confluence and others. The business team just says: "we could've employed anyone to do that".... really ....

> Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.

Actually you're right and this is the reality. IMO, I see the grand scheme of things, where I know what "should" be done, so we could attain 100% autonomy and be able to scale without coding anymore, whereas the business team needs some features NOW, forcing me to do shortcuts. This is why I'm pushing to build a roadmap, but it's obvious we cannot do it right now.

> Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.

We have 10k users, we have the market fit, we have the funding. The only problem is that I built everything for a specific business case, and now I have to abstract it to support the previous business case, plus new others, which are completely different. It's like building a new product from scratch. And my pain is that we could've thought about it from the start - this would've allowed me to abstract some of business logic.

> Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.

Exactly, no plan is going to be perfect, and we're constantly iterating over it, but we didn't allowed ourselves to start this damn plan from the beginning. We thought: "let's do it, see what happens. Wow, it worked! Let's do even more now, and be backwards compatible"

> What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.

EXACTLY! We had poor product and domain knowledge - basically we built our way without having a good sense for them. The code is flexible enough: monorepo with apps and libs sliced and combined in separate packages, while trying to follow 12-factor-app methodology as much as I could.

> Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.

This is where the friction comes inside the team. I want to plan as best I can do it, and then just execute. Talking about my experience, I was employed in a German project where people actually took their time to plan thoroughly, at a point where they knew exactly what people they needed and almost the exact buget for the whole thing. And it was a joy to code and do your thing. In retrospective, looking at this German team, they really knew their tools and craft.

> Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!

I've been using solutions like Supabase, Hasura, n8n, Prisma, just to move things faster. IMO, it all boils down to understanding the product and domain. Then the table schemas, data structures, interfaces, services, etc, will start fitting into place. In my case, they still do, partially, but I could've done a better job at abstracting them from the first place, rather than patching or rewriting shit at this point. I'm lazy.

My takeaway, even it might sound childish or wishful thinking, is this: 1. I won't start a startup with non-techincal founders anymore 2. I won't touch a single line of code if I don't understand 100% the product and the domains 3. I will strive to employ only the right people for the job and I will document everything from the start, so the onboarding curve would be low 4. I will enforce best practices, standards and internal protocols when it comes to writing, testing and deploying code. 5. I don't want to think when I read code; a quick glimpse is what it takes: looks good, passes tests => OK 6. I want to be able to delegate as much as I can, without fearing that quality might suffer 7. I should follow my guts and speak louder when the business team wants the Pyramid of Giza - at a point looks like a challenge that I accept, but then it translates into lost nights for myself.

I might be biased, I know I'm not that experienced yet, I know there's no such thing as a perfect world, but I can strive to achieve that. Maybe I'm just venting - nonetheless, it's still possible to build a product without having a gun pointing at your head.

What do you think ?

Don't build software for salons; start your own salon that uses software you create, and make that your competitive advantage. Don't know how to cut hair? Then you probably don't know what software would help in that business anyway. Find a business you can do yourself, and help yourself using your technical skills.

This is also why this (very good) advice is not so easy to follow in real life. You need multiple skillsets.

If you're operating in a grayish legal area, start worrying about laws once you're so big that your government worries about you. If I did my last startup now, I'd spend all the money I spent on lawyers, on marketing. By the time we had on paper that our business is operating within the law, we were down a big chunk of money that we later desperately needed to gain traction. If you fail, no one will care to sue you anyway (specially not your government). But if you make it, you'll have money for lawyers and money to eventually make it more legally acceptable.