I think you have a big problem with selling direct to homeowners. Most HVAC companies will not touch a homeowner-purchased system. So if you’re selling direct, then you’re going to need DIY quick connect line sets like Mr. Cool.
441 karma · joined October 22, 2014
I think you have a big problem with selling direct to homeowners. Most HVAC companies will not touch a homeowner-purchased system. So if you’re selling direct, then you’re going to need DIY quick connect line sets like Mr. Cool.
We should talk. If your open source roadmap includes getting rid of your npm dependency then we might just migrate to Pynecone for our front-end.
The thing is, we were already employed by the bank to run risk management and the bank already had the subscription to the software. So from the bank’s perspective it was close to 0 marginal cost to conduct the stress tests because even if they weren’t required, we would be doing them anyway as good risk management practice.
If a bank says that stress tests are too expensive to run, that means that absent regulatory requirements they would perform no risk management.
The difference here is that SVB’s customers did not understand proper corporate cash management practices and had deposits far in excess of FDIC insurance. So from a game theoretic perspective if you hear a whiff of insolvency then you want to pull your cash as fast as possible.
This is on startup CEOs as much as it is on SVB.
If your firm’s hiring process has inadvertently optimized for #1 then WFH will not work. If the firm has managed to find enough #3, then RTO will damage company productivity.
Ironically, the fact that Apple was able to make the migration from PowerPC to Intel back in the day was because they gave a #3 type employee a special exemption to WFH.
One of the things remote-first companies are going to need to do is to migrate from interviews that are centered around “what you know” to “show me you can get stuff done”
The home page is a setup where you setup your dataframe. If you already have some csv or something, you can read that rather than getting user input.
The app will randomly select 2 rows of the dataframe and display them as side-by-side VS cards. You then pick the winner from the two. Then the app will repeat random selection/winner as many times as you want.
There's a results page that shows the ELO ranking of all the "players" as well as the history of all the "games" between the players.
I implemented not with a "swipe" interface but just with side-by-side cards and you click on one. It wasn't clear to me how swiping would work when you're choosing a winner between 2 objects rather than making a yes/no decision. If you have an idea for how swipe would be useful, I'm all ears.
Live App: https://compare-and-rank.pycob.app/
Source Code: https://github.com/pycob/sample-apps/blob/main/compare-and-r...
Do you have any examples of the pet projects posted on GitHub? I could try to take a stab at giving it a front-end, which would probably be the first step in making your pet projects SaaS
Live App: https://markdown-to-json.pycob.app/
Source Code: https://github.com/pycob/prototypes/blob/main/markdown-to-js...
App: https://hn-analytics.pycob.app/
Code: https://www.pycob.com/view_code?code_owner=hn-analytics
I’m not sure if it’ll go anywhere but I like the idea that it’s interoperable with existing JS/TS packages.
Just a list of random stuff I’ve worked on, including a lot of abandoned side projects.