The broken tooth

In 2013 and 2014, my co-founder Gustavo and I were running out of money. We were on our second startup in a row that wasn’t working - first an “Airbnb for cars,” then a ride-sharing project that went viral on national TV and never made a real. The money was nearly gone. The situation had collapsed into a binary: build something that earns revenue, or go find jobs.

I grind my teeth when I’m nervous. That year, I had a lot to be nervous about - enough that the bruxism finally broke one of my teeth, and I had to go to my dentist to fix it.

While I was in her chair, I learned that the software running her practice had just failed her. Again. And when I looked at it, I understood why: it ran on a Windows virtual machine, on the Mac at her reception desk, connected to a physical server sitting inside the office. Every layer of that stack was an accident waiting to happen, and the accidents kept arriving on schedule. I tried to fix the immediate problem for her. I couldn’t.

So I asked the only question that mattered: “What do you pay for this?”

A thousand reais a year.

One day to a mockup, one month to a product

I went home with an idea I couldn’t put down: build the thing she actually needed. That same night, I made a mockup of it. Not a spec, not a business plan - screens. I showed them to Gustavo, and we did what we’d keep doing for the next decade: we cut. Simplified everything down to the smallest product that would genuinely serve her.

The next day, I had lunch with my dentist and put the mockup in front of her.

“Would you pay for this? It’ll cost a thousand a year - what you pay today.”

Her answer was a loud, instant “CLARO!” - of course. I confess I didn’t believe it. People are polite at lunch. So I spent the rest of the week showing those mockups to every dentist I could reach, asking the same blunt question about the same price. The answers kept coming back yes - yes to the need, yes to the willingness to pay.

There is one upside to having a rope around your neck: development flies. With no revenue and no time, there’s no temptation to gold-plate. Exactly one month after that lunch, the first version of Doutore was live in her clinic - a dead-simple daily agenda and a patient history we called Histórico. She was our first paying customer.

That was 2014. We’ve been profitable since the following year and never raised a cent.

Eleven years later

She’s still a customer today. She knows she’s customer #1 - it’s not a secret between us; it’s a small shared piece of history. Over the years she became something more useful than a customer: one of our best advisors. When you’ve served someone for eleven years, watched their practice change, fixed what broke and built what was missing, the relationship stops being commercial. She tells us the truth.

And that’s how the same office produced a second company.

The intern

Years later - eleven years into running a profitable software business - we could see another problem clearly. In Brazilian healthcare, getting documents legally signed is painful. The standard approach demands an ICP-Brasil digital certificate that most patients simply don’t have. Consent forms, contracts, treatment plans: every clinic improvises around the same broken process.

We knew the problem was real. But for us, knowing has never been the bar. Understanding is.

So I went back to my dentist with a strange request: I asked her to let me work at her front desk. As an intern. I sat where her secretary sits, and I handled the paperwork myself - contract by contract, signature by signature, patient by patient. I felt exactly where the process stalls, what patients don’t understand, what the front desk improvises to get a signature collected before the next appointment walks in.

SantoDoc - our e-signature product, legally valid without the certificate - came out of that chair. Built for her first. Then for everyone.

What this story is actually about

It would be tidy to say the lesson is “solve a real problem for a real person.” That’s true and useless - everyone says it.

The real lesson is narrower and harder: proximity is a method, not a phase. The dentist’s chair gave us our first product because I happened to be sitting in it. The front desk gave us our second product because I chose to sit at it, a decade later, when nothing forced me to. The accident became a discipline.

Some companies start with a pitch deck. Ours started with a broken tooth - and we’ve been going back to that office ever since.

Except we practice a more extreme version of it. We don’t just do unscalable things. Before we build anything, one of us becomes the product.

It has happened four times now. Every product, every market.

Doutore: I was the patient

In 2014, stress from a failing startup broke one of my teeth, and I ended up in my dentist’s chair while her terrible practice software failed her in the background. I asked what she paid, mocked up a replacement that night, and validated it over lunch the next day. One month later, the first version of Doutore was live in her clinic - our first paying customer. (The full story: The Dentist Who Started Two Companies.)

I didn’t interview a market segment. I was in the chair. The product question wasn’t hypothetical - it was “what does the person currently looking into my mouth actually need?”

