Hey Kira!
I'm Matt, I run Product & Engineering at Ona.
First, thank you for trying the product and for taking the time to write this up. I shared the post with our product engineering team. There are several things in your experience that simply aren't good enough, and we're working on them. I've also credited $200 to your account in case you do want to explore further.
To be concrete:
> My very first encounter with the app was that I was unable to login on their desktop version at all. Auth is hard, so I can empathize and forgive this.
Whilst I appreciate the forgiveness, we hold ourselves to a higher bar than this.
We've done extensive testing of the desktop authentication flow and haven't yet been able to reproduce the failure you experienced. If you're willing, could you email me at matt at ona dot com? I'd like to grab some logs and work out what went wrong.
> it spent nearly my entire $20 worth of “ona compute units”, whatever those are, thrashing and trying to get a hold of the todos from linear just so it could pick one to start.
Looking through what happened, there were a few different things going on here.
- Roughly a quarter of the OCUs were spent by our devcontainer setup agent. That agent created a PR which standardises the development environment and adds install, build and CI tasks so that future agents can operate in a reproducible environment. There is real value in doing that setup once, but we did a poor job of making it obvious that it was happening, why it was happening, and what you were paying for. We'll fix this. We've also switched that setup agent from Sol to Luna as of today after tuning it against our evals. This should make that setup substantially cheaper going forward.
- The Linear flow also involved far too much friction. You went through multiple authentication and setup steps before the agent could actually get to the work you wanted it to do. That's not the experience we want. We have shipped a fix that lowers this friction already, and have a couple more planned (that will take a little longer).
- OCUs themselves are our attempt to combine model and compute consumption into a single unit. If someone has paid us money and still can't tell what they're spending it on, that's a problem. We're actively revisiting how we explain and expose this.
> This only adds more friction between me and my projects, which is literally the opposite of what I want when I pay for developer tooling.
I agree completely. Today, Ona asks a lot of a new user before it has earned the right to ask for that investment: connect this integration, authenticate that service, let us configure the environment, understand what an OCU is.
The thing we need to get better at is making the initial experience more boring: sign in, point Ona at something useful, and see it accomplish something valuable before you have to think about any of the machinery underneath.
> The thing is I think ONA is a good idea. I am evidently willing to pay for this kind of tooling. But I want a version that works without lighting twenty dollar bills on fire.
Based on your experience, I can see why you reached this conclusion.
If you're open to it, I'd love to spend an hour with you to help you get Ona working on something useful and show we can achieve what we outline in our marketing. No expectation that it changes your opinion but I'd like the opportunity to learn from what went wrong and show you what the product should have felt like the first time. Email is as above.
I look forward to hopefully connecting soon.
- Matt