Hacker News Reader

Comment by briandoll | Hacker News Reader

The main point here seems to be that the failure to build a SaaS product is blamed in part on the compounding technical debt incurred due to a fast-moving software ecosystem and the effort involved in keeping up.

The point I think most people should consider instead, is that building an app is not the same thing as building a business. Building the app is comparably easy, once you've proven that you understand the market, your target buyer, and have a unique insight/tool/solution to offer that you can deliver via software.

If you want to learn a technology, by all means build an app. But if you want to build a SaaS business, keep focused on building the _business_. The app, it turns out, is the easy part.

View on HN

Yes. The other way to look at it is that #4 on his list is the only learning that truly mattered.

>>Get your product to be something useful for others as fast as possible. Until you deliver something valuable, you only have a hobby.

The other learnings are simply things that shouldn't be done at the expense of customer development.

Wish I could upvote this twice. Roughly speaking, "building the product" is maybe 20-30% of the actual business. The other 70-80% is what makes or breaks an actual company - market research, customer discussion, sales, marketing, support, accounting/finance, etc.

>But if you want to build a SaaS business, keep focused on building the _business_. The app, it turns out, is the easy part.

This. The crux of his issue is focusing too much on tech and not enough on the end user along with the other "Big Design Up Front™" pitfalls.

Oh, I've fallen into this trap - not the technical debt so much as the getting so focused on building something cool that I ignore the business side of things (small things, such as, does anyone want this thing?). So in the end I wind up with something only I think is cool :)

On the upside, my last failed SaaS product was at least partly responsible in landing me my current job. At the time of my interview I had not yet fully given up on it. I mentioned it (the failing SaaS) because I had learned a few relevant technologies while building it.

One of the engineers interviewing me pulled it up on his laptop and said, "Show it to us." So most of the interview turned into a combination demo/technical discussion of the project. They ended up skipping the whiteboard/coding portion of the interview (which is good because I suck at those), and I ended up with a (very good) job offer. The job itself has turned out pretty good so far, too.

So, I've got that going for me, which is nice.

> The app, it turns out, is the easy part.

I dunno, I don't know anything about self-driving cars, but when the people making self-driving car SaaS say the software part is difficult I tend to be inclined to believe them.

Even if these sorts of entrepreneurship cliches are true in most cases, I don't think it's a good idea to use them to write people off without doing any critical thinking.

One person is making a self driving car company in the evenings and weekends and you think the software will be the hardest part? Someone could figure out the software perhaps but selling it to an existing car company would be near impossible but less impossible compared to creating brand new car company and getting them certified in a state.

> The app, it turns out, is the easy part.

Automating existing Excel spreadsheets is much easier for solution creation success than automating what you perceive to be a business workflow.

The only problem with not caring about the technology, is if your solution is trivial to replicate then anyone with a bunch of cash can come in with hired gun coders and out advertise you. Hard to replicate technology gives you some kind of a moat to at least slow down copy cats.

edit: Oh, I see, the guy in the article was just throwing together random open source stuff not actually developing anything of value. Never mind.

I'm not sure "hard to replicate technology" is a moat I'd often bet on, given that by definition that does not deliver any specific advantage to your customer.

User Experience. Developer Experience. Community. Those are moats you can bet on primarily because it takes so much dedication, expertise, and work. That's not easy to buy.

>User Experience. Developer Experience. Community.

But that's what I'm saying. If you find some solution to a problem that's making decent money, some guy with big capital will just come in and "fast follow" you with better user experience and advertise the shit out of it until they have a better or at least more active community. Like suppose this guy's admissions scheduling app actually started making money. Why wouldn't some big player like Pearson just come in and roll him? They can easily hire a bunch of guys to copy what he's doing and then leverage their existing relationships with the education industry to lock him out.

While Pearson have the advantage of some connections at universities and in the education sector, they also have the disadvantage of being a large and slow organization. Hiring 25 people won’t get you a better product than that lone wolf has, unless you (the one hiring the 25 people) have the vision and understanding of what those 25 people are going to build.

And from what I’ve seen of Pearson, I highly doubt they have a clue. Their existing business survives due to market inertia, but they’re very far from delivering quality products.

Education is a very "enterprisey" market in which the purchasers are not the users, who are essentially powerless.

Pearson doesn't need to deliver quality, they need to deliver functional + whatever sweetener on the rest of the contract to keep out the competition.

Ultimately, you are right. Innovative proprietary tech just doesn't matter in software. I want to believe it does, so I don't feel that I've wasted my life learning to build software. Seems like hardware and medical are the only places where innovation creates value. A software company being no different from a salty snack company is sad to admit. On the other hand starting some new brand of potato chips or soda can't be any worse than making a webapp to squat a SaaS microniche that you don't care about.