SantoDoc: I was the intern

Eleven years later, we could see that document signing in Brazilian healthcare was broken - the standard process demands a digital certificate most patients don’t have. Instead of speccing a solution, I asked that same dentist, customer #1, to let me work her reception desk as an unpaid intern.

I handled the paperwork myself: contract by contract, patient by patient. I felt where the process stalls, what patients don’t understand, what a secretary improvises when the waiting room is filling up. SantoDoc - legally valid e-signatures without the certificate - came out of that chair, built for her first.

Dr. Assistente: I was the AI

When OpenAI released Whisper, I knew typing was the single biggest burden in our doctors’ lives, and that we finally had a shot at eliminating it. Whisper took several minutes per audio on my laptop - too slow for a product, fast enough for an experiment.

So before the product existed, I hand-picked a few doctors from our base and made them an offer: record your consultations, and I’ll return a well-structured record within 24 hours. Behind the curtain there was no product. There was me - running transcriptions on my own machine, structuring the records by hand, delivering them one by one.

The experiment famously failed - doctors didn’t want a higher-quality record tomorrow; they wanted a good record before the patient left the room - and that failure taught us that speed, not quality, was the actual product. We would never have learned that from a focus group. I learned it by being the slowest version of the product, personally disappointing real doctors.

The vet hospitals: I was the staff

When a university’s veterinary hospital became our path into a new market, I flew to a city I’d never set foot in and spent seven days inside the hospital - 7:30am to 9:30pm, every day. We discovered within hours that our product, decent for solo vets, was useless for hospitals: a hospital is not a bigger clinic, it’s a relay race between shifts and teams. We rebuilt the product live that week - me shipping quick fixes from the hospital floor, Gustavo going deep from home.

Why this works (and why almost nobody does it)

Every standard discovery tool is a proxy. Surveys are proxies. Dashboards are proxies. Personas are proxies that lie politely and in great detail. Proxies are popular because they scale - you can survey ten thousand people.

But here’s the thing about understanding: it doesn’t need to scale. It needs to be true. One founder sitting at one reception desk for one week produces more product truth than a thousand survey responses, because the reception desk can’t lie to you. You feel the stall points in your own hands.

The reason almost nobody does this isn’t that it’s hard to think of. It’s that it’s embarrassing and slow and doesn’t look like leadership. A founder at a front desk looks like a demotion. A founder manually transcribing audio at midnight looks like a failure to automate. A founder spending fourteen-hour days in a vet hospital in a small city looks like someone who can’t delegate.

It’s none of those things. It’s the cheapest, fastest, most reliable instrument ever invented for finding out what to build. The software scales just fine afterward - that part was never the problem.

The org chart says founder. The job has always been: patient, intern, AI, staff. Whatever the product needs me to be, until I understand it.

Both halves of that sentence matter. Here’s the whole story.

The setup

We’d spent a decade building Doutore, the system doctors type their records into. Ten years of watching the most highly trained people in any building spend a third of their day as data-entry clerks. If you’d asked me what our customers’ single biggest burden was, I wouldn’t have needed to think: typing.

Then OpenAI released Whisper, and for the first time the burden looked optional. I ran it on my own machine. It took several minutes to transcribe a single consultation audio. Too slow to be a product. More than fast enough to be an experiment.

The wizard of Oz

I didn’t build anything. Instead, I hand-picked a few doctors from our customer base and made them an offer: record your consultations, send me the audio, and within 24 hours you’ll receive a well-structured medical record. Better organized than anything you’d write yourself in the two minutes you have between patients.

Behind the curtain, the “product” was me. Whisper grinding away on my laptop, then me structuring the output into a proper record by hand, every evening, for every consultation. In product circles this is called a Wizard-of-Oz MVP: the user sees a product; the founder is the product.

The records I delivered were good. Genuinely good - higher quality than anything those doctors had seen, and I knew what good looked like after ten years in medical records.

The failure

They didn’t care.

Not “they complained about the delay.” Not “they asked for changes.” They were simply, politely, uninterested - in a free service, hand-crafted by a founder, delivering the best documentation of their careers. That stung. Then it taught me the most valuable product lesson I’ve ever learned.

