zkanter

> 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.

This is outlined in another linked post: https://www.stedi.com/blog/excerpts-from-the-annual-letter

I'll take the other side of that bet.

Nod to a famous set of articles by W. J. King called 'The Unwritten Laws of Engineering.'

It says it at the top of the post:

> 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.

We are launching drop-in replacements for their APIs: https://www.stedi.com/blog/replacements-for-change-healthcar...

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.

Here are the beginnings of the docs:

https://www.stedi.com/docs/api-reference/post-healthcare-cla... https://www.stedi.com/docs/api-reference/post-healthcare-eli...

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.

If there's anything we can do to help, email us at [email protected] or contact me directly ([email protected]).

[1]: https://x.com/zackkanter/status/1764057780800094350?s=20

Full paper: https://www.stedi.com/documents/papers/how-stedi-uses-automa...

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.

It's difficult to use the method you're describing to write a transaction like this, particularly when the receiver's system can fall over due to a single character out of place: https://www.verizon.com/business/support/vec/onlinehelp/dam/...

(I'm the CEO of Stedi)

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.

Good overview. I wrote about this in a bit more detail on our blog recently: https://www.stedi.com/blog/what-makes-edi-so-hard

Stedi | Serverless Engineer | Full time | Remote / fully-distributed

Stedi is working in one of the biggest markets on the planet – EDI, the technological backbone of the physical product economy. We’re building a next-generation platform: a ubiquitous commercial trading network to automate the trillions of dollars in B2B transactions exchanged by nearly every company on Earth. We are a 25-person, fully-distributed team with $21 million in funding (First Round, USV, Bloomberg Beta, others), located across six states and four countries.

We are 100% built on AWS serverless technologies - Dynamo, API Gateway, Lambda, SQS, SNS, etc, all provisioned with CDK, with TypeScript through the full stack.

Full list of positions here: https://www.stedi.com/careers

Library being discussed: https://github.com/StediInc/cdk-clj

Stedi | http://www.stedi.com | Boulder, CO | Onsite | Senior backend engineer

We're a three-person startup and we've raised $3.7 million in seed funding from First Round Capital, Bloomberg BETA, and other top investors - we're building a modern EDI platform to automate billions of dollars in transactions between retailers like Amazon and Wal-Mart and suppliers like Fitbit and Eero.

If you aren't familiar with EDI, it's a standard data format for exchanging transactions such as purchase orders, invoices, and ship notifications - for example, Fitbit uses EDI to receive orders and send invoices to Amazon. It’s the only way for companies (big and small) to integrate with 90% of Fortune 1000 companies and their tens of thousands of suppliers. But EDI software hasn't changed in a decade. We're eliminating the enormous complexity and cost of implementing and managing EDI by building a simple, intuitive interface - basically, 'Stripe for EDI.'

We’re looking for a senior backend engineer with a ton of experience on any JVM language. We’re building on AWS’s serverless stack (Lambda, API Gateway, SNS, SQS, RDS, etc). More info here: http://careers.stedi.com/p/08cffb8e3da8-senior-backend-engin...

Send us an email at [email protected].

Many thoughts on this. But they all come down to: it sounds like you think Amazon's current moat is trivial for Wal-Mart to overcome. Should be a few more months now and then Wal-Mart will start to take the ecommerce lead, then ;)

> You claim Amazon has 42 million Prime-eligible SKU's, and them compare that to how many SKU's exist in an average Walmart warehouse... forgetting that Prime-eligible SKU's don't all reside in Amazon warehouses... a 3rd party seller can warehouse that inventory on their own.

I'm not trying to be rude, but I think you have a misunderstanding of how third-party Prime eligibility works.

Virtually all Prime-eligible SKUs reside in Amazon's warehouse. That's how the FBA program works. There is a very new initiative called Seller-Fulfilled Prime (where the inventory resides in the seller's warehouse), but this is an extremely small percentage of the 42m SKUs.

There are ~2 million FBA sellers and roughly 42 million Prime-eligible SKUs - hundreds of thousands of inbound shipments. You can't just buy a couple of fulfillment centers (with their homegrown WMS software) and be off to the races.

For comparison, your average Wal-Mart distribution center has ~100k SKUs and one 'user' (Wal-Mart).

(Gross) margins were never razor thin - this is a myth.