Live data from Hacker News

Why Slight Failed: A Slight Post-Mortem

colmanhumphrey.com

31–40 of 77 posts

Re: Why Slight Failed: A Slight Post-Mortem

#31
> Slacking around SQL snippets, schlepping around CSVs, devs having minor inconsistencies when running a bunch of ad-hoc queries: problems for sure, but not major ones for a small company.

This is a general theme: it is hard to fight "good enough". Even in a big-enough company, a competent engineer will have a good enough way to manage queries, while incompetent ones won't care. In the end, very few people will want to pay for such service, or even want to learn such service.

Re: Why Slight Failed: A Slight Post-Mortem

#32
post #11

Earlier quoted context omitted.

> 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity. This is one where having an open-source core helps a ton. In my role I'm often the one finding these and being a major influence in pushing for or against them, and one of the key things that pushes me away is having no exit path in case the company goes under, pivots or otherwise…

In some cases, an alternate option is to put the code into escrow. At one of the bootstrapped startups I was a principal at, a very large enterprise customer stipulated that we had to work with a much larger entity (with which they already had an MSA) and technically, the software was licensed and delivered through the entity (who ended up getting the support contract in exchange). The code was put into escrow with t…

Is there a good way for a startup to find a vendor who has agreements with larger companies and is willing to ship the startup's product?

Re: Why Slight Failed: A Slight Post-Mortem

#33
post #32

Earlier quoted context omitted.

In some cases, an alternate option is to put the code into escrow. At one of the bootstrapped startups I was a principal at, a very large enterprise customer stipulated that we had to work with a much larger entity (with which they already had an MSA) and technically, the software was licensed and delivered through the entity (who ended up getting the support contract in exchange). The code was put into escrow with t…

Is there a good way for a startup to find a vendor who has agreements with larger companies and is willing to ship the startup's product?

You can often search for press releases with big name services vendor or big name software vendor + your target customer and see if there are press releases. Many large companies work with specific partners for IT services and these providers are the ones with the MSAs that you can attach to.

Examples: Cognizant, Tata, Accenture, etc.

It won't be easy unless you know someone on those teams already. Sometimes if you find a customer that loves your product but cannot procure through a startup, you can ask them if they can refer you to one of their partners and see if you can work something out with them (most of the time, those partners will want an arm and a leg).

Re: Why Slight Failed: A Slight Post-Mortem

#34
We shouldn't forget the history of SQL. I wasn't there, but my impression has been that it was originally written so that non-technical users (business decision makers) could write queries and have access to data in order to make business decisions. The data accessibility feature is ostensibly already built into the language. I think this original vision never ended up working out. I believe that business decision maker brains are not the same as SQL query writing brains. You need to be able to choose some facts, ignore the rest and persuade people.

So this product adds (added) a middle layer in between the end user and the database. Either the user could learn this, or they could just learn SQL. But if the end users really care about what the data shows, they might as well just learn to write SQL queries, they aren't that hard. The reality is that end user business decision makers may not care that much about the SQL query output from data sets that may have a whole series of built in errors and biases anyways.

I think business decision makers want to make decisions based on gut feel. In bigger companies and publicly traded companies, they then pay data analysts to produce data analyses that support those decisions, to CYA. In order to accomplish that, you don't need this tool, you just need vanilla SQL.

The successful (LLM) tool would essentially have the business decision maker write a prompt that says: "I want to do X. Write me a report using this dataset that supports my decision". Yes?

Re: Why Slight Failed: A Slight Post-Mortem

#35
Man, I do really miss these postmortems on HN. We used to see several a month back when the site was more startup-focused. Great read! Don't want to dogpile with criticism, I'd just suggest brushing yourself off and trying again (heck, after multiple failures, I still am!).

Re: Why Slight Failed: A Slight Post-Mortem

#36
post #19

> Large companies didn’t want it enough to deal with our lack of “big company features” (enterprise SSO, compliance certifications... > We spent a bunch of time on multi-tenant infrastructure... I'm in a position where I talk to SaaS businesses all day about both of these. Probably over 1,000 at this point. We help a lot of these companies add the enterprise features they need, but it's often a shame to hear they're…

I'd love to hear more insights about on this. I'm just kicking off a B2B SaaS, have a rough idea of the checklist in my head, and am trying to balance core tech development with box checking.

GDPR & ISO27001 compliance are the important ones, but depending on the industry there maybe others (HIPAA for example). You need to hire an advisor and start writing everything down. Being able to hand over compliance documentation along with proof of an audit is absolute gold. If you don’t do this, be prepared for a mini-audit on every sale (if you get that far).

Sales to governments will likely come with even more compliance requirements, national security audits, and potentially staff vetting. It’s not worth it early on unless you’re really well funded.

Compliance does actually scale with the business, so it’s not particularly onerous at the start. Although it can get out of hand if you’re not careful. Compliance should be pragmatic.

SSO is clearly one of the major factors for integrating anything into an enterprise organisation. Their IT team will want to have complete control over who has access, when somebody leaves the company they want to make sure that they can shut them down immediately, not have to reach out to third-party providers, or login to multiple systems. Ignore this at your peril.

Independent penetration tests are also really important.

You can usually resist requests for self-hosting or multi-tenancy if you have all the above, but not always. If they don’t think you’ll be around tomorrow, then they won’t touch you.

Re: Why Slight Failed: A Slight Post-Mortem

#37

> Distribution Incredibly hard with B2B/enterprise SaaS, even if you solve a problem that they have. Across three different startup efforts, I've learned that even if some team loves the product: 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons, 2) it addresses a key part of their workflow, but the primary process exists in some *other* system so they are not willing to add a new…

> 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons

What are the common reasons and why can't they be dealt with? There are platforms like WorkOS that (supposedly) make it easy to do compliance stuff.

Re: Why Slight Failed: A Slight Post-Mortem

#38
post #3

I would also maybe add "picking a name that's impossible to Google and hard to remember". The number of emails I get along the lines to "Your trial period of Foowazzle will expire soon" and my reaction is usually "I can't remember what the hell Foowazzle is". In fact the reason I often fail to actually use trials of potentially interesting services after signing up is because I forget what they are called and can't f…

In all our automated emails, we put something like "As a reminder,[name of company] is a ..."

That's better than most but it only solves half of my problem.

Re: Why Slight Failed: A Slight Post-Mortem

#39

> Distribution Incredibly hard with B2B/enterprise SaaS, even if you solve a problem that they have. Across three different startup efforts, I've learned that even if some team loves the product: 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons, 2) it addresses a key part of their workflow, but the primary process exists in some *other* system so they are not willing to add a new…

> EDIT: A key lesson learned for technical founders seeking co-founders where your target market is enterprise/B2B SaaS: the best non-technical candidates don't want to take the risk in a startup (because they are already making bank with enterprise sales) and most candidates that want to do a startup probably aren't the best candidates (because otherwise, they'd be making bank doing enterprise sales for an incumbent).

Disagree. Those are two very different roles - the most successful enterprise AE's are specialists and most of the time aren't going to have the generalist skillset or mindset that is needed to build a business from scratch.

Re: Why Slight Failed: A Slight Post-Mortem

#40

A really level-headed take on what must have been a very tough experience. I'm reminded of the Star Trek TNG quote "It's possible to commit no mistakes and still lose that's not weakness, that's life."

Had to look it up! I won't link the youtube but it is from ST:TNG s02e21 "Peak Performance"
Post reply on HN