A medical record that arrives after the patient has left the room might as well not exist. The consultation is over; the doctor’s mind has moved to the next patient; whatever they were going to remember, they’ve already half-forgotten or scribbled somewhere. The 24-hour record wasn’t a slower version of the product. It was a different, useless product.

I had validated quality. Quality was never the question. The product was speed. The record has to exist before the patient stands up - or it doesn’t count.

The rebuild

So we engineered for speed with the single-mindedness of people who had just been told the truth. Every stage of the pipeline - capture, upload, transcription, structuring, delivery - attacked for latency. The goal wasn’t “faster.” The goal was a number with physical meaning: a full consultation should become a finished, structured record in about thirty seconds, because thirty seconds is what the end of a consultation gives you - the patient gathering their things, the doctor’s hand reaching for the next file.

Same underlying model anyone can rent. Same quality bar I’d held by hand. Completely different product.

The addiction

After it got fast, the reaction changed in kind, not degree. Doctors didn’t “adopt” it - they latched onto it. The same population that had shrugged at my hand-crafted 24-hour records now couldn’t go back to typing.

One doctor put it in words I’ll never improve on. He told me - his framing, not mine - that we were handing out free cocaine: one taste and there was no way back to the old life.

What everyone building with AI gets backwards

I see teams everywhere making my 2023 mistake in 2026. They obsess over output quality - better prompts, bigger models, eval suites - while their product takes ninety seconds to do something the user needed in ten. They’re hand-delivering beautiful records 24 hours late.

Latency isn’t a performance metric. In AI products, latency decides what your product is. A 30-second scribe is a different species from a 24-hour scribe, the way a conversation is a different species from a letter.

Quality got us politely ignored. Speed got us addiction. If your AI product isn’t landing, check your latency before your prompts.

People ask what the secret is. For years I’d have said “we get along.” That’s true and tells you nothing. Watching ourselves more carefully, I can now name the actual mechanics.

We didn’t choose each other - the robots did

In college, an intro engineering course got me invited into RioBotz, the university’s combat-robotics team. I spent almost two years there, entirely unpaid, regularly working through the night without noticing - the first time in my life that effort stopped registering as effort. We became Brazilian champions, then world champions.

The real prize was a teammate named Gustavo. By the time we started a company together, we already knew precisely how the other behaves at 3am when the robot won’t work and the competition starts in the morning. You cannot interview for that. You cannot reference-check it. We never “chose” each other as co-founders; by 2013 the choice had long since been made by accumulated evidence.

▶ Anexo 03 · RioBotz best hits (video)

No ego - the entire governance model

The foundation under everything: there is no ego between us. Either of us will change his mind mid-argument, out loud, without ceremony. We both know how to say “I was wrong,” and how to apologize and mean it. Write all the partnership agreements you want; if two people can’t do those two things, no document saves them. If they can, the documents mostly never come up.

Opposite minds, used deliberately

We think very differently and - this is the useful part - we know exactly how we think differently.

He’s a better coder than I am, more analytical, and he works one way: take a single brutal problem and disappear into it until it’s solved. I’m the opposite: more creative, carrying many problems at once across products, support, and customers - broad, not deep. He does the deep dive; I do the juggling. Between the two modes, most of what a company needs is covered.

Even our tastes oppose. On UI and UX we disagree almost by default - and it’s a gift. Every design discussion gets two genuinely different starting points and, because nobody’s ego is on the table, the conversation converges somewhere better than either of us began. Two like-minded founders would just confidently share blind spots.

The rule we never wrote down

Our entire conflict-resolution system is one rule - and we never discussed it, wrote it, or even noticed it until years in. It simply emerged:

When a decision is split and we both feel strongly, the one who cares less yields. Then commits completely to the other’s direction.

No relitigating. No “I told you so” filed away for later. We’ve run this dozens of times. Amazon had to write “disagree and commit” into its leadership principles and train thousands of managers on it. Respect installed it here for free, silently, as a habit before it was ever a concept.

No titles, ever

Twelve years, three products, and we have never appointed a CEO or defined a “director” of anything. The job description has always been the same two items: talk to customers, build things. Each of us drifts to what he’s best at - but as gravity, not org chart. Titles tell people who decides; when there’s enough respect in the room, the question never comes up.

The best way to work together is not together

