This is a track from the corporate development block (listed in the price list as Event-Driven Deepening). It comes in as the product grows from MVP to MMP and MLP. The track costs $4700.
While there are few users, everyone learns about events in the system by talking to each other. Once there are many, the lack of notifications and a log turns into blindness: nobody knows what happened, and nobody can reconstruct it.
For a business, that blindness has a price. A customer did not get a confirmation and ordered from a competitor. A manager missed a payment and did not ship the goods. A background export stopped on Friday and nobody noticed until Monday. This track makes sure the right person hears about what matters straight away, and that any action in the system can be traced.
What is included
- Notification system: validation, alerts, push, e-mail, Telegram.
- Action and event logging.
Notifications by channel
Each notification is designed as a rule: which event triggers it, who it is for, which channel it goes through and what the person should do after reading it. Validation guides the user inside the interface, alerts tell the team about failures, push and e-mail keep the customer informed about their order, and Telegram suits quick messages to staff.
Delivery channels are kept separate from event sources. That way a new channel can be added without touching business logic, and one event can be sent to several places at once.
Action and event log
The log records who did what and when: created, changed, deleted, approved. For changes it stores the value before and after. System events are recorded separately: background jobs starting and finishing, exchanges with external services, errors.
You need the log sooner than you think
The very first dispute ("I didn't change that", "the order disappeared", "the customer got the wrong email") comes down to one question: who did what, and when. Without a log there will never be an answer, and the investigation turns into competing versions of events.
The log is especially critical for integrations. When another company's system is on the other end, only a record of outgoing and incoming messages shows whose side the failure was on.
Notifications are not just push
The most useful ones are usually the dullest: an alert that a background job did not run, and an email saying an integration returned an error. Nobody asks for them at the start, and they are exactly what saves money later.
The flip side is that people stop reading notifications about everything. So during design we cut the noise and keep only the messages that lead someone to act.
What the business gets
- Customers learn the status of their order, payment or booking on time and contact support less often to ask what is going on.
- The team hears about failures from the system, not from an unhappy customer.
- Management can reconstruct any disputed case from records rather than from people's memories.
- Investigating a failed integration with a partner relies on exchange records, not on each side's account.
Cost and what it depends on
The track costs a fixed $4700. That covers the notification system across the agreed channels and the logging of actions and events.
Before work starts, the consultation pins down the list of events and channels, the recipients by role and exactly what goes into the log. If another team built the product and it is unclear which events it even has, we start with an audit of the existing system: $800 for a written report, or $2400 with an early prototype of the change.
What breaks if you cut corners
- A failed background job or integration is spotted days later, after lost orders have piled up.
- A dispute with a customer or employee is settled on someone's word, because there is nothing to confirm the action.
- Notifications hard-coded in a hurry have to be rewritten every time a new channel is added.
- Without filtering, staff switch notifications off entirely and miss what matters.
Examples from our work
The awaited answers tracker is built on a simple idea: "you have new mail" does not help, while "the reply you were waiting for has arrived" does. Expectations are listed, the service polls sources, a model checks what it finds, and only confirmed matches become a short message in a work channel. Delivery channels are kept separate, so new ones are added without reworking the sources.
In the Goal Decomposer app, deadline reminders appear as system browser notifications through a service worker, and a timer checks deadlines every 30 seconds. The limitation is stated plainly: reminders arrive while the app is open in a tab. Limits like this should be agreed with the client before development, not after users complain.
The AI agent log monitor shows that a log can make money, not just settle disputes. It turns logs into a table: which task, how many tokens and what it cost. From that table you can see which runs pay off and which were wasted.
Where to go next
Related tracks: security and server optimisation. The map of the series is in the app development strategy.
Discuss your product's growth.
If your product has grown and you hear about failures from customers first, book a free consultation with an architect. We will work out which events and channels you actually need, and after the consultation we will send a price and timeline broken down by stage.
