For engineers who can understand the problem and build the solution.
Full-time and contract roles are available. An FDE works inside the
customer's systems: their codebase, data, and production
environment. You use agents for routine work, make the technical
decisions, and stay involved through launch. The role, reading list,
and interview process are on this page.
You talk to the client's people first, then write the code.
02
You work in the customer's stack, whether that means frontend, data, or agents.
03
You direct agents for routine implementation and make the decisions that need experience.
04
Every engagement has a delivery date and one agreed business metric.
05
We hire readers.
The FDE playbook
01 / 06
Six pages, one role.
What the role involves, how we work, and what we expect.
01 · The role
One engineer, end to end.
Most engineering jobs work like this: you build one capability, polish it, and ship it to many customers you will never meet. The FDE role runs the other way. You embed with a single customer, bring many capabilities to their one problem, and stay until it is solved. You talk to the people who live with the problem, find what is actually broken, which is rarely what the brief said, and ship production software against it.
The output is never advice and never a prototype. It is a working system, in their environment, moving a number they care about. And what you learn there feeds back into the platform, so the next engagement starts further ahead than the last one did.
⌐ From the culture doc: agents handle implementation; engineers make the calls.
02 · Not consulting
You stay until it runs.
The comparison comes up in every intro conversation, so let's settle it. A consultant's deliverable is a recommendation: a deck, a roadmap, a handover. They leave before the consequences arrive. An FDE's deliverable is running software, and you stay for the consequences: the deploy, the pager, the number that moved or didn't.
The lineage is older than the name. In the 90s, the best engineers in the world were consultants working Monday to Friday on client floors. The first wiki, TDD, and the agile movement all came out of that work. Then consulting became body shops, and no self-respecting engineer wanted the title. Palantir gave the same job a tactical name and made it cool again. That's the job. The name just recovered.
⌐ From the field: BoardRoom's link to the Australian Securities Exchange, rewired in under seven weeks.
03 · The actual work
Start with the people who use it.
A working day starts with people more often than code. You sit with the team that owns the problem and pull the real constraint out of their heads: the thing they mention in passing, not the thing in the ticket. Then you build: workflows, data pipelines, platform extensions, and fixes for whatever production surfaced overnight. The stack is whatever the customer runs.
None of it is throwaway work. Field code gets reviews, tests, monitoring, and a deploy path, because it lives in someone else's production long after you have moved on. You watch the live system constantly. That is where the truth is, and it is usually different from the meeting.
⌐ From the field: a 25-year-old financial core, mapped with 80% less of the client's time.
04 · At realfast
A small senior team, supported by agents.
Here is the realfast version. We send two to five senior people where other firms send forty, because agents handle the routine width of the work while engineers make the calls. We embed with software-driven enterprises on problems that are urgent, high-stakes, and stuck: the ones that have already survived a committee or two. Applied AI sits in the operating model itself, not bolted on afterward: strategy and engineering are one team, often one person.
Two things are non-negotiable on every engagement. What we ship belongs to the customer: their product, their platform, their repo. And every engagement is tied to one business metric, agreed before code is written. If the number doesn't move, nothing else we did matters.
⌐ Sidu, on every customer call: if we don't move the number, you're not happy with us, don't pay us.
05 · How we run
A practical delivery cycle.
Every engagement runs the same shape. Understand the business before the model. If the customer can't name the number they want moved, finding it is the first deliverable. Analyze the real data in full before writing a single rule, because the data always disagrees with the documentation. Then ship a working slice fast and iterate with the customer in the loop, weekly, so trust is built on things they can use rather than progress reports.
Before anything goes live, test at scale against their own historical data. Confidence has to come from evidence, not vibes. And when it ships, every reusable pattern goes back into the platform. That compounding is the whole model: each engagement starts further ahead than the last one did.
⌐ From the field: a university's month-end close went from three days to under ten minutes.
06 · The traits
Breadth and sound judgment.
The FDEs who thrive here share a shape. They are at home in unfamiliar codebases, the five-million-line kind nobody fully understands anymore. They are self-directed, because nobody writes your spec here; you write the customer's. They carry a customer empathy that survives contact with production, and a breadth that beats purity: frontend, pipelines, agents, whatever the problem actually needs.
Above all of it sits one discipline. Always be working on the single most valuable thing. Everything that doesn't need judgment is already being automated. What's left is the job.
We measure the result in the customer's business.
Continue to read the role and how we work.
How an FDE runs a fleet
One engineer.Several agents.A review before release.
You sit with the client's people and write the brief. An agent can act on it: the codebase, the constraint, the date.
Agents take the routine width: map the flows, draft the tests, read the branch logic, hundreds of files in parallel.
Everything lands back on you. You review with the client's experts, and they become reviewers, not narrators.
The new path must match the old one on the client's own historical data before anything switches.
Switch over, watch it hold, write down what hurt. Then the next constraint. The loop is the workstyle.
fleet / run
The reading list
The realfast reading list.
We hire readers. Nobody quizzes you on these. Read a few anyway.
They shaped how this place works, and the application asks what
reading changed for you.
▼ browse the stack · tap a book to open it
Open the full catalogue (45)
Everyone · 25
Eric S. Raymond · essay
Eric S. Raymond, to Linus Torvalds, 2000 · email
Poul-Henning Kamp, FreeBSD list, 1999 · email
Fred Brooks · paper
Eric S. Raymond · essay
Ray Dalio
Marty Cagan
Patty McCord
Daniel Kahneman
Peter Thiel & Blake Masters
Ben Horowitz
Andy Grove
Andy Grove
John Doerr
Steve Krug
Strunk & White
Fred Brooks
Steve Blank
Eric Ries
Eliyahu Goldratt
David Kushner
Paul Graham
Mary & Tom Poppendieck
Donald G. Reinertsen
Kent Beck
Developers · 15
Abelson & Sussman
Robert C. Martin
Michael T. Nygard
Eric Evans
Dave Thomas & Andy Hunt
Martin Fowler
Kent Beck
Steve McConnell
Michael Lopp
Ben Moseley & Peter Marks · paper
David L. Parnas · paper
Seth Gilbert & Nancy Lynch · paper
Roy Fielding · thesis
Dorian Taylor · essay
Alberto Savoia · humour
Designers · 2
Susan Weinschenk
Alan Cooper, Robert Reimann, David Cronin & Christopher Noessel
Extended canon · 3
Elizabeth Pisani
Robert M. Pirsig
Nassim Nicholas Taleb
Field notes from client work
Real situations from client work, with our response to each one.
01 / 07
Day two on a client's floor. Their staging environment has no usable data. The demo is Thursday. Their platform team's queue is six weeks deep.
What we'd do
Thursday doesn't move because their backlog is long. You write the seed generator, which takes an evening, and you tell them you did. The date was the commitment; the missing data was an obstacle, not a change of scope.
How you apply
There is no form. Your coding agent submits the application.
Point your coding agent at
join.realfast.ai
It sets up your profile and submits the application. We review your agent
configuration and one session log to see how you work, not how you describe
your work.
join.realfast.aifdeThe application process.
README.MD
Your agent submits the application. You handle these two steps:
01 · The next step
Mandatory after setting up agent
Express interest. We'll email your assignment shortly after.
A one-minute form: name, email, phone, the role, your notice period, and expected comp so we can align on budget early.
One quick conversation before your assignment lands.
Three questions with our AI screening assistant, under five minutes. The transcript and recording go straight to the hiring team. Your assignment is sent once both steps are done.
# 3 questions, under 5 minutes total.
# Have three books ready that changed how you work. The agent will ask what you read and why.
# Speak naturally; no right or wrong answers.
# Quiet environment and a working microphone.
# Recorded; reviewed async by the hiring team.
First name, and the email you used in the form:
Both fields, please. The transcript needs them.
⎇ MAIN● UPDATED TODAY6 STEPS · 8 STAGES · BAR RAISER AT 08