Sarah asked whether the app sends a reminder before an invoice is due. Deflekt answered from the code and the data, then noticed four customers had asked for a seven day option, and prepared a spec and a small pull request.
Monday, 14:20. Sarah is on a call with a prospect who wants to know whether the app reminds their clients before an invoice is due. She asks Deflekt instead of waiting for a developer.
Deflekt answered from the code, with the source cited:
> app/jobs/payment_reminder_job.rb
sends a reminder 3 days before the due date
only when "payment reminders" is enabled in company settings
email only, in the client's language
> companies with payment reminders enabled: 612 of 1,380
> reminders sent last 30 days: 18,904
Yes, the app sends a reminder three days before the due date, by email, when the setting is turned on. 612 companies use it, and it sent close to nineteen thousand reminders last month. Sarah had her answer before the prospect finished the next question.
Deflekt keeps a file per customer and remembers every request. While answering, it noticed that the same question had come up before, in a different form. Four customers had asked, in separate tickets over the past five months, for the reminder to go out earlier:
All four wanted the same thing: a reminder seven days before the due date. Each ticket had been closed with a polite no.
Deflekt drafted a short spec. The setting gets a choice between three and seven days, three stays the default, and nothing changes for the 612 companies already using it. It checked the job and the scheduler: the delay is a single constant, so the change is small.
The pull request adds the setting, reads it in the reminder job and covers both values with tests. It was run in two environments with the same data, before and after, and the recording of the settings page and the scheduled reminders was attached. Deflekt also drafted a short reply for each of the four customers, in their language, to send once the change ships.
Lina reviewed the change, asked for one rename, and Deflekt handled it in a second round. It shipped on Wednesday. Support approved the four replies.
The prospect signed. The four customers heard back the same week.
Deflekt linked the four tickets to the feature, so the next customer who asks gets a yes. Feature work is not where Deflekt spends most of its time, but when a request keeps coming back, it notices. See the product questions use case and the feature requests use case.