Careers
There are no open roles today.
A role is listed on this page on the day it opens, with its own terms; nothing is listed, so there is nothing here to apply to yet.
Open roles
Nothing is open, and this page is where it would appear
This page is the only place a role is announced. When one opens it is listed here with what the role owns and how to apply to it; until then there is nothing on this page to apply to, and no standing wishlist behind it.
General applications are still welcome. Send one email to careers@sylphx.com saying that is what it is, with what you have built and the kind of work you want to own next. There is no form, no application portal and no tracking dashboard, and no reply window is promised here because none is published.
Questions about the work go to the same inbox. Every other mailbox this site publishes is on /contact, if your question is not about working here.
What to show
A strong application looks like a good change
Changes here are read against a contract. Applications are read the same way, and these are the six things worth writing down.
- The job you want to do. The customer or operator job your work completes, in plain language — not a list of technologies you have used.
- The boundaries you understand. Which part of the platform your work touches: the Rust services that own backend effects, durable state and queues, or the TypeScript and Next.js surfaces that own the browser, SSR and the UI. Saying where a change does not belong is as useful as saying where it does.
- The consequences you considered. Failure, security, privacy, capacity, cost and recovery: what breaks, who notices, how the system recovers, and what it costs while it does.
- What you would delete. The predecessor that goes away in the same change. A change that leaves an alias, a dual writer or a read fallback behind is not finished, and the person who maintains it forever is the point.
- Evidence we can open. A repository, a pull request, a documentation change or a written explanation — something we can read for ourselves. The open source page shows the kind of artifact we publish ourselves.
- The honest unknowns. What you have not solved yet, and what you would need to find out. Every page on this site is written that way; an application reads better the same way.
Honestly
What this page will not do
No invented terms, no invented programmes
That is deliberate rather than incomplete. A careers page that describes a company we have not published is a page of guesses, and the honest version of it is short.
Next
Read the product before you write
The fastest way to write a good application is to know what the platform actually claims.
- About Sylphx — what the platform is, what it is not, and how the company is registered.
- The docs — the product, organized by task, with the commands you would ship with.
- Open source — which surfaces are public, and which part of the platform stays closed.
- The changelog — what shipped, in order, and what changed about it.
- Status — live health for every platform service, with the endpoints behind it.