Disparador

The starting point was a Tkinter desktop application. It handled sending, but split campaigns, schedules and automations into confusing flows and lacked the operational depth of a web platform.

The new product had to unify three campaign formats without hiding their differences, process deliveries safely and make every event observable. It also needed a navigable demo with no risk of real sends.

The architecture places immediate, scheduled and sequenced campaigns in the same domain. Users choose a type, compose content, define the audience and manage everything in one list with consistent states and actions.

Deliveries leave the interface and enter an asynchronous queue. Each sender follows its own limits, failures receive controlled retries and the system records the reason for each error.

Opens and clicks are connected to campaigns, recipients and links. Guest mode uses demonstration data and blocks real side effects, allowing anyone to explore before configuring a sender.