Engineer. Designer. Product leader.

Superfiliate sells creator-led growth as a category: creators treated as a measurable, full-funnel acquisition channel rather than an awareness spend. It sits against influencer marketing on one side, which trades in one-off campaigns and impressions, and affiliate software on the other, which trades in last-click commission. Superfiliate's argument is that neither describes what actually happens when a creator sells something, and that the whole lifecycle belongs in one system.

I joined in July 2021, six months after the first product work and before the architecture was settled. I was there near the beginning: early enough to help shape how the domains related, the product vision and how the system would grow — and I stayed long enough to help take it to US$10M ARR and find out whether those decisions held.

I held three roles on the same product. As a Senior Product Designer I shaped interfaces, flows, and the architecture underneath them. As a PM I moved to problem definition, prioritization, roadmap, discovery, and validation. As Head of Product I became responsible for strategy, project quality, stakeholder alignment, go-to-market, releases, positioning, hiring, and career development — and for the harder problem of keeping around eight simultaneous squads building something that still felt like one product.

The shortest honest description of those five years: I moved from designing the product, to managing the product, to designing the organization and processes around the product.

The product spans the creator-marketing lifecycle across roughly 45 product areas, four sales channels, five payout providers, and forty-odd connected services. It serves influencer marketers, creator strategists, ad buyers, growth managers, creators, talent managers, and finance and operations teams. A good part of what keeps that coherent is process rather than software — how work enters the roadmap, how a spec is sized, how measurement gets planned, and where a squad has room to define the solution — and that part is mine.

The constraint that shaped almost everything was capacity. For a long stretch the Product Management function was effectively me working alongside the CPO, supporting an organization with roughly nineteen engineers and six product designers. As a designer I worked across three or four squads at once, holding the current squad and the next one in my head simultaneously. That is why architectural consistency mattered so much here — there was never a large central team available to go back and fix fragmentation later.

Kiper's customers were condominiums and houses that wanted a higher level of security — particularly in large cities, or in places where public safety made a permanent on-site guard both expensive and insufficient. The proposition was a remote concierge: instead of stationing a person at every entrance, install equipment at the access points that matter and have a remote team watch the property twenty-four hours a day.

That team did considerably more than answer the intercom. Operators handled visitors, deliveries and packages, access requests, panic and coercion events, electric-fence signals, fire events, and the continuous monitoring of the equipment itself.

Which makes this an unusual kind of software. An action in the interface opened a door, opened a gate, granted a permission, or changed the behavior of a security device. The digital system and the physical building were the same system.

I joined in May 2020, three months before Porter Group formed by merging Porter — the remote-concierge service and franchisor — with Kiper, the technology company that built the hardware and software, and Villaro. I worked across two surfaces of one product: Kiper Monitoring, the operational side used by the remote team, and Kiper App, the resident and property-manager side. They were never really separate products. A resident configured in the app changed what the operator saw. A property rule set in Monitoring changed which action was correct. A door could be opened from either surface depending on who you were.

Fourteen months, one product, three completely different mental models over the same underlying truth about people, permissions, properties and equipment.

Zygo existed to answer one question on behalf of restaurants: how do we get a customer to come back? That question produced loyalty programs, points, rewards, promotional mechanics, at-scale communication, gamification — and eventually a much less obvious answer about customer identity.

I was there at the point in my career where I was still moving between front-end engineering and design, and at Zygo that stopped being a transition and became the method. I designed in Sketch and coded the experience, working directly with engineering on backend logic and product rules rather than handing a file across a wall. Technical understanding became part of design instead of a constraint that arrived after it.

Three products, two of them halves of the same loop. Companion was the merchant side, where a restaurant configured its loyalty program, ran promotions and communicated with customers. Portal do Consumidor was the consumer side, where that customer saw points, progress and rewards. What one configured, the other received.

Then in March 2020 COVID closed the dining rooms, the delivery marketplaces were taking twenty to thirty percent of every order, and the problem changed shape entirely. Delivery do Bem was built in seven days.

Zygo is where I learned to think of product design as the connection between customer behavior, business economics, data models, interface and code — problem, experience, logic, implementation as one job rather than four.

Between 2015 and 2019 I was the front-end and UI/UX side of a small software studio in Florianópolis, shipping web systems and hybrid and iOS apps for over 40 clients in legal tech, education, real estate, financial services and retail.

I joined as a front-end intern and left owning both the interface design and its implementation. I shipped hybrid and native iOS apps here before I ever called myself a designer, and this is where I stopped only implementing other people's designs and started arguing about them.

Product design, product management and product leadership all came after, in that order, and all of them build on this. It is why I can still read a diff.

One thing from that period outlived me. An ed-tech platform I helped build for a client later became the foundation of a full product platform, built after I left, on the work we did.

Where my career started: a web-development internship, August 2014 to July 2015.