maxmorlocke

Upsolve (YC W19) | Senior Software Engineer | Remote US | Full Time | https://upsolve.org

Upsolve is a nonprofit that helps low-income and working-class families improve their financial situation through free online education, tools, and community. We have helped 16,000 families erase $700 million in debt, increased the average user’s net worth by $118,000 over 10 years, and average 4.9 stars out of 5 in over 1700 google reviews.

We're looking for a Senior Software Engineer to help build new AI-driven customer support experiences, improve the success rates of our existing flows, and enhance automation to make our users lives easier using typescript/node/react.

link: https://jobs.gusto.com/postings/upsolve-inc-senior-software-...

We review the web presence of a business as our core product offering for payment processors, etc. as they look to onboard ecomm merchants. This (and techniques like it) make a great way to find scummy actors and have a proveable piece of evidence as opposed to a 'yea, this looks off' or 'this doesn't fit the profile of what an established business looks like'. We leverage a lot of subtle signals like this.

I've found rapidfuzz to be a good, digestable C/Python integration. It's especially nice as the algorithms implemented in C frequently have good pseudocode or other language representations, so you can reference really well. The docs are in reasonable shape as well:

https://github.com/rapidfuzz/RapidFuzz

Seriously. As an engineer and engineering leader, I cannot maintain focus to code, sit in meetings, and a variety of other tasks for more than 2-3 hours without a break. It is good to get up, move around, catch up on the news, etc. Taking appropriate breaks and conducting self care gives my mind an opportunity to decompress, allowing me to come back to work more focused and productive. Very long sessions (5+ hours) without a break tend to run into a wall - I may still be doing work, but the quality drops precipitously. Sometimes, I can raise my productivity by distracting myself with home chores (e.g. laundry). Sometimes, I find a quick dip into the news or a catchup on our friend group's discord server productive. This may not be the same for all of us, but studies have repeatedly shown breaks improve productivity for most individuals. Being outside the office, I find it much more convenient to take a productive break without having other coworkers distracting me. Looking over studies and suggestions, it seems interesting to me that tasks like meditation, power naps, small chores, snacks, listening to music, and interacting with pets are much more easily conducted in the comfort of our homes.

https://learningcenter.unc.edu/tips-and-tools/taking-breaks/ https://hbr.org/2023/05/how-to-take-better-breaks-at-work-ac...

ZoomInfo is in the same general area on quality and the price per record is competitive, but they have historically required a high minimum annual spend and have a reputation for litigiousness. There are a few other large players (e.g. apollo), a few medium sized players (e.g. coresignal, mixrank), and some smaller players (e.g. thecompanies, bigpicture). There are also a lot of other folks who are not as api-oriented and are more focused around the sales/marketing experience (e.g. seamless.ai)

For a typical db.t3.xlarge instance, you're talking about 29c/hour vs 27.2c per hour. That's $157.68 as the total difference for one year's runtime, when the whole instance cost for postgres would be $2540.4 for the year, or about 6%. The larger the machine, the closer to parity. Given the absolutely small difference, I hope this isn't the dividing line in any commercial project.

Generally speaking, it's inadvisable to 'discard' migrations with django. If the migration set is getting too large, the general practice is to 'squash' migrations, which is a django-supported function for merging the migrations down to a single app. You can do the less blessed, but more simple function of nuking the migrations, updating the migrations table, and remaking your migrations... but you have to coordinate that in every environment.

For an existing database, you can easily create django models for each table, etc. There's a --fake option to update the migration table to make it think you've applied these migrations, but not actually apply them. This convinces django you've brought the database in sync. May your deity or deities help you if you did not actually bring it in sync. I've used this quite a bit in some java ee->python migrations I've done in the past.

I think this is a really naive idea, I think you're seriously underestimating the level of complexity in a real estate transaction. You're dealing with what is for many people is the most impactful and expensive purchase of their life. In that transaction, they have imperfect, limited knowledge of the market and acquisition process. Further, there are varying levels of dishonest actors within the process - with an extreme range of dishonesty present. Top that off with the fact that you're actually negotiating with imperfect information as well... :exploding_head: Having an actual expert present who can enable you to be successful is extremely empowering and much more likely to result in a positive outcome.

