> I get the impression they would be perfectly happy shipping nothing for long periods.
I wouldn't say _happy_, but we were certainly _willing_ to do this for long periods of time to get the right foundation built (for reference, we built for 5 years before launching). This is made explicit in the opening:
> As a result of following the framework, product development may sometimes come to a screeching halt. The work itself may be tedious and frustrating. Progress may take many multiples of the time it would take using other methods.
> [...]
> That's the difference between principles and preferences: principles are what you do regardless of the cost – everything else is just a preference.
As for this item:
> But the “what” and the “why” seem to be mostly implied.
> We are hiring across multiple engineering, product, and design roles right now, so we wanted to post this publicly to give a sense of what it’s like to work here. If this resonates with you, we would love to hear from you.
Hi all: I'm the founder/CEO of Stedi. Came here to say that we're preparing to publicly launch drop-in replacements for Change's Claims and Eligibility APIs[1]. Our new API will allow customers who have been using Change to directly switch with minimal development effort. The API: i) accepts Change JSON request format, ii) translates it to X12 270/837, iii) submits it to a clearinghouse (we have a master connection with Availity, or can use yours), and iv) returns the response as Change JSON. We are working around the clock over the weekend to onboard the first external customers.
Our goal is to help providers submit claims and eligibility checks as quickly as possible. We’ve created a streamlined contracting process along with a standardized price list and the ability to match volume pricing. We can get folks set up with a dedicated Slack channel immediately and start working with engineering/ops teams to get back online.
Google started with nerds; nerd learned to write good queries. Then normies appropriated Google and wrote dumb queries in massive volume; Google optimized for handling dumb queries. To get good results today, you have to write dumb queries. For example, a nerd would never write a question as a search input – nerds would write a series of hyperrelevant keywords. Normies don’t understand keywords – they ask questions of Google, like it’s a person. So, only way to get good results for most queries is to reform them as questions.
Yep, there's no way around mapping – the data has to get mapped somehow. The 835/837 are a bear. You can save some time if someone has built a mapping template already – say, from a transaction type in Oracle to the 837 – but if it's a custom system you're mapping to/from (like a homegrown API), it's impossible for a template to exist...it has to be done from scratch.
We've found that many of the fields end up being single-item enums, so those can be hardcoded (i.e. no mapping required). Guides (https://www.stedi.com/products/guides) generates JSON Schema for you, and Mappings (https://www.stedi.com/products/mappings) automatically populates any single-item enum. Both are free to configure in the UI.
It's definitely possible to write simple EDI transactions (no HL loops, etc) with a couple of trading partners using something akin to mustache templates – many of our customers come to us after getting something basic like this up and running in a day or two, and then hitting complexity.
We have lots of customers in regulated spaces – healthcare is a big one – but it's definitely a dealbreaker for certain companies that have hard rules for running everything in their own environments.
What sort of scale? Would love to see the math. (Context: I'm the CEO – if our pricing doesn't make sense for certain use cases, I'd love to dig into it)
I wouldn't say _happy_, but we were certainly _willing_ to do this for long periods of time to get the right foundation built (for reference, we built for 5 years before launching). This is made explicit in the opening:
> As a result of following the framework, product development may sometimes come to a screeching halt. The work itself may be tedious and frustrating. Progress may take many multiples of the time it would take using other methods. > [...] > That's the difference between principles and preferences: principles are what you do regardless of the cost – everything else is just a preference.
As for this item:
> But the “what” and the “why” seem to be mostly implied.
This is outlined in another linked post: https://www.stedi.com/blog/excerpts-from-the-annual-letter