HN Explorer

Show HN: Luther Enterprise: Dev platform for operating end-to-end mega workflows (enterprise.luthersystems.com)

8 points by iamsamwood ↗ HN
I’m one of the developers behind Luther. We make it easy to operate “mega-workflows” – the long, cross-team, multi-system processes (insurance claims, mortgages, etc.) that today are usually held together with bespoke glue code and mismatched workflow tools, which are always about to be upgraded “any day now”.

Our platform replaces that glue code with a Common Operating Script, that runs reliably and consistently across teams and systems. Systems are connected to the platform rather than each other, so it’s easy to add and remove systems as your tools change, and changes must be approved by all teams before they go live, so everyone’s operating the same process, all the time.

To show how this works in production, we open-sourced a full Claims Settlement case study (75k loc in production, 12 systems and 5 teams), and you can check it out here: Repo: https://github.com/luthersystems/cross-department-claims-set... Video walkthrough: https://vimeo.com/1141432607?fl=pl&fe=cmt

How it works

• Logic: Write process-operations logic in a transactional Common Operating Script. Nodes execute this logic to process events across the various teams, while maintaining consistency.

• Infra: We provide a drop-in Kubernetes cluster with Prometheus/Grafana pre-wired. Use our managed version, or deploy to your cloud via Terraform.

• DevEx: Our connector hub provides 100s of ready-to-go connectors (S3, Postgres, etc.) and a prebuilt GitHub Actions pipeline. We provide a production-ready repo for you. We’d love feedback from the HN crowd, especially on the pain points you’ve seen when stitching together complex workflows in enterprise environments.

4 comments

[ 5.5 ms ] story [ 16.9 ms ] thread
alanJames34
How do you handle debugging when a workflow spans that many systems? Most workflow platforms, especially low-code/no-code, become painful to debug at scale.
bit_tea
Kudos for the emphasis on solving the cross-team coordination problem for these "mega-workflows", as that's usually where the bespoke glue code starts to rot.

How is this fundamentally different from low-code automation tools like n8n or Make? Curious what you think these tools lack/fall short of

iamsamwood
Those tools are excellent for simple data movement, but drag-and-drop becomes unwieldy as logic density increases. This often leads to script bloat, where developers embed code inside nodes, creating the worst of both worlds. We keep process logic as code so you can use standard dev tools—like Git, Cursor, and CI/CD—while maintaining a high-quality integration DX.

We also use a highly performant Go and LevelDB runtime for solid performance at high scale, and our focus on enterprise means we include all the compliance features and industry-specific integrations that aren't native to other platform.

db422
"Mega-workflow" is a bit vague. Is that a certain size/complexity of process? Sounds interesting but it needs to be able to scale.