We’re building something ambitious at Fly.io: a new public cloud, running on our own hardware all over the world, built to make it easy to run apps close to users everywhere.
Don’t just skim this post. There are lots of different kinds of UX engineers, and we’re on the hunt for someone very specific.
For the past five years, we’ve been working on a public cloud platform that that has the ergonomics of “platform as a service” offerings like Heroku, but the power, flexibility, and economics of a hyperscaler cloud. Those goals are in tension, which makes working on UX here especially challenging.
This Role
A UX engineer at Fly.io is a primarily an Elixir developer. The work is primarily front-end and interaction design.
But Fly.io isn’t primarily written in Elixir, and every decision we make from button sizes to distributed consensus algorithms is driven by user needs. So you won’t just be thinking in Elixir: our CLI is a Go program, as is our API, and other components are in Rust and Ruby. You won’t own these components. But you’ll need to understand them, and to drive changes in them. It’s a daunting problem, so this is a senior role.
Fly.io has historically been a CLI-first company. The CLI isn’t going anywhere, but our emphasis is shifting. So, when we think about UX development, what’s in our head is: someone who makes sure our team is shipping, quickly, with a strong browser-based interface.
Finally, Fly.io is weird about product management, and that’s especially the case with UX. You will not have a PM to rely on for feature breakdowns or roadmaps. You’d need be prepared to come out of the gate with strong ideas about what’s going to make our users lives better, and what’s going to make them happy in the long run.
What We’re Doing Now
We’ve got two big product pushes happening in 2025.
The first is MPG, our upcoming Managed Postgres offering. Managed databases let users create databases and then not worry about them. Databases are complicated: lots of knobs, lots of flashing lights. We need the knobs simplified and the lights curated, so that MPG is telling the story users need to here, and not confusing them with other stuff.
The second use case is LLM execution environments. A crazy thing happens when you give a hallucination-prone LLM access to a secure, ephemeral environment with which to actually compile and run code: the LLM actually gets good at coding. We’ve got a handle on the core engine of generating code and getting it to run safely. But what is the UX of that as a product? What does it mean to start a new LLM-driven project, and what does it mean for it to be finished, put into production, maintained, and extended? We’re looking for somebody with takes.
Seriously, This Is A Fussy Role
We’re not afraid to talk you out of it. You’d need to be:
- Attuned to the needs of the kinds of users that ship things on public clouds. Check out our public community if you think that’s easy to do consistently.
- Relentlessly focused on shipping. We work with 2-week horizons here; 6 months from now might as well be the year 3000.
- Rock solid with Elixir/Phoenix. Unafraid of Go.
- Able to keep a model in your head of ambitious features that are implemented across many layers of software, many of which you don’t own; you have to be willing to get your brain dirty.
To us, all these things that make this job complicated also make it interesting. If we’ve held your attention this far, let’s see if we can make something work.
How We Hire
This is a senior, fully-remote, full-time position.
In order to optimize for pay equity, Fly.io doesn’t negotiate salaries. We have standardized salaries for each employee level. The salary for this role is $190 to $225k USD, depending on level. We offer competitive equity grants with a long exercise window. We provide health care benefits, flexible vacation time (with a minimum), hardware/phone allowances, the standard stuff.
Our hiring process may be a little different from what you’re used to. We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent. So instead of resumes and interviews, we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it, with “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet. (We’re happy to talk, though!)
There’s more about us than you probably want to know at our hiring documentation.
If you’re interested, mail jobs+ux@fly.io. You can tell us a bit about yourself, if you like. Please also include your location (country), and your Github username, for work sample access.