How to price automation projects without hiding the risk.

Why hours multiplied by a rate is not enough

An automation can look simple while the delivery conditions remain uncertain. Credentials may not be ready. Source data may be inconsistent. APIs can impose limits. Exceptions need somewhere to go. The client may expect monitoring and support after handover.

If the estimate counts only build time, those tasks become unpaid work or rushed work. A pricing floor should include the full effort required to reach an agreed result.

A transparent pricing-floor method

1. Estimate build effort. Count the work needed for the core workflow, integrations, transformations, branches, approvals, and custom API steps.
2. Add delivery work. Include discovery, planning, testing, documentation, communication, deployment, and handover.
3. Apply risk contingency. Increase the hours when access, data, failure impact, ownership, or support expectations remain uncertain.
4. Add direct costs. Include project-specific tools, API credits, contractors, or setup costs you must pay.
5. Apply your margin rule. Divide the delivery cost by one minus the target margin. Do not add margin as if it were a simple markup.

Worked example

Consider a fictional n8n project with 24 build hours and 12 hours for discovery, testing, documentation, and handover. Total delivery effort is 36 hours.

• 36 delivery hours with 20% contingency = 43.2 adjusted hours
• 43.2 hours × €90 hourly floor = €3,888
• €3,888 + €200 direct costs = €4,088 delivery cost
• €4,088 ÷ (1 − 20% margin) = €5,110 pricing floor

The result is an internal planning floor, not a claim about the market price or what a client will accept. You can round only after checking what the package includes.

Risk questions that should change the quote

• Are all systems, credentials, scopes, and test accounts available?
• Is the input data structured, complete, and owned by someone who can correct it?
• What happens when a step fails, times out, or produces an unexpected value?
• Who approves exceptions, and what happens when nobody responds?
• Who monitors the workflow after launch?
• How often are the connected systems or business rules expected to change?
• What support period is included, and what becomes a paid change?

Unanswered questions do not always require a larger fixed quote. Sometimes the correct commercial response is a paid discovery phase before committing to delivery.

When to use fixed price, discovery, or time-based billing

Fixed price works best when the process, inputs, access, acceptance criteria, and support boundary are clear. Paid discovery is safer when important technical or operational facts are missing. Time-based billing can suit exploratory work where both sides expect the scope to change.

The delivery model is a risk decision. It should not be chosen only because a client asks for one number.