Author(s): Bruno Caraffa

Originally published on Towards AI.

Building Pulso: What it Actually Takes to Put Agentic AI in a Solo Practice

What we learned turning real AI capability into something a one-person clinic can really use, and afford.

Why I’m writing this

Most of what gets written about “agentic AI” lives a long way from the people it’s supposed to help. We talk about autonomous agents, orchestration, RAG, benchmarks. Meanwhile the nutritionist, the psychologist, the dentist who runs their own practice is still copying appointments into a notebook, typing up records at midnight, and answering “do you take insurance?” for the thousandth time.

Pulso started in that gap. This isn’t a pitch. It’s an honest log of the engineering and product problems we hit while turning real AI capability into something that fits the day, and the budget, of a health professional who works mostly alone. Some of these challenges we chose. Others chose us.

1. Infrastructure that grows with you: why we run on Railway

The first hard call in a new product is rarely a feature. It’s the foundation. Where this runs, how it grows, and what it costs while there’s still no revenue to justify anything fancy.

We moved off a heavier, more “enterprise” setup and onto Railway, and it was a deliberate choice. Not because it’s the cheapest or the trendiest, but because it gives us three things that matter right now:

1. Deploy by git, no ceremony. Commit, push, the environment ships itself. No one-hour pipeline to validate a copy fix.
2. Environments that actually mirror each other. We keep staging and production as sibling environments, same backend service, same Postgres, same Redis. That lets us validate in staging before touching real data, which in healthcare isn't a luxury, it's the job.
3. Predictable, modular cost. FastAPI backend, database, and cache in one place, with the freedom to pull any piece out when (and if) growth asks for it.

The word that did the heavy lifting was modular. We designed the system in layers that can be separated without rewriting the product: the messaging layer (WhatsApp through a BSP), the agent layer (the AI flows), the domain layer (journeys, records, scheduling), and the usage and billing layer. Each one can scale, get swapped, or become its own service later without dragging the rest down.

The lesson we keep coming back to: in the validation stage, the best infrastructure isn’t the one that survives a million users. It’s the one that doesn’t get in the way of learning fast, and that you won’t have to throw away once the learning turns into traction.

2. We built from a real pilot, not from guesses

This is probably the most important decision we made, and it isn’t technical.

The classic way to get product wrong is simple. You imagine a solution, bring it to the customer finished, and ask “would you want this?”. The answer is almost always “yes, love it”. And it’s almost always a polite lie. People don’t want to let you down, so they praise ideas they’ll never use. That bias has a name and a whole body of work behind it. It’s the spine of The Mom Test by Rob Fitzpatrick, and it echoes Uri Levine’s “fall in love with the problem, not the solution”. The practical rule is to stop asking whether people like your idea and start digging into the problem and what they actually do.

That’s exactly how we worked. Instead of building a bundle of features and asking if people liked it, we started from a real pilot, ran it through several validation sessions, and listened to the problem before proposing anything. Every feature came out of a concrete pain we watched happen, not a roadmap we invented in a room:

• Audio-to-record transcription. It showed up because dictating is natural for someone seeing patients all day, and typing isn’t. The professional talks the way they would in the room, and the system transcribes, structures, and organizes it.
• Help searching the literature. An agent that helps find and summarize references, because staying current competes with a packed schedule.
• A scheduling assistant that supports the front desk. Many of these practices already have a receptionist the patients know and trust, the person who gives the whole thing its human touch. We were never there to replace them. The assistant books, confirms, and reminds on its own, and it lets the receptionist handle the manual cases, like setting up recurring appointments, right inside the conversations tab. The patient gets a smoother experience and the practice gets time back.
• Hybrid AI and human control. Maybe the subtlest lesson of all. The professional has to be able to take over the conversation at any moment. The AI handles volume, the human steps in when it matters. Without that, nobody trusts it enough to let it run.

The difference is the method. We listened to the problem and brought the solution, instead of bringing a solution and asking if they’d like it. Sounds like a detail. It’s the difference between building what sells and building what fills up the repo.

3. The gap between frontier AI and what solo professionals actually have

There’s an almost absurd distance right now between what agentic AI can already do and what an independent professional actually has in their hands day to day.

Models hold a natural conversation, transcribe, summarize, structure, schedule, remind. And yet most small practices still run on a personal WhatsApp, a spreadsheet, and memory. The technology exists. The access doesn’t. It’s packaged into expensive, complex tools built for big clinics and networks, with onboarding that assumes an IT team the solo professional never had.

That’s the thesis behind Pulso, and it’s what moved us from the start: use that gap. Take real AI capability, the same kind that powers polished products today, and wrap it so a person working alone can use it on day one, in the channel they already live in (WhatsApp), at a fair price.

It was never about having the newest model. It’s about removing the friction between that model and the person who’d gain the most from it. The innovation here is as much about distribution and packaging as it is about technology.