Here’s the discovery that surprises people most: we work better apart. The same office made us worse - when we share a room, we talk, and when we talk all day, nobody goes deep. Our entire company runs on two people going deep.

So we work remotely, on purpose, permanently. I’m a morning person; he’s a night owl - between us we cover a much longer day than any office schedule could. Deep work happens alone. And the contract that makes it safe: when one of us hits a wall, the other is one call away, always, answered in seconds.

No standups. No status meetings. No presence theater. Presence is not collaboration. Availability is.

The portable lesson

None of this transfers as a checklist - you can’t install “twenty years of accumulated evidence” by Friday. But the direction transfers: pick partners you’ve already seen at 3am; protect deep work from each other; let the one who cares more win; and spend your governance budget on respect instead of titles. It’s cheaper, and it compounds.

The detour that almost was: academia

I went to PUC-Rio at sixteen, fell into the robotics lab, and became a world champion in combat robotics with the RioBotz team (that story, and meeting Gustavo there, lives in Twenty Years, Zero Titles). I spent an exchange year at the University of California, Irvine, working in a renewable-energy lab - work that ended up published as a scientific paper on micro PEM fuel cells. I took professional courses at MIT and was sure enough about an academic career that I applied to a master’s program there.

Then I started working at a strategy consultancy - and within one week I knew I’d be happier building things in the real world than in a lab. I dropped the master’s process. Two years at Accenture followed: bank operating models, a petrochemical post-merger integration, even the strategic planning for Flamengo, my football club. Great training. Not the life I wanted. In 2012 I left to start companies with Gustavo.

Failure #1: carro.com.vc (2013)

The idea was clean: an “Airbnb for cars” in Brazil. You own a car you use one hour a day - rent it by the hour to your neighbors and cut the cost of ownership.

We even won an international business-model competition at Santa Clara University with it. A trophy, a trip to the US, validation from people who study business models for a living.

What we hit instead of a market was a wall: insurance. The entire model depends on insuring a stranger driving your car, and no Brazilian insurer offered such a product. We couldn’t build it ourselves - it wasn’t ours to build.

The four guessed emails

Four companies in the US were already doing what we wanted to do. I didn’t know them and didn’t have their emails. So I guessed - name @ company .com - and sent the same honest message four times: I’m building something similar in Brazil. I’ll be in San Francisco next week. Coffee?

All four founders replied within minutes. All four said yes. I bought the flight after the replies came in - the trip existed because the emails worked, not the other way around.

The conversations were extraordinary. People I’d only read about walked me through exactly how they’d cracked insurance: the product structure, the pricing model, the playbook, shared openly with a stranger from another hemisphere. I came home carrying two truths at once. The happy one: I now knew precisely how to guide an insurer to build this product. The fatal one: the fastest US player had taken nine months to get an insurer onboard - and we didn’t have nine months of runway.

What stays with me isn’t the startup. It’s the meta-lesson: the distance between you and almost anyone is one honest, specific email. People answer strangers who are clearly building something and clearly respect their time.

Failure #2: the ride-sharing project (2013)

If insurance was the bottleneck, maybe we could at least solve the other marketplace problem - liquidity - and have a user base ready for the day insurance arrived. So we launched a carpooling experiment for students at PUC: people with cars, people without, same campus, overlapping friends.

It went viral. Fifteen hundred sign-ups in two weeks. National television - Bom Dia Brasil, Jornal da Globo, Globo News. Rio’s city government approached us to promote carpooling city-wide; we did it unpaid (project name: Pelo Menos Duas) because all we wanted was the user base.

Then we tried to make it a business. Twice. A dynamic-carpool product for students; a corporate version for employees of big companies. Neither monetized.

We had virality, press, a city partnership, a trophy from the previous startup - and zero revenue between the two ideas.

The bottom - and why it was the beginning

By early 2014 the money was nearly gone and the situation was binary: make something people pay for, or go get jobs. I was nervous enough that the bruxism broke one of my teeth - which put me in a dentist’s chair, which is where Doutore began (that story has its own page).

But notice what we carried into that dentist’s office, because none of it was luck:

