Goose is too important to staff with the wrong people, and the right people are too important to mislead. Here's exactly where we are, what we're trying to build, and what working here actually looks like.
Most careers pages do one of two things badly. They overclaim, "we're a growing team of passionate operators", when the truth is a vision deck and good intent. Or they underclaim, vague, modest, generic, and let the right candidate scroll past without realizing what they're looking at.
This page does neither. If the rest of it makes you want to write to me, that's the right reaction. If it makes you close the tab, that's also the right reaction. Both save us time.
One founder, in Dubai. A working V1 app shipped. V2 architecture in flight, a feature store, typed events, a multi-layer intelligence system being built phase by phase, with rigour. A pre-seed round being raised right now.
No engineers yet. No designers yet. No team yet.
The first hire, likely you, if you're reading this, joins a company at the moment it stops being one person.
The runway is real but not infinite. The market is large enough to matter. The technical bar is high. The design bar is higher. The pace is fast but deliberate. If either the consequence or the risk bothers you, this isn't the role. If both excite you, keep reading.
Goose is a personal adaptive control system, a continuously running model of someone's life that detects drift, resolves cross-domain trade-offs, and steers them through complexity. Health and performance first, finance integrated from day one, the rest of life to follow.
The way to understand it: every wellness app, finance app, productivity app, and habit tracker is solving a fragment of a single underlying problem. The problem is that adult life is multi-domain and our tools are single-domain. The integration falls to the user, who is exhausted.
Goose is the layer above the apps, the intelligence that holds the model together. A system that knows someone well enough to actually help.
The technical work is genuine: typed event systems, feature stores with versioning and confidence semantics, cross-domain inference, episodic memory, a per-user model assembled at request time and consumed by every engine. The design work is rarer, calm UI for a product that lives in the hardest parts of someone's life, language that earns trust, motion that doesn't condescend.
This is a real engineering and design project. Not a wrapper on an LLM.
Not pixel-perfectionism for its own sake. Restraint. The understanding that most products fail by adding, not subtracting. You can point to work you've done and articulate the choices you made and why.
The Goose problem isn't "build this feature." It's "what should this part of the system look like, given it has to behave well across thousands of users for years, with continuously shifting data, in a domain where being subtly wrong is worse than being obviously wrong." That kind of thinking is the bar.
Not vague specs. Genuine ambiguity, questions nobody has answered yet, design problems with no precedent, technical decisions that only prove right or wrong in twelve months. If that scares you, the role isn't right. If it interests you, keep reading.
The people who do their best work on something like this are the ones who'd build it whether or not they got paid. We won't pay you what big tech pays. We can offer real equity, real ownership, and the chance to make a thing that matters.
Code, documentation, internal docs, design specs, user-facing copy. Most of the leverage at this stage comes from clear writing. If your Slack messages are precise and your PR descriptions read like essays, you're our shape.
Not "I built this prototype." Things in production. With users. That you maintained. The bar isn't volume, it's that something you built is being used right now by people who didn't write it.
Compensation is honest for the stage, a real salary, plus real equity. We'll talk specifics when we talk. If your bar is FAANG numbers and a name on your LinkedIn, this isn't the place.
The roadmap is being built collaboratively. If you want to execute a plan someone else made, this isn't the role. If you want to shape the plan, it is.
You're the team. The next hire is the team. The hire after that is the team. The mistakes will be ours and so will the wins.
No game room. No kombucha tap. No learning budget that's a marketing line item. The perk is the work. The perk is the equity. The perk is being part of building something that matters.
Everything you build will be visible. Everything you decide will compound. There's no middle management to dilute the consequences of your work, that's both the upside and the cost.
Not just equity, though that's real. Decision-making weight. The first ten engineering decisions in V2 will shape the next three years. If you're a person whose work gets better when you're trusted, this is your environment.
I'll tell you when something you've shipped is below the bar, and I expect the same from you. Not in performance-review formalities. In the moment, in plain language, with care.
The product, the architecture, the design language, the intelligence system, there's a real point of view here, and the intent is to keep thinking hard about it, together. Not "we'll figure it out as we go."
What you ship in your first month will still be load-bearing in year three. The architectural choices being made now are the ones the company will live with. That's a rare position to be in.
This is a control-system company. We use the product. The norms surface, the protocols, the recovery layer, they apply to us too. Burnout culture is incompatible with the company's premise. We work hard; we don't perform working hard.
We're hiring the first two technical roles. Each is broader than the title suggests because the team is small.
You'd own the V2 intelligence system implementation alongside me, the feature store, typed events, UserModel assembly, cross-domain inference, the policy layer. Strong systems thinking. Comfortable with TypeScript and Postgres. Experience with event-sourced or graph-shaped data is a plus. Senior enough to argue with me about architecture, and right often enough that I'd listen.
You'd own the React Native app, the surface where the entire system lives. Strong product instincts. Strong design taste. The ability to take a Figma file or HTML mockup and ship it at quality. The willingness to refactor when the third week shows the abstraction was wrong. We're building something whose interface is half the product; this role is where that interface becomes real.
Open to other roles? If you read this page and think "I should be at Goose but the role above isn't quite me," write anyway. The right person and the right role often arrive together.
Email careers@joingoose.app with the subject line "[Role] · [Your name]".
In the body:
I read every email myself. I reply within seven days, a no, a "let's talk," or a request for more.
If I say no, I'll tell you why. If I say let's talk, the first conversation is 45 minutes, on video, mostly me asking you to walk me through something you built and why. The second is a paid half-day work session on a real problem we're solving. We move fast from there, or we don't move at all.
We are building one of the most personal products software can build. That's not a marketing line, it's the design constraint.
If you've read this far, you've already self-selected past most candidates. The remaining filter is whether the work itself, described honestly, makes you want to write the email.
If it does, write it.
Think you'd fit? Write to me.
careers@joingoose.app