Dietbox

Overview

A Brazilian SaaS used by nutritionists to plan diets and by their patients to follow them. Two audiences with almost nothing in common share one product, one identity system and one platform — and that platform spans a decade-old monolith and a newer generation of services running beside it.

What I did

The problem

The nutritionist lives in the tool all day; the patient opens it to read a meal plan. Same product, same identity backbone, opposite expectations. And in 2020 a .NET Framework monolith carried both on Windows App Service, shipping once a day, at night, because that was the only window that felt safe.

By the numbers

Architecture

What it does

• Diet planning for the practitioner, and the same plan in the patient’s own app.
• Two sign-up journeys over one identity system — a practitioner subscribing, and a patient invited by the one treating them.
• Live updates pushed to open clients without a refresh.
• Subscriptions and recurring billing.

Engineering decisions

• Custom identity policies instead of a hosted login

  Two audiences share a product but not a journey: a practitioner signing up for a subscription, a patient invited by the one treating them. Custom B2C policies gave each its own sign-up, sign-in and password flow, branded per audience, over one identity backbone instead of two user stores to keep in sync.

• Shared building blocks before shared services

  The newer services start from a common domain, infrastructure and identity layer rather than each inventing its own. It is what let a small team add a service without each new one arriving in a new style.

• Event sourcing in the portal, not everywhere

  The portal’s questions are historical — what changed, when, and by whom — so its state is derived from events. The rest of the platform is not, because the rest of the platform is not asking that, and event sourcing charges rent on every service that adopts it.

• Realtime as its own service

  Long-lived connections scale on a different axis from request traffic, and behind a Redis adapter any instance can push to a client connected to any other. Keeping it inside the monolith would have tied both to the same deploy — and the monolith deployed once a night.

What changed under my direction

• From one nightly deploy to several a day

  I brought in Scrum and trunk-based development. A deploy in daylight stopped being an event.

• A payment migration nobody noticed

  I planned and ran the move of thousands of active subscribers from Iugu to Pagar.me. Revenue never paused — the kind of change whose measure of success is that nothing happened.

• Cloud spend as an engineering problem

  I took a cost pass over the Azure estate — without a feature freeze to pay for it.

• Reporting engineering in the executive’s language

  I started bringing DORA metrics and a roadmap to the executive team, so investment in technology was argued with evidence rather than conviction.