Not every new feature needs its own screen.

It's something worth thinking about when a digital product starts growing.

A new feature gets introduced, so a new page is created.

Then another feature arrives. Another page. Another menu item.

Eventually, the navigation starts reflecting everything the product has accumulated rather than how people actually use it.

And that's where things can become unnecessarily complicated.

When you're designing or improving an existing product, adding functionality isn't just about finding space for another interface.

It's about understanding how that functionality fits into the workflows people already have.

Imagine an invoicing platform introducing automated payment reminders.

You could create an entirely separate section for managing them.

Or you could integrate that functionality directly into the invoice workflow, where users already have the relevant context.

Both approaches can make sense.

If the feature involves complex configurations, reporting, or needs to be managed independently, a dedicated section might be justified.

But if it's something people naturally need while completing another task, moving them to a separate screen could introduce unnecessary steps.

I think this is particularly important with established products.

Every new feature affects more than the area where it appears.

It can change navigation, information hierarchy, existing user habits, and the overall complexity of the experience.

And the more a product grows, the more important those decisions become.

Sometimes introducing a new capability means creating an entirely new experience.

Other times, the stronger solution is making that capability feel like it has always belonged there.

A successful n8n execution can still end with a lead that never reached the CRM.

In a local n8n 2.47.3 demo with a mock CRM, all eight webhook executions finished with status “success”. One of those requests exhausted all three write attempts. The caller received HTTP 503, no event was stored for that request, and one alert reached the local alert sink. The workflow had handled the failure, so the execution itself completed successfully.

For a lead-intake workflow, test these three outcomes separately: • First delivery: one lead, one event and one review task. • Same event and business data replayed: HTTP 200, outcome “replayed”, still one of each. Compare the stored values too, not only the counts. • All write attempts fail: a failure response to the caller, no unintended write, and an alert someone can act on.

Those were the observed results in this demo. The replay preserved the original lead and event rows; the failure case left the existing records unchanged.

Before handing a workflow to an operations team, agree what “delivered” means in the destination system and test the exhausted-retry path. An execution-success count alone can miss failed deliveries that the workflow handles deliberately.

Have one reproducible n8n workflow failure? Send the failing step, expected result and a redacted example through my scoped repair service: https://contra.com/s/ergMeOOY-repair-one-reproducible-n8n-workflow-failure?r=shivansh_jain_jkup5ikk