You know what good looks like. You can tell when a workflow is technically correct but still wrong: too vague, too slow, too brittle, too noisy, too hard to trust, or too poorly fit to the customer’s real problem
You care about the feeling of rightness. You notice naming, data models, logs, permissions, latency, API shape, loading behavior, failure modes, and the small frictions that make complex software feel either elegant or exhausting
You use AI without outsourcing judgment. You can delegate work to agents, but you still define the problem, set review criteria, constrain the implementation, verify the behavior, and decide whether the result is good enough to ship
You build with customers close by. You are comfortable using real customer workflows, support threads, calls, prototypes, and internal dogfooding to understand what the product needs to become
You keep the team small by raising the bar. We would rather have a few engineers with strong taste, high agency, and deep ownership than a larger team producing more undifferentiated software
You do not ship half-baked experiences to customers. Early prototypes are useful. Internal dogfooding is useful. Customer co-creation is useful. But the public product should feel cared for
You have built workflow systems, developer platforms, data platforms, infrastructure products, agent systems, internal tools, or complex enterprise SaaS used by technical customers
You have opinions about API shape, execution semantics, logs, permissions, lifecycle states, and observability because you have seen what happens when those things are treated as afterthoughts
You can show how AI has made you faster without making your work worse
You can point to places where you rejected, rewrote, constrained, or heavily edited generated code because your judgment was better than the tool’s first answer
You have pulled something back from release because it technically worked but did not yet meet the quality bar
You are comfortable with ambiguity, but you do not confuse ambiguity with vagueness. You ask the questions that make the work concrete
You care about regulated, high-trust AI because it is harder and more useful than another thin wrapper around a chat box
You Are Probably Not a Fit If
Being direct about this saves everyone time
You want a narrow backend-only, infrastructure-only, ML-only, or frontend-only role
You need detailed tickets before you can make progress
You are looking for a large team with mature process, fixed swimlanes, and lots of scaffolding
You are comfortable shipping AI-generated code you do not fully understand
You think “AI-native” means letting an agent produce thousands of lines of code and asking reviewers to find the problems later
You see design, product judgment, reliability, platform architecture, or customer context as someone else’s job
You ship something once and move on before it has proven itself in production
Small team, high ownership. We are early enough that a strong engineer can meaningfully change the shape of the platform
AI tooling is part of the job. We expect high leverage from modern engineering tools, and we expect the judgment to keep that leverage from turning into drift. Everyone here uses AI; the differentiator is whether it makes your work better
Customer reality matters. You will be close to real customer problems, especially in life sciences and other regulated environments
Cross-functional by default. Product, design, engineering, customer feedback, and delivery are tightly connected here. Engineers are expected to think, not just execute
Low bureaucracy. We value clear writing, direct conversation, working software, and people who make the system easier for others to reason about
A short note about why this role specifically. Not a generic cover letter
A description of where you are strongest across backend/platform work and where you still feel comfortable across the rest of the stack
Your GitHub, writing, technical design docs, shipped UI examples, or a representative sample of work you are proud of
One example of a platform, workflow, developer tool, data product, or user-facing system you shipped where the architecture, abstraction, or customer experience judgment mattered. Tell us what you would do differently now
One example of how you use AI in your engineering work. We are especially interested in where you overrode, constrained, rejected, or improved the AI’s output
We will read everything. We will respond to everyone, including no’s