Hacker News Reader

Comment by danpalmer | Hacker News Reader

Hey, nothing to add to the pricing advice, but do be aware that having one big customer paying a lot of money could well change your product/engineering culture, or even the company culture.

Imagine having that customer and then them saying they're considering dropping you in a year if you don't have a particular feature that's not on your roadmap (or maybe not even that related to your product in your opinion). Do you drop everything to please them, or do you stick to your plan? How much pain do you endure to keep the one big customer happy?

I've seen close friends work in companies with 2-5 large customers, and the team regularly endured significant pain to keep one of them happy because it would be business-changing to lose one.

Unless you are very intentional about how you handle this sort of thing, it'll be bad by default. Don't take this as discouragement, but do make sure you really know this in advance.

View on HN

I've seen a startup in the Netherlands that never made it beyond mega-client #1. They are still doing well, but basically they have become a service provider for what was their first bigger customer and, years later, is now their only one.

This is in line what others here are warning, but the way I would deal with it is specify a price where either it is similar to the single-seat price with no longer term obligations OR a much reduced price with a very long contract duration (so they can either make you so rich that you don't need them or they can save money but then they cannot threaten to leave you as a means to elbow you into building off-roadmap bespoke features that only they need). Note that this is theory ;-) I have not been in that situation myself.

> Unless you are very intentional about how you handle this sort of thing, it'll be bad by default.

I don't think it's necessarily bad by default. Any single customer (large or not) is going to be clearer with their requirements, than trying to distill something that can fit several other customers' problems. It tends to put firmer constraints on your design, brings more clarity to your direction. It also depends on what you're comfortable with - personally I prefer to focus on solving the technical challenges, so I find that constraints on product direction leave me with more brain cycles to tackle the tiny details. Once I have a well-engineered solution, it tends to generalise more easily.

I don't think it's necessarily bad by default.

Everything I've read indicates that bad by default is the way to bet.

Small companies routinely think one big customer will have them set for life. They will have it made in the shade.

It seems to be the small business version of the "winning the lottery" fantasy.

And most of the time, you become their bitch. They make demands, you have no real choice but to meet them because it's such a big chunk of your revenue that you can no longer make payroll without them.

Rule of thumb: Don't let one client be more than 20 percent of your income if you want to actually remain an independent business and not get pwned by these people.

They are unlikely to worry about your welfare and you can get into financial hot water if they come up short financially and decide to stiff you.

They likely have a legal department or lawyer on retainer who has told them just how much they can legally shaft you and it can threaten to put you out of business.

Sometimes small businesses who survived such incidents change their stated policies in defense after nearly going under.

> Everything I've read indicates that bad by default is the way to bet.

Agreed. Once the customer realizes that they make up the vast majority of the vendor's revenue, 99% of customers will press that leverage for everything it's worth. They'd be irresponsible not to!

They might not be too demanding or screw the vendor over right away, but when push comes to shove they will pull that ripcord faster than you can say "Net 30".

Here's the double whammy: chances are that the customer's success will be correlated to the rest of the economy, so when the vendor really needs the money is exactly when the customer will stiff them.

The only exception is government, but that's a different class of sales.

You describe being a freelancer (or some of US folk call contractor).

It's a pretty good & comfortable life ;)

> Rule of thumb: Don't let one client be more than 20 percent of your income if you want to actually remain an independent business and not get pwned by these people.

I agree in principle but how does this work in practice?

Keep rejecting clients until they are right sized?

> They make demands, you have no real choice but to meet them because it's such a big chunk of your revenue that you can no longer make payroll without them.

Would you have been better off never having had that money in the first place?

Possibly. You could have made money from other clients who weren't going to do that to you.

There are only 24 hours in the day. Time spent serving them is time not spent on other clients.

One piece of advice I've seen: Diversify your client base if you are seeing too much of your income from one or a few clients.

We even did this to ourselves, internally, at a prior workplace.

They wanted a new web-based system to make it easier to onboard client work (less coding!) but picked a test case of a fairly complex client. The idea was of course some combination of them being complex enough to expose requirements, needing a rewrite anyway, and hoping they'd pay for some of it (funding the system development).

What happened in the end was a fundamental tying of the mental model of the software to this particular client - like some weird cousin of Conway's Law, the system was overly complex and complicated for the vast majority of our simpler client work because it was too strongly coupled to the business model and structure of this major client and their work. And it never got simpler, because by picking this complex one to start with, the sprints were always racing to catch up. These wounds were all entirely self inflicted.

Seen this too. Sometimes companies think of themselves (or aspire to be) product companies but are really service providers. Not that there’s anything wrong with one or the other the same strategies don’t necessarily work for both.

Absolutely, I've gone through this at most of my past employers and am currently experiencing it. We've always had a very careful engineering culture, taking the time to thoroughly plan and future proof features, and it's been great. But now we've got a big industry name waving a blank check in our face and we're suddenly rushing features to win their business. Our architecture is becoming brittle and we're spending as much time fixing defects in the new features as building them.

We're a startup and I get why management sees this opportunity as our big break, but I have to wonder if it'll be worth it in the long term. Sucks to watch the best codebase you've ever worked on devolve into the standard enterprise ball of mud in real time.

Agreed, but the switching costs for for this customer are likely significant, especially for 5,000 users. Something to keep in mind if one is to gauge the level of idle-ness to their threats.

Study Crossing the Chasm, this is the exact challenge of doing startups focused on enterprise and that book is fantastic for understanding how to navigate it.

A multi-year contract could mitigate that risk.

Reply on news.ycombinator.com