Why I Stopped SignaFlow: Validate the Integration Before Building the Product

SignaFlow started with a clear promise: manage a company’s email signatures from one dashboard and apply updates without asking every employee to copy and paste HTML.

I built much of the visible product before validating the hardest part of that promise. When I finally tested the installation path, I could not find a supported API workflow that delivered the centralized, automatic behavior the product depended on.

The project was stopped on October 18, 2025. The code remains public because the mistake is more reusable than the product.

What I built first

The repository contains a React and TypeScript frontend with:

• a dashboard and employee management;
• three signature templates;
• campaign fields and settings;
• a configurable n8n webhook client;
• an n8n workflow that returns HTML and plain-text signatures.

The documented final flow looked like this:

React frontend → n8n webhook → generated signature → manual copy/paste

That flow could generate a signature, but generation was not the core promise. Centralized installation was.

The assumption I tested too late

I treated email-client integration as an implementation detail. It was actually the product’s main feasibility risk.

The correct first milestone was not a dashboard. It was a narrow proof:

1. choose one target client and account type;
2. install or update a signature through a supported integration;
3. repeat it for a second employee;
4. verify what permissions and administrator controls are required;
5. confirm that the flow still matches the intended customer experience.

Had that proof failed on day one, the project could have changed direction before the frontend accumulated momentum.

Why manual copy/paste was not enough

Manual delivery can be a valid product. It can provide consistent templates, previews, and instructions. It was not the product I intended to build.

The original value proposition depended on removing repetitive employee action. Once the remaining workflow required each person to install their own output, the product had crossed into a different category with different competitors and a weaker reason to exist.

That distinction matters: a functioning fallback is not automatically a viable substitute for the original promise.

The useful parts were still incomplete

The frontend used mock or local state. Supabase integration, authentication, and production deployment were not complete. The n8n documentation also left webhook authentication and rate limiting for later.

Those are solvable engineering tasks, but solving them would not repair the unvalidated installation model. Continuing because the visible interface looked close to finished would have protected sunk cost rather than reduced product risk.

The lesson: order work by uncertainty

For integration-heavy products, I now want the first week to answer questions that can kill the idea:

• Does the required API exist for the exact customer and account type?
• Can it perform the critical action, not merely return related data?
• Which permissions, reviews, or administrator roles are required?
• Does the fallback preserve the original value proposition?
• Can the proof run against a real account before the UI is built?

UI work is predictable. External policy and integration constraints are not. The uncertain part deserves the earliest test.

Stopping was part of building

SignaFlow was not evidence that centralized signature tools are universally impossible. It showed that the integration path I targeted did not support the automatic product behavior I had designed around.

That narrower conclusion is more useful. It points to a concrete process change: build the riskiest integration proof first, then earn the right to build the dashboard.

The archived implementation and its status are documented in the SignaFlow repository, including the n8n workflow guide and deployment notes.