network effects and customer base are much more powerful moats than choosing one technology over another or developing your own.

hard to develop technology is a very narrow moat.

You have the first problem that well-funded competitors can almost certainly replicate whatever you built if they care to do so.

You then have a second problem that well-funded competitors can almost certainly market inferior tech as being equal to or superior to yours, if they care to do so.

Never, ever, ever, ever worry about anyone copying your stuff. Depend on your unique insight. No one can copy that. If in the extremely rare circumstance that someone copies you, be thrilled! That means you are building something valuable (which is extremely rare).

Hard to develop tech is a huge moat. The issue here is timing. Hard tech buys you time. Most of the M&A today is not done due to hard to replicate, but due to time. Even if I can replicate the tech, I do not have time to do that.

Can you name, say, three notable software businesses whose advantage was hard-to-replicate tech?

Google (search), Microsoft (OS, especially early on), Dreamworks (rendering, animation), Oracle (database, early on before OSS database got good).

It's the exception, not the rule though.

Microsoft licensed their early OS. Dreamworks led with SKG and the tech followed. Oracle always had meaningful tech competition and fought with sales/marketing.

Google is pretty true, though.

Ksplice, kdb+, Google search, Mathematica

Yes. Any tech acquisition over 1B is never done for customers. For example deep mind from google.

Just this week Intel bought Havana labs for 2B due to their AI chip hardware.

Also, look at what AMD is doing to Intel. This is pure tech play (and pure moat).

The underlying rule in play, is that the tech business is bound to "leapfrogging", I.e. a better technology can destroy companies almost overnight (see the case of Nokia). So hard tech is more important than customers.

Look what Tesla is doing to GM, etc.

I said software business, so I'm not sure why you're bringing up AMD or Intel.

As for billion dollar acquisitions.... Visio, GitHub, Yammer, LinkedIn, Instagram, Parse, etc.... shit-tons of them are done for market reasons.

Right, network effects are also moat.

But I thought you said nobody ever did large acquisitions for customers....

weird, I must be thinking of somebody else. Since it would make no sense for you to try to take both of those sides at once.

Why not. There are no sides here. There are different moats. If you want a more elaborate view:

http://reactionwheel.net/2019/09/a-taxonomy-of-moats.html

The only time someone will NOT copy you, is if the market is not worth it. But this is by definition a market that you should not play in.

Look at markets that are worth it (e.g. cloud computing)- they have products from different companies with exactly the same features.

In general, I am not sure what you are proposing. Let me publish my ideas for free, see someone copies them, and that be happy that I got it right?

Thought it was clear: "Never, ever, ever, ever worry about anyone copying your stuff."

This is bad advice. If you have a really good idea and a company in the same space with the money and resources to beat you to market sees it, it's very possible they will bring it to market before you.

Large companies like Google and Facebook will regularly feign interest in someone's app or idea (that they might want to purchase), only to roll it out themselves.

99.9% of entrepreneurs are never going to actually compete against Google, Facebook, et al. And if they do, it's actually not that hard because the entrepreneur's approach will be completely different.

That's the whole point of the advice: stop worrying about being copied. It's a fake problem.

Solutions come from hard work, perseverance, and listening to customers over years of work.

They almost never arrive fully formed and then take the market by storm, on the contrary most overnight successes have years of grinding away on a project behind them, not years of building, but years of tweaking, listening and going back to the drawing board.

The technology used doesn't really matter much, just use what you're comfortable with, because it's about 10% of the problem. The rest is hard work that can't be replicated overnight.

There was a podcast I listened to years ago that stuck with me. Every time it comes up I vow to find a link but never get around to it.

The guest proposed a model of software features and why “agile” fails for a lot of people. On a two dimensional graph of difficulty and profitability, everyone avoids the high effort, low value quadrant. That’s a no brainer.

Problem is a lot of policy ends up avoiding the high-effort column entirely.

Low-effort features are only short term differentiators, if even that. They offer no long term viability.

To have features your competitors don’t have is going to take real work.

The only loophole I know for this is if my code quality is good, what is a moderate effort feature for me may be a high effort feature for you. If my pockets are deep I can just run my competitor down, by setting an agenda they can’t afford.

Nobody's as smart as they think they are. Even if this guy was an EXPERT, as a one-man shop, he can't be an expert in everything, and "hired gun" coders can still out-code him across all disciplines in aggregate, even if he's better than any one of them in a specific discipline/component.

Reply on news.ycombinator.com