Frequently Asked Questions

It depends entirely on scope — a single follow-up sequence and a multi-system operational workflow are different projects. We don't publish a fixed price list because the honest answer always depends on what you're automating; a strategy call gives you a real number for your specific case.

Timeline follows the same four stages described on the Lead Follow-up pillar — diagnose, design, build, launch — and scales with scope. A single workflow is faster than a multi-system rollout. We give a specific timeline once we know what's being automated, not before.

n8n itself is open-source and can be self-hosted, which means data doesn't have to leave infrastructure you control. Security in practice depends on how a workflow is built and where it's hosted, not on the engine alone — see the Trust Center for how we handle data across every system we build.

Every system we build routes anything outside its defined playbook to a person rather than acting unsupervised, and every action stays visible and reversible. Mistakes inside the defined playbook are handled the same way any process error is: found, fixed, and the playbook is corrected.

No. It removes repetitive execution around decisions your team already makes, so their time goes to the judgment calls that actually need a person. See the oversight note on the Automation pillar for how that boundary is enforced in practice.

No — a working system is handed over documented and running, not as a kit you assemble. Day-to-day use doesn't require touching the automation platform itself; changes to how it behaves go through whoever built it, the same as any other business system.

No — connection is an architecture decision, not a vendor decision. A relational system can be built on Notion or on what a business already runs; the point is the relationships between functions, not the software brand.

No — a wiki page and the record it describes are still two separate things someone has to keep in sync by hand. A connected system removes that gap structurally; see the wiki trap for the difference in full.

It follows the same four stages as any implementation here — diagnose, design, build, launch — and scales with how many functions need connecting. We give a specific timeline once the dependency map is clear, not before.

No. Connection keeps information current everywhere it's referenced; it doesn't decide anything. Every team still owns its own judgment calls, now working from one current picture instead of three conflicting ones.

From scratch, hand-built. Templates are a legitimate choice for a low-stakes site, but a primary business channel gets a site built around its actual audience and load-performance needs — see hand-built vs. template for the honest trade-off.

Via Lighthouse and Core Web Vitals field data on the live, deployed site, before and after any rebuild — the same measurement standard behind every performance claim made across this site.

It's handed to the system that acts on it automatically, not left in an inbox — this is the fourth capability every working website needs. See the Lead Follow-up cluster for exactly what happens next.

It follows the same four stages as every project here — diagnose, design, build, launch — and the timeline scales with scope. We give a specific number once we know what the site needs to do.