The @TryRamp top vendors list is our favorite list to be on because it's one of the few 'real' benchmarks out there. This is our second time on it. A year ago, it was @Stedi alongside a bunch of other SaaS and a few AI companies. Now, we're the first non-AI company to be on the list in 5 months. There is still an enormous market for API-first, network-based SaaS – agents need efficient and reliable ways of connecting to the otherwise-illegible real world (in our case, we handle connectivity to 3,500 different healthcare insurance companies for claims processing) – but building a defensible business in these categories is a huge investment of time and capital. Nine years in, we're growing faster than ever. We're hiring across many roles – engineering, design, product, GTM, legal, ops, recruiting, and more. If you're looking to be a part of something special for the long term, drop me a note.

Had a great time at @AWSEvents re:Invent talking about the @Stedi agent. We built and launched the first version in <2 weeks using Bedrock AgentCore – from talking to other founders, it seems that AgentCore is one of the best kept secrets in software (hopefully not for long).

You can read the full announcement on our blog, but I thought I'd editorialize a bit more here and tell more of the backstory of what happened over the past 18 months. In late Feb 2024, I brought our engineering team into a war room. Change Healthcare – the nation's largest clearinghouse for processing healthcare claims between providers and insurance companies – had been down for almost a week due to a cyberattack that would ultimately take them out for 2 months. It’s hard to explain the magnitude of the outage to people outside the healthcare industry. Nearly 40% of healthcare claims processed in the United States flowed through Change’s platform. They processed an aggregate $1.5 trillion of claims volume annually – 15 billion claims in total. Healthcare spend in the US is $4.9 trillion annually – 18% of total GDP – which means that when Change went down, it was processing roughly *5.5% of US GDP*. We worked around the clock to launch our drop-in replacement for their clearinghouse, which we did 5 days later. We were in the right place at the right time, but so were a lot of other people – this didn't exactly happen in private. We were able to do this because we had spent the previous 6 years building the underpinnings of a platform that could power a clearinghouse. It's funny because by February 2024, we had what we thought was product market fit – our EDI processing platform was used across retail, logistics, healthcare, and more. We had plenty of customers, but even with all of the work that we had put in to make our EDI processing platform easy to use, it still took weeks or months for companies to get up and running, because each connection had to be set up one-by-one. Customers were willing to put in the work, but it was still a far cry from what I had set out to do from the earliest days. I always loved Uber's original mission statement: 'To provide transportation as reliable as running water, everywhere, for everyone' (its current mission statement – 'To reimagine the way the world moves for the better'– is watered down corporate nonsense). My goal was similar: to make business-to-business transactions as reliable as running water. In our January board meeting, I said that our plan for the back half of 2024 was to finally move another level 'up the stack' and to offer turnkey transaction functionality in healthcare – the only place where it's currently possible to do so, thanks to regulatory-enforced transaction schemas and robust network of interconnectivity – by building a clearinghouse. It became clear a few days into the outage that Change wasn't coming back online anytime soon, or perhaps ever. We accelerated our plans and launched over the weekend. It was pandemonium. For the seven weeks after launch, I couldn't leave my keyboard for more than five minutes at a time – most days from 4:30 or 5am until midnight. Six/seven figure deals went from initial phone call or text message to signed terms in under an hour. A couple of weeks in, I went for a quick walk to get outside, and took three phone calls from CEOs and CTOs who were desperate to get back online. We sent people to their offices and had them integrated and processing claims within hours. It's strange to tell this story now because our world was almost entirely about the Change Healthcare outage for a couple of months last year, and we've hardly thought about it since. They eventually came back online and the dust settled. None of our customers who signed and went live switched back. But at the same time, Change stopped hemorrhaging customers – the companies who were going to jump ship, jumped ship. Yet our growth has only accelerated. Last month, we signed 5x the number of customers that we signed at the height of the Change outage. Stedi has become the de facto choice for virtually every new venture-backed health tech company – and as later-stage health tech companies and traditional institutions revisit their legacy clearinghouse dependencies in the wake of the Change outage, Stedi’s cloud-native, API-first platform has become the obvious choice. But more and more, our growth is driven by GenAI use cases from all segments of the market – from brand new startups to traditional companies coming to Stedi to build agentic functionality into their existing platform. One-third of our customer base is now made up of fully-native GenAI companies. Development teams hit frustrating roadblocks with legacy clearinghouses. The legacy clearinghouses were built pre-cloud computing (and in many cases, pre-internet), and most are the result of a series of private equity acquisitions with tech stacks that were never harmonized or modernized. They offer only the bare minimum of hopelessly outdated APIs – most of the functionality offered by legacy clearinghouses is not accessible programmatically. Stedi’s approach is API-first: every piece of functionality available through our user interface is available via API. Our thesis is simple: as more and more aspects of software are subsumed by agentic workflows, companies will shift ever-greater portions of their workloads to the platforms that offer the best accessibility and legibility to AI agents that are performing actions; since other clearinghouses don’t offer ways to perform tasks programmatically, customers will continue to migrate to Stedi as they build net-new workflows, or as they find that existing workflows come to exceed the requirements afforded by other clearinghouses. We have a single question that we use to guide our roadmap decisions: does this make it easier for humans and agents to interact with our platform? This has dozens of small improvements alongside bigger launches – notably our MCP server last week and our own native agent yesterday. Venture capital is a wonderful thing – it would not have been possible to spend 6 years building a platform without it. This latest funding allows us to accelerate hiring of world-class talent across engineering, product, design, business operations, and more. If that sounds exciting to you, send me a note.

