Land and expand: how FDEs find the second contract inside the project they just shipped

Week six at the customer. The workflow you built is running smoothly, the final demo drew praise and the account manager has messaged the whole team to say thanks. Then you roll off, and three months later the contract renews at exactly the same scope. Sometimes it doesn’t renew at all.

At some companies that hire FDEs, that outcome means the job is only half done. Firecrawl’s FDE job posting states plainly that the role is measured by adoption and expansion, not by tickets closed.

The same posting asks FDEs to work with the revenue team to turn technical results into adoption and expanded contracts. At companies like that, shipping the first project is not the finish line.

If you are aiming for an FDE role, the ability to spot the second contract inside the first project is what sets you apart from a good outsourcing engineer. It can be learned, and it starts with reading data, not with being a smooth talker.

Why does the “expand” part belong to engineers?

Palantir is open about this strategy. Ryan Taylor, its chief revenue officer, said on the company’s Q1 2024 earnings call that it would keep landing new customers and then expanding those relationships as the product gained traction.

The way in is the bootcamp. According to Taylor, more than 915 organisations had taken part by then. Since late 2023, Palantir has described AIP bootcamps as a way to get real workflows running on a customer’s data in five days or fewer.

The company also says bootcamps lead to larger deals and shorten the time it takes to convert and then expand contracts. If the way in is a workflow running on real data, it is reasonable to think the expansion opportunities surface from that same workflow, which is to say from the engineer’s work.

Sales doesn’t know that the warehouse team exports the same Excel file every Monday morning, or that the ERP connector you wrote would work for three other departments. You know, because you are sitting inside the customer’s systems.

The order cannot be reversed. The fde.academy deployment playbook warns that trust lost in the first weeks is very expensive to rebuild. The same playbook advises shipping a narrow slice that works within about two weeks before widening the feature set. Deliver one small thing solidly first; discuss expansion later.

An example: from invoice reconciliation to procurement

Picture a logistics company. Your first project is an agent that reads supplier invoices, matches them against purchase orders in the ERP and pushes discrepancies to accounting for approval. The scope is deliberately narrow: domestic freight invoices only, one accounting team only.

Four weeks after go-live, the first job is to open the logs. Say 20 accountants have access and 15 use it weekly: 75% adoption. That is a solid enough base to start talking about expansion. If only 4 of the 20 were using it, your job would be to fix adoption, not to sell more.

The second signal is a workaround. You notice that the head of procurement asks an accountant to export the discrepancy list every Monday, to take into negotiations with suppliers who keep getting their invoices wrong. That is a user the contract never accounted for, who found the product on their own.

The third signal is in the code. The invoice parser and the ERP connector already exist. International freight invoices go through the same ERP; only the format and currency differ.

So the second slice costs far less than the first. This is the mechanism the fde.academy playbook describes: one-off custom work gradually standardised into reusable features.

Put those three signals in a table and you have something to hand the account manager:

Signal	Where you saw it	Question to verify	Who needs to know
Adoption 15/20 accountants	Weekly usage logs	Who isn’t using it, and why?	Head of accounting
Procurement exports every Monday	File requests, forwarded emails	What decisions do they use the file for?	Head of procurement
International invoices on the same ERP	Data schema, existing connector	What’s needed beyond the new format?	Revenue team, internal engineers

The next step is the review meeting with the customer, and here the way you frame questions matters a great deal. Don’t open with “we could build the international part too”. Ask about the problem:

I noticed you’ve been pulling the discrepancy file every week. What do you use it for, and how long does that take you today?

If the answer is two afternoons a week stitching numbers together by hand, you now have a quantified problem. Take it back to the revenue team rather than promising scope on the spot.

Doing it yourself in five steps

The first step happens at scoping: pick a narrow slice and write down the adjacent workflows you are deliberately leaving out. That list is your future expansion map, and it lets you turn down scope creep without souring the relationship.

After go-live, measure adoption weekly as actual users over users granted access, not as the number of features shipped. In parallel, log every workaround: exported files, manual copy steps, people who routinely ask someone else to pull results for them.

When writing code, separate the shared parts (connectors, parsers, evals) from what is specific to this customer. That investment is what makes the second slice cheaper, and it is also what the product team needs to standardise it into a feature.

Once adoption is solid, fill in the signal table, verify each row with a question about the problem, and pass it to the account manager or revenue team. They handle budget, contracts and signatories. Your part is the technical evidence and the effort estimate.

Finally, when the second slice is approved, repeat the same cycle: narrow, ship fast, measure, look for the next signal.

Mistakes that make the opportunity disappear

The first is raising it too early. Proposing expansion when only 4 of 20 people use the product just tells the customer you care more about selling than about them, and trust starts to erode.

The second is promising scope yourself. A single “we can add that quickly” in a meeting can wreck the revenue team’s pricing strategy, and your team ends up doing extra work nobody pays for.

The third is harder to spot: expanding by copy-pasting custom code. The second slice then costs no less, technical debt doubles, and by the third slice nobody wants to touch it.

The last is talking only to users. Accountants loving your product doesn’t mean the head of procurement knows it exists. The person with the problem and the person with the budget are often two different people.

Putting this skill on your CV

Hiring demand is hot: Indeed data shows postings for applied AI roles rose more than 800% between January and September 2025. When reading job descriptions, look for phrases such as “adoption”, “expansion” or “partner with revenue team”. They tell you what the company will judge you on.

On your CV, replace “built an invoice reconciliation pipeline” with a line that has numbers: “got 15/20 accountants using it weekly within four weeks; identified a need in procurement, opening a second slice that reused the existing connector”. Whether you work in outsourcing or on internal products, every project has usage logs and workarounds worth telling.

Shipping the first project well is necessary but not sufficient. From your next project on, practise spotting the second one before the customer has even thought of it.