23david

AWS was super greedy and honestly I’m glad elastic even survived their aggressive tactics.

Their Q4 earnings had some conservative projections and higher expenses due to investments in building out their VR teams, and this was enough of a catalyst that the short sellers were able to create a panic.

Fine to hate the company and management, and their politics, but following the money, this seems to be a wildly successful effort to manipulate sentiment and cause retail investors to panic and benefit short sellers in the market. There’s huge money to be made by hedge funds in shorting Meta on the way down, and then buying it again on the way up.

Or maybe they’re really going down to $0 … which is more likely?

Great advice.

So once you start getting traction and customers, there's some internal product manager evaluating whether it's worth entering your market.

The shareholders agreement, even if 'boilerplate', may only give the company the right of first refusal on the sale of shares. Even if unauthorized sales are completely disallowed, if you find an interested buyer there are still ways to craft a legal agreement where you for all practical purposes have 'sold' the shares.

But if the company isn't very successful, there may not be any investor interest, which would make the legal details pretty irrelevant.

I'd recommend getting an attorney to read over your agreements, and also try and gauge investor interest by listing your shares on one of the secondary market marketplaces.

I know someone who just came out of a job where he was hired to take over most of the day-to-day for a founder in a similar situation. It might be useful to discuss the situation and see what recommendations he has. Feel free to connect via Linkedin and I can put you in touch.

I don't find the title 'Systems Engineer' to be in widespread usage at tech startups in SV, so I'm not sure what to expect from one. To be honest, I would expect Systems Engineers to be working on hardware.

The infrastructure automation work done at modern tech startups is best described by the title 'DevOps Engineering'. If you're posting a job where the requirements include using automation code to set up and configure CI/CD, monitoring, alerting, Databases, Analytics, AWS, GCE, Heroku or other 3rd-party SAAS tools, the job title in widespread usage that encompasses that is DevOps. The Webmaster, Ops, DBA, SRE, IT, Systems Engineer, and SysAdmin titles describe different skillsets and are therefore less useful for describing a role with these kinds of requirements.

Here's an AWS-specific, but otherwise useful reference of a modern 'DevOps' skillset: https://aws.amazon.com/certification/certified-devops-engine...

Any sufficiently complicated infrastructure that has uptime requirements and significant revenue associated with it is going to have a DevOps Team (or the equivalent) ultimately responsible for ensuring that things are working. I guess it's possible to turn your entire dev team into part-time DevOps engineers, while still calling them Software Engineers, but I've usually found that doesn't work long-term and causes employee retention issues. It's like saying your company does 'No-Support' because you don't hire Support Engineers, while in fact you've enlisted your Software Engineering team to handle all support requests.

Also, if you're working in a regulated field like Healthcare or Finance, or anything that touches PII, your developers often can't have access to deploy code directly to production. Again, you could maybe work around this in the short-term by turning all developers into developers+devops, but they're different skillsets.

So it looks like Github takes a 25% fee. I thought maybe they would do something more innovative regarding the fee structure, or maybe have a lower intro fee like 15%. But here is seems pretty much on par with the 30% of the Heroku marketplace.

It's a complicated tool for sure, but once it was all set up we finally had visibility into a complex multi-account AWS spend, and could start generating automated cost reports for each company business unit and major customer.

I wouldn't recommend going to the effort of building a custom setup... AWS billing is just too complicated and it changes frequently to add even more layers of complexity. As one example, the recent change to add RI size flexibility completely changed the calculations for RI costs and recommendations.

I've also used cloudability and cloudcheckr in the past, but both systems had serious drawbacks. In my opinion cloudhealth is a much more advanced/professional system at this point.

I definitely agree that Amazon, Azure and Google are squeezing the OSS vendors and other SAAS providers by offering their own hosted options. From experience, I know that it's possible to still compete with the large cloud vendors, so I don't think that they're necessarily an existential threat to OSS businesses. But if you're a VC-backed company watching your valuation and your investors are expecting a 100x return, I think that cloud vendors jumping into your market makes the big investor payday a lot less likely. And if you want to compete in the SAAS market your company needs to get really good at the managed hosting business.

IANAL, but if all options are on the table is it possible to have a modified OSS license that would exclude 'hyperscale' cloud vendors from offering a hosted version?

If I'm hearing you correctly, it sounds like you have 3 people, ~$1.8 MM net profit and since your tax burden is low it looks like you pay out most of that by the end of the year. So are you looking at annual compensation of $500-600K each?

Why not stop paying yourselves so much and reinvest more in your business?

IMO, it's a lot easier to hire and take risks on money if it's set aside in a pool of money that you've designated as NOT being for founder salaries. If you cut back to a more reasonable $150-250K salary each, you'd have tremendous free cash flow available for all sorts of hiring and even acquisition possibilities.

Several months ago it seemed clear that the team was overly optimistic, and it's just disappointing to see that now the clustering will be available only in a paid (minimum $400!) option or on their hosted service.

I understand the business considerations here, but it feels like a bait n' switch for all the people who evaluated/used InfluxDB in single-node operation as a temporary measure while giving the team ample time to work out the clustering kinks.

Lesson learned I guess... but dang what an expensive lesson.

The fact that founders sometimes are able to participate seems to imply that it's a possibility for regular employees too if the appropriate legal docs were standardized.