Now, all that being said, it's obvious there's a deficit of actual SME's who are extremely helpful in the process. I've purchased two homes... one with an agent who I feel would fit right in with the culture of the used car salesman stereotype and another who actually was that SME. She knew the market inside and out, knew what to look for in the neighborhoods, and found the problems in each house we looked at. She had connections that got us through a weird mortgage issue (multiunit home converted into one with... sloppy paperwork), helped with specialized inspections (radon issues), and provided great advice when dealing with a cantankerous negotiator. I certainly didn't find my money wasted there and actively recommend her for anyone in the NW Columbus, OH area. There's a lot that could be done to improve the situation - higher requirements for education and qualification of realtors, prohibiting companies from being the buyers and sellers agents, etc. There's a lot to automate as well. But when there's serious complexity and life changing quantities of dollars floating around, an expert should be strongly valued.

Our latest release should have more clear language on airports and 'All London Area Airports' as opposed to 'City of London Airports'. The point about multiple airlines should also be addressed.

Your point about at a glance determination of the departure/arrival airport is really good. I expect to have a UX enhancement for that next week. Currency and manually selecting multiple airports are still a fair ways off.

Thanks. Our roadmap isn't currently public, but this is on it. That being said, this is a medium-term priority, so definitely not something coming in the next couple weeks.

Works in all Chromium browsers actually. Support for Firefox and Safari is on the way, but does require some more work.

As a simple example, United probably isn't going to offer a flight where one leg is on United and another is on American. Yet, it might be substantially cheaper or less painful to take that flight. Certain codeshares may be more profitable for them to hawk, to the point where they will only show certain legs when the more profitable flight is booked. They may also choose not to show flights that are already profitable based on bookings (e.g. takes 75 economy seats to make flight with legs A->B and B->C profitable) when a similar flight (A->D, D->C) is underbooked and could use some more folks aboard. There are probably a thousand other reasons...

Your gut reaction is not wrong. That being said, I think it's wise to pick the right time to leverage this capability. Our resources are extremely limited at the moment in comparison to one of the most aggressively litigious entities in our space.

I don't know which is the biggest, there are a lot of known unknowns still floating around. Will we run out of money before we monetize? Will we have to deal with constant lawsuits? Will other innovators in the space attempt to move in our direction? Are there enough travelers willing to install an extension? Will google be google and shut us down? The ever present bus factor. All of these are legit concerns that are going into our crowdfunding risks disclosures. All are things to manage.

I don't think this is a big city thing. I live in a medium sized city in the states and I hate going to the airport. 20-30m commute there, parking, walk, wait in line, go through the scanner, inevitable pat downs, cinch back up the belt, etc. Not what I look forward to. On our long term feature list is adding commute time and time to get through the airport to the timeline view as an optional setting, as well as potentially factoring that into our pain algorithm. This is really handy when you're flying to/from a big city like London or NYC, where airport choice my matter at a particular day/time. A similar long term add is factoring in having to go through customs on a layover. This is another awful part of the flight experience we can track and influence decision making through.

Thanks for the feedback.

Re: codes: yup, that's a bug and will be fixed (or at least the obvious one will be...)

Re: performance - this is on our radar, and we'll keep chipping away at making things a little better as we go. We do have some limits based on system characteristics, but the primitives available to chrome extensions for system information are limited (praise WECG - there's a lot of bad that can be done with too much info).

Re: ballpark dates - This is on our radar, but is both a thorny interaction and below the priority of a few other things users commonly request. No firm commitments on dates as such... but yes, it's a useful tool when you know you want a "May" vacation, and you want a reasonably priced flight that is comfortable.

We don't handle the booking, we redirect you to the travel site that we found the best price on. Many online travel search agencies and metasearch sites can put together itineraries the airlines don't offer directly.

There are a few reasons:

1.) When a user reports an issue to us, it is much easier to find any issues in our error reporting stack. if we have their name and email address attached to the issue as opposed to asking them for all the search terms, time of issue, etc. and then hunting through to see if we've already found (and hopefully fixed) the issue. This practice started when we were a paid subscription, and I've found it useful to continue, especially with a very small team supporting a set of highly asynchronous interactions with scripts running across multiple websites and pushing data back to a common source.

