9 ms·
Launch HN: Onu (YC W23) – Turn scripts into internal tools in minutes
Hey HN! Chine and Lindsey here from Onu (https://joinonu.com https://joinonu.com). Onu lets you write scripts and turn them into internal tools suitable for use by non-technical teammates. We built Onu to help you spend more time coding and less time running scripts for ops or customer support. Unlike no-code/low-code products, we’re code-first and let you use your preferred tools. We take care of the annoying parts for you: most importantly the frontend, but also auditing, permissions, and 3rd party integrations (e.g. Slack, email, Jira, Pagerduty).
We’ve put up a few sample screenshots at https://joinonu.com/examples https://joinonu.com/examples, and a demo video here: https://www.youtube.com/watch?v=4XMnBRsktsw https://www.youtube.com/watch?v=4XMnBRsktsw.
Many engineers lose hours a week fielding requests from other teams. While most companies have a home-grown internal dashboard (or are using a third party tool builder for this such as Retool), there is still a long tail of scripts that engineers have to run regularly for their ops and CX teammates, either locally or by SSHing into prod. Maybe a user’s account got stuck in a weird state, or you have a script to manually onboard new customers to your B2B product, or you have to run a custom provisioning script each time you add a bike to your e-bike fleet (something we experienced at Lyft).
We experienced these problems while working on engineering teams at Lyft and Stripe. Our teams needed internal tooling, but we didn’t have time to build feature-rich dashboards. Stripe had a homegrown tool that allowed engineers to quickly spin up simple internal tools without writing any frontend code. When we started working on Onu with a different idea we immediately felt the pain of not having a similar tool. We pivoted to working on our current product instead because we already knew how powerful it can be for speeding up engineering teams.
Internal tool builders mostly take a no code/low code approach that requires engineers to duplicate a lot of business logic in the browser. This leads to brittle internal apps that are hard to keep in sync with the business logic in your codebase, and difficult to maintain as you scale. In addition, such tools subject you to point-and-click / drag-and-drop workflows that just aren’t the sweet spot for programmers. We don’t like working that way ourselves, so we focus on a code-first approach, allowing you to hand scripts to non-technical teammates to own and run without engineering oversight.
Onu works with your existing dev workflow. You write scripts in your editor of choice—not the browser—and deploy tasks the same way you deploy any other code. We can host your scripts if you prefer, but you can also add Onu to your existing Express server and our frontend will handle routing requests to the correct script. We currently have a Node SDK and are rolling out Python next.
You can try Onu now by heading to https://auth.joinonu.com/signup https://auth.joinonu.com/signup and signing up for an account. It’s free for personal use cases and for teams of up to 5 people.
We’re looking forward to your thoughts and feedback!
- TBloom 3y agoThoughts on how you compare to airplane.dev?
- lredd 3y agoHi! Thanks for asking -- the main difference is that devs build tools on Onu completely in backend code. Airplane requires some react code to build more robust frontends.
- rubenfiszel 3y agofounder of windmill.dev here, a fully open-source alternative to airplane.dev Congrats on the launch. I am not sure that is accurate. Both airplane and windmill supports defining your task as plain backend code and deploying them from CI/CD using our respective CLIs. The react part that we both support is if you want to build more advanced views that goes past the need of a single form. One difference between airplane and windmill is that airplane require a yaml configuration to define the inputs while windmill automatically infer them from the main function signature. What mechanism do you use yourself?
- lredd 3y agoHi! Yes, thanks for the clarification! And by "robust frontends" I meant "advanced views," so you're totally right! The goal with Onu is for you to be able to build those advanced views completely in backend code instead of using React. We made this choice so that pure backend engineers wouldn't have to learn React to build internal tools. In fact, I didn't know any react while being an infra eng at lyft! We've heard this from a lot of other backend engineers as well -- they don't want to deal with react components. To define inputs in Onu, devs use our SDK! This is actually what Airplane does as well (I think they deprecated their yaml config).
- rubenfiszel 3y agoAgreed, backend engineers do not like writing frontend code. From there, for advanced views, I believe interval.com chose the route of having the frontend being defined in the task itself with an SDK (which I think is what you seem to hint towards?), and for windmill we have a drag-n-drop/retool-like UI builder if react is too much.