PostHog prices FDE work by milestone, not by the hour. Here is what engineers should learn from it

PostHog’s public handbook is explicit: forward deployed engineering work is quoted per milestone, not by the hour. The same handbook contains a stricter rule as well. Any deliverable that grows to double its scope must get a new quote rather than being quietly extended.

The decision has reached the public /services page too. A pull request on the posthog.com repo sets a minimum of $5,000 per milestone, replacing an earlier line that tied the fee to roughly 20% of the credits a customer bought in its first year. The PR describes this as a deliberate choice by the FDE team.

PostHog does not explain why. On its overview page, though, it writes that AI has helped people build faster, so the value the team brings is judgment, taste and the ability to reason.

PostHog does not connect those two points itself. But if the real value lies in judgment, hourly billing is hard to defend, because hours can only measure output.

For an engineer who works as an FDE, or wants to, the model is worth reading closely. It shows how to turn judgment, which is normally hard to see, into things a customer can sign for: a milestone, a quote, an approval.

Why are hours the wrong measure?

PostHog’s “How we work” page puts it plainly: an FDE’s value lies less in how much they produce and more in the judgment they bring to the work.

Picture two FDEs given the same job. The first writes 3,000 lines of script over two weeks. The second spends the first two days asking the customer questions, finds that two-thirds of the events slated for migration are no longer used by anyone, and migrates only the rest in a week.

Billed by the hour, the first engineer earns more. Billed by milestone, the second wins, and so does the customer. The pricing model therefore forces the whole team to answer “what should we do?” before “how much should we do?”

The argument is not unique to PostHog. IndiaNIC, discussing agency pricing in general, argues that once AI cuts the hours behind a deliverable, hourly billing penalises fast workers and rewards slow ones.

Customers have their own reasons to be wary. Ghanemzadeh, who writes about FDE pricing from a practitioner’s point of view, describes the familiar time-and-materials model: the work has no clear stopping point, and the total cost only becomes visible when the engagement ends.

A milestone must be narrow for the price to be honest

A fixed quote is not a cure-all. Ghanemzadeh himself notes that a fixed price for a fixed outcome is only honest when the scope is narrow enough. That is why the unit of pricing has to be a clearly defined milestone, not an entire vague project.

Imagine a customer that wants to move its analytics data from an old tool to PostHog. A weak milestone says “support the migration”. A good one says: events from the three main applications flow into PostHog, the five most important dashboards match the old system’s numbers, done in about three weeks.

The second version is measurable, bounded and checkable, which is what makes it quotable. When the customer reads it, they either nod or say “actually, the revenue dashboard is what we really need”. Either answer is useful, because the mismatch surfaces before anyone has written a line of code.

PostHog’s handbook also encourages FDEs to share unfinished work early so colleagues can comment on the direction. For a milestone, the practical advice is to have a colleague read the draft description before it goes to the customer: a wrong call at this stage costs more than at any later one.

What happens when scope grows?

Back to the migration. Midway through the second week, the customer asks: while you’re at it, could you also sync the data to the data warehouse? For many engineers, the natural reflex is to say yes to keep the customer happy.

PostHog’s rule blocks exactly that reflex: a deliverable that doubles in scope must become a new quote, not extra work absorbed along the way. The rule protects both sides. The FDE is not dragged into a project with no end, and the customer gets a clear decision instead of a surprise invoice.

The skill behind the rule is being able to say “yes, but that is a separate milestone” without damaging the relationship. You can practise it now, with the internal teams that keep asking you for extra work.

“Done” means someone on the customer side signs

According to PostHog’s “Working with customers” page, a milestone is done only when the deliverable has shipped and been approved by a named person on the customer side. Not “the customer seems happy”, not “the hours ran out”, but a specific person who takes responsibility for saying “this passes”.

In the migration example, that person might be the customer’s head of data, who opens the five dashboards and confirms the numbers match. This forces you to establish at the outset who will sign and by what criteria they will check.

A related piece of advice: write documentation that lets the approver check the work without you sitting beside them. If only the FDE understands how the script runs, that signature will be hard to get.

What remains after each milestone

A milestone may close an invoice, but PostHog does not want the lessons to close with it. The handbook asks FDEs to turn what they build for one customer, if it is useful to others, into examples, templates or product improvements.

The overview page adds that patterns repeated across engagements become reusable assets and product improvements.

DataCamp names the skill involved: product judgment is deciding which parts should be tailored to one customer and which belong in the core product. Choose wrongly and you leave behind one-off code that nobody can maintain. Also according to DataCamp, good FDEs carry lessons from the field back to the product engineering team so the platform improves for everyone.

In the migration example, the script written for the first customer, once cleaned up, could become a template for the tenth. That too is a judgment call: which parts are general enough to invest in, and which should stay a one-off.

Aspect	If billed hourly (comparison scenario)	PostHog’s FDE model
Pricing unit	Hours worked	Each milestone, with a minimum
Cost to the customer	Total known only when the engagement ends	Known in advance for each milestone
When AI speeds up the work	Fast workers lose out	Price tied to the deliverable, not the hours
When scope grows	Easy to keep adding hours	Doubled scope means a new quote
End point	Easily tied to hours or budget running out	Shipped and approved by a named person on the customer side
What is left behind	No specific requirement	Examples, templates, product improvements

The middle column is a scenario inferred from the logic of hourly billing, for comparison; it does not describe any particular company. Read row by row, the right-hand column always forces the engineer to decide earlier and more openly. Judgment cannot be measured directly, so this is an indirect way for an organisation to see it.

Borrow PostHog’s signals for interviews and your CV

PostHog’s handbook hands you a ready set of signals to check against: quotes per milestone, a new quote when scope grows, sign-off by a named person on the customer side, and lessons turned into reusable assets. When you read any FDE job description, look for traces of these mechanisms.

In an interview, borrow PostHog’s rule directly: when a deliverable doubles in scope, does the team write a new quote or quietly extend it? Ask also who on the customer side signs off, and which parts of your work will be turned into templates for the next engagement.

On your CV, follow the life of a milestone. Which checkable outcome did you agree before starting, when did you say “that is a separate milestone”, who on the customer side approved the work, and how did what you left behind make the next job faster?

If you are already an FDE, the cheapest exercise is to start every job with half a page defining “done” and end it with a customer signature. When coding speed no longer separates one engineer from another, those two habits are what people pay for.