Matheus Felipe

Problem: Selling tracking means selling a brand, not somebody else's software — and the alert has to reach the owner where they actually read it, not in an email nobody opens.

• Architecture: upstream Traccar, with a custom frontend and external integrations
• The alert leaves through WhatsApp, not e-mail: it is where the owner reads within minutes
• A PWA with its own service worker instead of a store app: it installs on iOS and Android with no review and no second codebase
• The branding bind mount is pinned to the file's inode, so every branding deploy recreates the container — otherwise it serves old content in silence

Problem: The clinic ran on notebooks and WhatsApp: follow-up appointments were forgotten, leads coming from Instagram were lost between conversations, and stock ran out with no warning.

• SQLite on a volume instead of Postgres: one clinic, one server — the whole database is a single file, and so is the nightly backup
• Keywords classify the lead before any AI touches it: no cost per message and the receptionist can audit the rule
• The scheduler runs inside the same process: reminders, returns and low-stock alerts need no external queue to be reliable at this size
• Every write goes to an audit log, because "who moved this appointment, and when" is a clinic question, not an engineering one

Problem: The agency only found out an ad account had run dry when the client complained — reporting meant screenshots and a spreadsheet rebuilt by hand every week.

• One Supabase per deployment: one agency's data cannot touch another's, not even through a query someone forgot to filter
• pg_cron inside the database instead of a worker: the balance alert does not depend on any process staying up
• The brand comes from the tenant row, so the agency's client never sees the product's name anywhere in the panel
• Turning a campaign on or off is the only write we make into an ad account — admin only, confirmed on screen, recorded in an audit table

Problem: A studio's work is visual, but the site that shows it loads slowly, says nothing to Google and gives the visitor no obvious next step.

• Static generation: with no server in the request path, there is nothing left to be slow
• One page per service and per neighbourhood from a single template — the demand is local, so the content has to be too
• The gallery loads first: in architecture the photo is the sales argument, not decoration
• A fixed call button on mobile, because this traffic converts by phone in minutes and rarely fills a form

Problem: Businesses need custom automation but existing tools lack deep AI integration and are expensive at scale.

• A queue between the API and the execution: a slow workflow never holds the user's request open
• One isolated worker per run, so a client's own code freezing does not take the others down
• pgvector in the same Postgres: RAG without keeping a second, vector-only database alive

Problem: Small businesses lose leads because they can't manage WhatsApp conversations at scale.

• Webhook rather than polling: the conversation lands on screen at WhatsApp's pace, not on a timer
• The model classifies and suggests; by default a person still sends the reply
• Inbox and Kanban read the same record, so sales never retypes what support already wrote

Problem: Knowledge workers waste time keeping Todoist and Notion in sync manually.

• Conflict resolution is explicit: last write does not win by default, because both sides are edited by the same person minutes apart
• Every job retries, so one API being down becomes a delay instead of a lost change
• An audit log per item: the answer to "why did this move?" has to exist

Problem: Non-technical users struggle to clean and understand their data.

• Processing in Python, interface in Next.js: each side does what it is actually good at
• A transformation is a named pipeline, not a click someone remembers — next month it runs again the same way
• The model writes the query and the user sees the resulting table, so the answer stays checkable