gkapur

Very cool -- I'm curious how many different providers of at home testing you abstract away with your API and also if you have your own services arm or are abstracting away third party providers?

Angellists data is flawed here—- you ideally want to look at seeds that are completely new or coming from sub $2 million pre-seeds. They include seed extensions, seed extension extensions, high priced note extension to seed rounds, etc. and when the market slows down you see a lot of extension rounds which pushes that number up but those are not really new seed rounds.

There are a host of other way their data is flawed as well :) but that’s a much longer topic.

Retool works well -- they have their own version of SDLC in the $10 plan (staging versions of resources.) If you hook that up to something like Neon (https://neon.tech/), you can have staging branches of a database, as well.

The issue I have with many of these products is that a lot of the logic should actually sit closer to the backend (ie. better REST APIs, etc.) If your engineering team is managing the backend anyways, it shouldn't be a huge issue maybe?

I made an investment here (moving the non-UI logic closer to the database) but it's too early to really see if it will work.

I think they are claiming they can mine something like 10k bitcoin/year (https://twitter.com/ThePrivatier/status/1547613977231798272) going forward but I have no idea what the COGS/cost between labor/maintenance and electricity is to mine that. If it's say 50%, then those "mining assets" will pay back in 7 years.

Seems like people are going to take a large haircut on whatever they deposited and then maybe get back some incremental cash over time.

It would be pretty cool to do some quantitative analysis of how remote friendly these company's stacks actually are, ie. are they "remote friendly" or actually friendly to remote employees...

I don't know if I agree. Adyen is worth $45 billion euros (so $45 billion :) .) From their last annual reports, Adyen '21 GPV: $561B +70% YoY; Stripe '21 GPV: $640B +60% YoY but Stripe has ~2x take rate on Adyen because they are more PLG versus Adyen has many more enterprise customers.

So $74b is probably about right or maybe even low?

Even if they do resume withdrawals, they will have to limit them.; Once faith is gone in a business like this, a "bank run" will ensue no matter what. It's not surprising that Blockfi is being bought for pennies. Will be interesting to see how many users of these yield products try again even if they are able to get their money out. If they aren't, I imagine they will be scarred for life.

I'd go with 3: 1. First try to think through a Kubernetes-native development workflow. Some tools here would that could be helpful are DevSpace (personal favorite), Tilt, or Skaffold or you could use Okteto for something full stack potentially. Alternatively you could use Minikube or Kind locally but these are more local adaptions rather than K8s/cloud-native. 2. Create a cluster on GKE. 3. Figure out how you want to do CI in your workflow. 4. Profit?

The challenge with serverless is building systems that rely on more complex backend processes and existing code and doing things like testing using most of an existing codebase. Serverless is great for nodejs/javascript stacks that are database and front-end heavy but don't need more complexity like queueing, event streaming, or more complex architectures. Then serverless becomes a huge mess normally and the developer experience becomes a giant catastrophe, as well.

Here the OP kind of got caught by the terrible DX that is almost natural to serverless IMO.

Just curious -- what are the performance trade-offs here? I assume you are basically querying each individual database and then doing a series of joins by doing additional queries? Or are you doing something more sophisticated with cache-ing, etc.?

I would assume the idea is that this is native to the deno runtime whereas some other frameworks like NextJS and Remix are "node native?"

Full time investor here. There have been some clear changes in the market that others have pointed out: 1. Diligence windows have increased. Nobody is rushing to deploy capital. 2. Series A and beyond feel fairly frozen at this point in time. 3. Seed valuations have compressed a bit towards pre-seed. 4. Your average joe feels poorer and is concerned about the market and future funding.

I always encourage every company that is raising to start by establishing to lay of the land for them. Are they vastly outperforming? Amazing traction? Is there team extremely credentialed? Well connected? Hot space?

If you have some of those, you go the the VCs who invest in your market (research companies in your space but not directly competitive and see who funded them) by getting connected through your network and you have a reasonable shot at someone being interested at some price. You then try to use that pricing (if you think it is unfavorable) to drive other investors to a decision -- investors feel FOMO.

If you don't have this, you normally simultaneously build while either: 1. Joining an accelerator. 2. Meeting people about town until you find a believer. The slight difference in this market is that angel investors may be less likely to invest on their own because follow-on funding is an existential risk. So you likely have to find a true believer who can write a bigger check or is comfortable with that risk.

Cool idea -- in some ways this "deno"-fies node, which I think is a sensible approach.

So far, Hagana only blocks outbound traffic from packages that are using the http or https modules. Support for other modules (e.g. net, dgram, dns) is coming soon.

This could be a problematic approach, though. If you are going OSS and do want to become ubiquitous, you will likely need much stronger protections. Obfuscation is not a path to security but blocking only some very basic vectors and then being explicit about it will have attackers adopt other similar vectors.

All in all, a cool first attempt at building with some work to do!

How do you think about partner versus build? Usage based billing on its own is a pretty complex topic as an example with multiple startups that have tried to do it right. It is pretty data intensive as usage frequency increases, as well. It seems like you may be trying to do too much here. Just one opinion but something to think through (build versus partner.)

Very cool -- appreciate your contributions to the OSS community/maintaining this as open source project.

Is this related to Pinterest's knox open source project? Also, how do you think about this in the landscape as there are lots of secret management solutions (including Hashicorp Vault, etc.)

These are very different; one is clickstream based and the other sits on the networking layer.

1. Most/many drugs have side effects. A “cure” for aging would have to have a very weak side effect profile as it’s not a terminal disease in the short run. 2. Clinical trials for aging would take a long time to run and be quite costly. 3. People are trying to cure this and quite a bit of money has been put into curing manifestations of aging (think all the Alzheimer’s companies or Unity Biotechnologies.) it’s also just really hard science...