I told investors from the first day in 2017 that it was going to take a very long time, but once it started working, we would be impossible to catch. 4.5 years to launch our first APIs, 2.5 for the full platform, and 1 to now be one of the fastest-growing software vendors.

I've been playing with a new tool that pairs LLMs with data sources in an Agentic data access pattern called PromptQL from @HasuraHQ. It's a very interesting way to explore and utilize your data, and not just by your data science folks! dev.to/shortjared/from-lego-…

I've always been a huge fan of @ShortJared's opinion on developer tooling so I took @HasuraHQ's PromptQL playground for a test drive last night. rboyd.dev/posts/hasura

The best part about rust is I can use this classic again. xkcd.com/303/

Huh. who knew I'd been doing it the faster way most my life. I just thought I was being lazy... turns out it's actually faster!

Anyone know how much of our computing power and energy goes into updating / training weather models? Seems like surprise rapid intensification to cat 5 indicates we have big gaps in the models. (I know nothing about this space, curious for resources to learn more)

I mean... really?

okay this is very cool

Please share this far and wide. As far and wide as you can. NIST Password Guidelines for 2024 are in the process of being updated. This is a HUGE pet-peeve of mine (when vendors in particular are still operating like its 2017 and keep changing passwords every 60 days, STOP DOING THIS, it's outdated and has been shown to put you MORE at risk than less -- NIST explains why it does in this document, meticulously outlining user behavior**) so I'm sharing this in the hopes all of you will pass it along to your bosses. The Special Publication series governing passwords is SP 800-63 "Digital Identity Guidelines". The 2024 version is 800-63-4. Here: pages.nist.gov/800-63-4/ The companion docs are also on that link. They are 800-63A, 800-63B and 800-63C. These are different documents for different scenarios in play at your org. The previous update was in2020. The changes in the 2020 version from the 2017 version were numerous but one of them was that the password verification method should NO LONGER require passwords be changed at specific intervals (i.e. every 60 days) but in the following circumstances instead: 1. After a breach/compromise 2. User request 2024 repeats this and adds a bunch more guidlines but here is a screenshot of page 13 of the new 800-63-4 (note the # 4 after it) which outlines how your systems should now and moving forward, be handling passwords. This goes for Active Directory, too. All your systems which have passwords should align with these guidelines provided there isn't another standard or framework you must adhere to which overrules this. Most frameworks, however, have moved away from arbitrary password resets and complexity rules. **We cybersec researchers and hackers use wordlists from breaches in a variety of different ways. Hackers use them in tooling to crack passwords whereas researchers use breach dumps to see the kinds of passwords users are creating and the psychology behind them. Using complexity rules gets you the user psychology of: Password1 Password2 and so on Use phrasing instead and allow for spaces, which is important. Humans type phrases with spaces. They also mention phish-resistant methods and most vendors are on-board with MS going to be turning off all Legacy Auth next month, across all free accounts and tenancies. I'm so excited for the new changes! Ok I'm off my soapbox. Share the love! Thank you!

today in awful ideas I've had: `transaction.execute_unprepared("LOCK DATABASE")` I honestly see nothing that could possibly go wrong.

One of our friends embroidered our dog Landra and I’m speechless. This is absolute mastery and art. reddit.com/r/Embroidery/comm…

Hey, @ajassy: this song was supposed to be satire, not an instruction manual.

Built my own stupid markdown CMS because I wanted a couple simple features. Turns out if you throw away all the crap it can be fast. Stuff I wanted: automatic reloading in dev, easy flexible directory based rendering, dark mode, not much else. < 300 LOC and minimal deps.

I think the best part of the whole AI coder thing for me is I can spend a lot less time on the drudgery of a throw away / learning project and get the parts out of them I care about.