2.) There are contractual requirements for some of the data that we've purchased to be protected from copies of those databases being made. Placing it behind an auth wall and leveraging account based rate limiting for API endpoints met our partners' needs.

I think I've gotten them all. Appreciate you bringing this to my attention!

Candidly, the Firefox extension framework is significantly nicer. Blam'ing chrome.runtime.lastError.

There's a lot of small amounts of work to get everything working right using the webext module. We're slowly chipping away, we've eliminated all our dependencies on chrome specific modules in the last month while working on other functionality, but we're a really small team right now with competing priorities, so this will get more priority as we get more people on the team.

The short answer is because certain airlines behave in ways I can best describe as 'scummy'. Some airlines are now demanding anti-consumer provisions when they do deals with travel sites, such as insisting that sites hide cheaper flights, hide multi-airline itineraries, and hide certain booking options. We think this compromises the user experience heavily and erodes trust - you don't know if you're getting the best possible flight. Being a browser extension gives us the ability to show the lowest fares without going through airline servers or airline contracts, since we can search and compile all the data from your browser.

A big part of why we're crowdfunding is to be able to grow the team and support more platforms (e.g. Desktop Firefox & Safari, mobile devices)

There shouldn't be any reference to a subscription. Can you let me know where you saw one? We used to have this setup as a paid extension, but pivoted away as that business model didn't work as well as we'd have liked.

Re: privacy and data. You can certainly review the settings we request and our terms of service - we ask to run the extension on a number of travel sites we interact with. We only collect your search intent data, progress around searching, and other similar lifecycle events as your search to aid us in product development. That being said, our long term monetization strategy is to sell search intent data - not your personal or financial data, and definitely not showing ads.

I tested locally with noscript installed. After giving the extension permissions to run scripts, everything worked for me. If you've blocked FlightPenguin, chrome extensions, or any of the sites we collect data from, you're going to have issues. Chrome extensions unsurprisingly rely heavily on JavaScript.

Adding alliances is on our near term roadmap. Should be live before the end of the month. Feel free to drop me an email (max AT flightpenguin DOT com) and I'll let you know when it's out.

Re: airports. You can select any airport or the city - which should grab them all (e.g. City of London (LON), London Heathrow (LHR), etc.).

Re: Noscript. I haven't tested with noscript, but have with most major adblockers. We do use the chrome extension API to open windows in the background to collect flight data and eventually to redirect you to for booking. I'll get it installed and see if I can replicate it. Might take a little bit, but I'll get there :)

Re: extension vs webpage. One of the biggest problems Hipmunk faced was that as the airline industry consolidated, they required OTA's and metasearch sites to sign highly restrictive agreements that prevented the site from showing all flights. We find this highly objectionable. By operating as an extension, we do not need to sign agreements to provide this data.

Flight Penguin's flight selection and timebars should feel very, very familiar. You can check out just how much we are inspired by the UX and values of Hipmunk here: https://www.youtube.com/watch?v=RzOAtn2sNCo

It doesn't, this is a side effect of requesting the chrome.tabs permission which we use to manage which tab is currently being highlighted. Chrome includes this note because the chrome.tabs permission set is very broad and includes an onUpdated hook that could allow the extension to capture history as you are browsing. Unfortunately, Chrome doesn't offer more narrow scoped permissions (e.g. tabs.query and not just generically tabs). This has been a known 'problem' for years unfortunately:

https://stackoverflow.com/questions/64063754/chrome-extensio...

And where did TPG enter into a commercial relationship or affirmatively agree to these terms?

Disclaimer: Founder of a company in the travel space that relies heavily on scraping.

What's interesting here is that there's conflicting precedent... and fundamentally that is what matters. hiQ vs LinkedIn is a great example of accessing data via a scraper that potentially violates the Terms of Services agreement, but found that Microsoft/LinkedIn violated antitrust laws. EF Cultural Travel vs Explorica is another example favoring scrapers. Against that, you have Facebook vs Power.com. Speaking personally, I'd like for clear and explicit rules about what is kosher to scrape and what isn't. Ticket bots are clearly problematic and deserve to burn in hell. Overly aggressive scrapers that incur load shouldn't get a free ride, but stuff like this that is initiated at the client's request and accessing solely the client's data.... I personally believe this should be fair use and would like to see that show up in the law somewhere.