Work where the problem is.
We put people inside the customer's building — business consultants, product managers, designers and engineers — to work the problem out with them, build it, and stay for whether anyone uses it.
If your career so far has been sending specs into a queue and reading about the outcome two quarters later, this is the opposite of that.
What a phase looks like from your seat
Work here is organised in phases, measured in weeks. This is the shape of one.
You land
You start in their building, not ours — on their floor, in their operating rhythm. Most of the early work is finding out what the business actually measures, which usually means discovering that three teams define the same number three different ways.
You work out what to build
No spec arrives. You sit with the people who have the problem and decide the thing together — then argue for the version that will get used over the version that is more interesting to build. That argument is most of the job.
You build it on the base
Identity, permissions, hierarchy and the metric layer already exist on the platform, so you are writing the part that is specific to this company, with AI doing most of the volume. Reviewed, not vibed — you own what you ship.
You are in the room when it goes live
You sit in the review where your work is either used or ignored, in front of the people who run the company. Adoption is the deliverable, not the merge.
Because a phase is weeks and not quarters, you find out whether you were right while you still remember what you decided.
Four disciplines, and they go in this order
A full bench goes in, not just coders — consultants first, engineers last, because a problem has to be understood before it is worth building.
Business consultants
You work out what the business is trying to measure and decide — and which of its long-running arguments are definition problems wearing a data costume.
Product managers
You turn that into something a company will actually open on a Monday morning: scope, sequence, and the judgement about what not to build.
Designers
You make dense operating numbers legible to a branch manager and a board member on the same afternoon. Interfaces people read under pressure, not in a portfolio.
Engineers
You build on the base with AI leverage, against real schemas and real mess. The interesting part is not the model, it is making something hold up in production.
We don't post individual roles, so there is no title to match yourself against. Tell us which of the four is yours.
Reasons not to take this job
Better you find these out now than in month two.
You will travel
Forward deployed means being where the customer is. How much depends on the engagement, and we will tell you plainly before you join rather than after.
There is nowhere to hide
Adoption is the deliverable, so if the thing you built goes unused that is visible — to the customer, to us, and to you. Some people find that clarifying and some find it exhausting.
It is not a research job
The elegant technical problem loses to the thing the business needs working on Monday. If that trade-off irritates you, it will irritate you most weeks.
You will not be the expert in the room
The branch manager knows things about that business you never will. The work starts by taking that seriously, and it does not suit everyone.
If you have read this far and still want it, you are probably the person we are looking for.
One note, no portal
Send an email. Say which of the four disciplines is yours, name one thing you finished, and say what it changed — not what it was built with. If there is something you are still quietly proud of, link it.
A CV is welcome but not the point, and there is nothing to fill in. We read every note that is clearly written by the person sending it.
Tell us what you finished
One note is enough. Which discipline is yours, what you built, and what changed because of it.