• Validation isn’t revenue. Press isn’t revenue. Virality isn’t revenue. Revenue is revenue. Two companies taught us that - one with a trophy, one with TV cameras.
• Validate willingness to pay before building. With Doutore we put a price on the mockup at lunch, before a line of code existed. The “CLARO!” came with a number attached.
• Speed is survival. The first version shipped in exactly one month, because desperation is a phenomenal product manager.
• Don’t build on a dependency you can’t control. Carro.com.vc died of someone else’s product (insurance). Doutore depends on nothing we don’t build.
• Audacity is cheap. Four guessed emails got us the playbook of an industry. We’ve never stopped sending that kind of email.

I sometimes say I thank God carro.com.vc didn’t work, and I mean it literally. We didn’t succeed despite the two failures. We succeeded because by the third try, the lessons were already paid for - and the tuition receipt was a broken tooth.

So here is what “AI inside the company” actually looks like for us, concretely - and what it looked like before AI existed, because the philosophy is twenty years older than the tools.

Coding with agents is the bare minimum

Yes, we code with AI agents - multiple agents working in parallel, every day. I want to be clear about how unimpressive that is in 2026: it’s the bare minimum. Table stakes. If “we use Copilot” is your company’s AI story, you don’t have an AI story.

The leverage isn’t in coding faster. It’s in what becomes buildable for a six-person company that was never buildable before.

Example one: the forensics of 0.2%

About 0.2% of our recordings still fail. At thousands of consultations a day, that’s not a rounding error - it’s dozens of real people, daily. And the stakes are not abstract: picture a physician in a difficult, life-changing consultation who takes no notes because he trusts our product to capture everything. If we lose that recording, “only 0.2%” is a meaningless consolation. For him, it was 100%.

So one of my actual jobs as a founder is to stay on top of every single failure - read it, understand it deeply, and personally message the affected person to explain and apologize.

What makes that possible at scale is instrumentation we built ourselves: forensic tooling that reconstructs exactly what happened on that specific device in that specific consultation - which of the forty-plus ways a recording can die actually killed this one. In the early days, one investigation could eat my afternoon. Now AI does the heavy lifting of the analysis, and I do the part that must never be automated: understanding, deciding what we fix, and facing the customer.

That’s the shape of it: AI doesn’t replace the apology. It makes the apology fast, informed, and followed by a fix.

Example two: the CRM we built in a week

We love Intercom - genuinely great software, and for years it earned its $1,000 a month from us. But our customers live on WhatsApp, because that’s where Brazilian clinics actually talk, and no off-the-shelf AI responder met the bar we hold for conversations with doctors.

The old build-vs-buy math was obvious: building a CRM takes months, so you buy the closest fit. That math is dead. I built our own CRM - WhatsApp-native, shaped exactly around how we support and sell - in one week. Not a prototype; the tool the team runs on, with a fit to our workflow no vendor could ship because no vendor knows our workflow like we do. The subscription savings are the footnote. The point is: when building costs a week, every subscription on the books becomes a question.

This philosophy predates AI by a decade

Here’s what most “AI-native company” commentary misses: the leverage was never the technology. It was the habit of automating around human attention - and we were doing it long before LLMs.

Years ago we built automation that watched how each new user actually used the product, segmented by specialty. We knew, for example, that a psychiatrist’s killer feature is controlled-substance prescriptions. So if a psychiatrist signed up, used the product for three days, and hadn’t created a controlled prescription, an email went out - personal in tone, hand-written in style, with an animated GIF showing exactly how easy the feature was. Those emails converted remarkably. The same machinery watched for usage drops and quietly checked in on important accounts.

That’s also why support never needed a department: a product that answers questions before they’re asked, plus automation that flags who needs human attention, let one full-time person (plus a backup) deliver sub-one-minute response times with 98% positive ratings. We could double the customer base without adding anyone.

Replace “hand-built email rules” with “agents and custom tooling” and it’s the same company, with a bigger lever.

The actual formula

People want the formula to be a tool list. It isn’t. The formula is:

1. Talk to customers - keep founders in the support channel, keep the WhatsApp link on every page.
2. Notice what eats human attention that a machine could carry.
3. Build exactly that - and now, with AI, “build” costs a week instead of a quarter.

AI didn’t change our method. It changed the exchange rate between attention and software. Six people was always the right size for this company. The machines just keep making six people bigger.