4. Per-tenant unit economics: measure the cost of AI before you scale it

This is the least glamorous challenge and the most decisive one for any product that ships AI. Every message a model handles has a cost. Every transcription has a cost. Every agent that answers on its own is spending real money. If you don’t measure that per customer, you’re flying blind, and you find out the hard way when the bill arrives.

So per-tenant usage control wasn’t a late “nice to have”. It was foundation. We built a usage meter tied to the pricing model, and gave it a name the customer understands without thinking about tokens: Pulsos.

The trick is turning a technical cost into a unit the customer can reason about. A Pulso is that unit. Instead of tokens, message fees, and model bills, the professional buys a quota of Pulsos for the period (monthly, quarterly, or yearly), and every action draws it down by a weight that mirrors what it actually costs us:

• A reply inside the 24-hour conversation window costs 0 Pulsos. It’s the cheapest message for everyone, so we don’t charge for it.
• A utility message, a confirmation or a reminder, costs 1 Pulso.
• An outbound promotional message costs 3 Pulsos. It’s the most expensive one on every side, so it weighs the most.

The professional sees this in plain language (“info” and “outreach”, never “utility” and “marketing”) and always knows how much of the pack is left. Underneath, that exact same weight feeds our unit economics. We know the margin per plan, per customer, per type of use, and we can answer the question that kills AI startups: does this customer make money?

The message weights aren’t the whole cost, though. The single most expensive thing we run is the conversation agent, the back-and-forth that figures out what the patient wants and carries a booking all the way to a confirmed slot. It’s multi-turn by nature, and even with the right model and aggressive prompt caching, those turns add up fast. That’s the point: the most valuable feature is also one of the priciest to operate, and you have to see that cost per customer before you scale it, not after.

So there’s a second layer of cost engineering in how we use the models themselves. We route each task to the right one. A fast, cached model (Claude Haiku) handles the day-to-day patient conversations and the basic tasks. A stronger one (Claude Sonnet) takes the heavier work where quality matters more than speed: generating care journeys, importing medical records, and powering the literature agent. There’s a fallback for when something breaks. The expensive model only shows up where it earns its keep.

The lesson: in an AI product, unit economics isn’t a finance spreadsheet, it’s an architecture decision. Measure per tenant from day one and you can scale with confidence. Skip it and you scale the losses.

A few more challenges worth logging

Those four were the pillars. But some problems only surface once you put agentic AI in front of a real patient, on WhatsApp, about health. These three earn a spot in the article.

5. Safety in a clinical setting: a human in the loop, for real

When the channel is about health, and sometimes mental health, “the agent got it wrong” stops being a bug and becomes a risk. We had to build crisis-signal detection with an AI confirmation step before anything fires, specifically so we don’t trigger a crisis response on a false positive (someone filling in an “emergency contact” field at signup, for example). And there had to be an off switch: a flag that pulls that detection out of production in seconds if it ever starts doing more harm than good. Safety in a health product is less about the happy path and more about failing carefully.

6. Taming WhatsApp: the platform’s rules as an engineering constraint

WhatsApp is not a friendly API. There’s a 24-hour window for conversations, templates that need approval, automatic categorization by Meta (which decides on its own whether your message is utility or marketing), and sending limits. We went with each professional bringing their own number, activated with help from our team, and built the whole template and rate-limit layer around rules we don’t control. A good chunk of Pulso’s invisible engineering is exactly that: making a smooth experience fit inside a platform full of sharp edges.

7. The demo as a product: earning trust before you touch someone’s schedule

Here’s something we learned about distribution. You can’t scale this with a signup link, and the reason is easy to underestimate. A professional’s schedule is their professional life. Handing it over to an AI is not a casual yes. So we stopped chasing volume and put trust first. What actually works is high-touch: short, focused meetings with demos we’ve prepared in advance, backed by real test numbers, so the person feels the product working before a purchase is even on the table.

And selling AI with screenshots doesn’t work anyway. Nobody believes it until they try it. So we turned the demo itself into a product. The lead gets a code, sends it to a number, and lives the experience in their own hands: books a slot, dictates a record by voice, watches the assistant answer questions on its own. The same number serves both the demo and the real flow, with smart routing between the two. Building that was its own challenge, but it’s what makes the “oh, now I get it” land in minutes, and it’s what earns the right to touch the schedule later.

What’s next

The next challenges are already on the horizon, and they follow the same logic of catching a window while it’s open: digital signing of records and prescriptions with the Brazilian ICP-Brasil standard, deeper calendar integration, and fitting into a regulatory landscape that’s opening up to digital in healthcare. Each one is, again, the same exercise: take a capability that already exists and make it reachable for someone who works alone.

If there’s one line that sums up what we’ve learned building Pulso, it’s this. The most advanced technology in the world only becomes value when it fits into a real person’s routine, at a price they’re willing to pay. The rest is engineering to close that distance.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI