HN user

shooker435

141 karma

sebastian@sebhook.com

Posts3
Comments37
View on HN

Agreed. I'm a huge fan of his work and have spent some time in Oak Park as well.

That being said, the most accurate/honest depiction I've seen is a 2-part series on PBS. I think it does a great job of capturing the genius alongside the troubled hubris.

Wright left Oak Park and separated from Tobin Wright in 1909. Before leaving, he divided the studio and the home, allowing Tobin Wright and the children to live in the studio wing and rent out the house for income. Wright sold the property in 1925 and later owners divided the building into six units and neglected to preserve the historically significant property.

This is a really generous interpretation of what happened... He ran off to Europe with one of their neighbors, and his ex-wife (not divorced yet, though!) was left high and dry with no money and was forced to turn the studio into apartments for income.

Anyone on the front page last night likely agrees that this was a cut and dry data leak...

Is this class action lawsuit territory? How can they just sweep it under the rug like this?

We've been building https://nimstrata.com/ for almost three years now, we put Google's Vertex AI product discovery algorithms on Shopify and Salesforce ecommerce storefronts.

At a high level, Google does not have a product culture, so there is a lot of white space for companies like ours to make adopting Google Cloud APIs much easier for less technical users.

It's also wild how much Agentic AI is creeping into all of our conversations - this space is constantly evolving as we're building.

The internet is having one heck of a day! we focus on ecommerce technology and I can't help but think our customers will be getting nervous pre-BFCM.

The author touches on it briefly, but I'd argue that the cloud is immensely helpful for building (and tearing down) an MVP or proving an early market for a new company using startup credits or free tiers offered by all vendors. Once a business model has been proven, individual components and the underlying infrastructure can be moved out of the cloud as soon as cost becomes a concern.

This means that teams must make an up-front architectural decision to develop apps in a server-agnostic manner, and developers must stay disciplined to keep components portable from day one, but you can get a lot of mileage out of free credits without burning dollars on any infrastructure. The biggest challenge becomes finding the time to perform these migrations among other competing priorities, such as new feature development, especially if you're growing fast.

Our startup is mostly built on Google Cloud, but I don't think our sales rep is very happy with how little we spend or that we're unwilling to "commit" to spending. The ability to move off of the cloud, or even just to another cloud, provides a lot of leverage in the negotiating seat.

Cloud vendors can also lead to an easier risk/SLA conversation for downstream customers. Depending on your business, enterprise users like to see SLAs and data privacy laws respected around the globe, and cloud providers make it easy to say "not my problem" if things are structured correctly.

Claude for Excel 9 months ago

This isn't built for Excel users who use Github and Claude Skills, it's built for Excel users who would run away from Git commands.

There's probably a middle ground here. Making a profit ASAP is only really possible if you're selling expertise, such as consulting. I really like the emerging term, "seed strapping" which aims to address this conundrum in the startup world: raise just enough to build the first iteration, then act like a bootstrapped business.

This seems super powerful. Would you recommend that an app developer who is creating App Blocks for PLPs (Search, Collections, etc.) use these new Web Components instead of building everything themselves?

Sounds like microservices deployed from a monorepo...

Which honestly may be the future if LLMs stay in a dev's toolkit. Plugging in an AI model to a monorepo provides so much context that can't be easily communicated across microservices in separate repos.

In addition to having 1 service with vastly different scaling requirements, having 1 service with vastly different availability requirements may make sense to separate as well.

If you need to keep the lights or maintain an SLA and can do so by separating a concern, it can really reduce risk and increase speed when deploying new features on "less important" components.

Great find and post.

I've run into this exact thing. Luckily rebuilding a container doesn't cause downtime for us and 99% of our changes require rebuilding an image, so I've just left it as is...

It is annoying though when we make a small infra change and have to wait for the container image to build...

I'm convinced it can only happen if the company is laser-focused, or really small.

I also believe resource constraints create innovation, which these companies are particularly poised to do.

There's a hidden glimmer of wisdom in here, which is to let your (cash) customers contribute to funding your (equity) business growth.

My theory is a niche consulting firm can perform services to make enough money to build out a product, and better yet, they're being paid to learn about user requirements along the way.

I'm on a similar journey right now, and it's always difficult balancing the dopamine and temptation of a short-term cash injection at the expense of development time spent on the core product we're scaling.

Or you haven't found product market fit yet, which sounds like what happened in the Kit.com example referenced in the article.

This mindset assumes that the only measure of success is monetary. If he left Google to try and get richer than staying at Google, then sure, he probably lost.

However, he kept trying again before job hunting or returning to big tech. This tells me the monetary factor was smaller than something else.

You mention the underrated educational experience in your last sentence, but there's so much more than that. He was probably never worried about his autonomy, being laid off, working with (or for) people he didn't want to work with, corporate politics, or anything else corporate bureaucracy introduces. This likely freed up his brain to be more creative and actually be used to 100% of its capacity.

I believe the obsession with TC in tech is highly problematic and there are a lot of talented folks optimizing for promotions via internal politics, rather than solving real problems for real people.

I also wish healthcare wasn't tied to employment, but that's a post for another time.