What Healthie's First Forward-Deployed Engineer Learned in 30 Days

Shimon Mazor joined Healthie 30 days ago as our first Forward-Deployed Engineer. The role is a relatively new one in enterprise software, and even newer in health tech. An engineer who sits at the boundary between the product and the customer. Close enough to close the gap between them. 

What that gap looks like is different for every industry, every company, every customer. That’s why we wanted to hear from Shimon early. Where was he finding the distance between what the platform offers and how customers are using it? What does it look like from the inside? 

The companies building on Healthie often aren't running standard clinics. They're delivering care at scale in ways that don't have a playbook yet. The care models our customers are inventing often don't have an obvious home in any existing software. These are founders and clinical operators solving structurally different problems, and there’s a gap between what they're trying to accomplish and what any platform can hand them out of the box. 

Shimon’s job is to navigate that space and shrink it. Not by building whatever a customer asks for, and not by telling them what the product already does. The work lives in between: understanding what a company is actually trying to accomplish, and finding the shortest path from there to something running in production.

We sat down with Shimon to find out what he's seen so far, including what he heard at our customer summit, where AI is delivering or falling short, and what genuine platform extensibility looks like from the inside.

Here are 12 questions we had for Shimon after his first month with Healthie.

1. Before you started, how would you have described what a forward-deployed engineer does? And how would you describe it now?

Before I started, I would have said it's an engineer who goes and watches how customers actually work. Their operations, their workflows, the places they get stuck. Then builds solutions for them that can be pulled back into the product.

That still holds. What I'd add now is the bigger half: the job is also unlocking things customers couldn't do before, or could only do by hiring an expensive dev shop. That's the piece that surprised me. A lot of what lands on my desk isn't a feature request. It's a company that has already decided to solve something outside the product, because they didn't know there was a path through it.

Our CTO & Co-Founder, Cavan Klinsky, put it more bluntly than I would have in my first week. The function exists to absorb the work customers would otherwise send to an agency. And we're specifically not an agency. We don't build their systems. We solve their problems using our system.

What I wrote down at the end of week one still reads right to me. The job isn't building whatever a customer asks for. It also isn't telling customers what the product already does. It's the space in between. Figure out what they're actually trying to accomplish, find the nearest thing the platform already has, and build the smallest thing that closes the gap.

The other thing I'd say now is that I underestimated how much of it is organizational. Before I started, I was reading about how Palantir ran this function and trying to figure out how to operate without formal  authority over anyone. I was the first person in this role  here, which meant there was no existing process for work to find me. That turned out to be the right thing to have worried about.

2. What drew you to this role at a healthcare company versus a more traditional engineering role?

I came out of running my own thing, and what I wanted was visibility into an industry with very hard, very large problems. Healthcare qualifies.

But the honest answer is that the interview process is what sold me, because of what it let me see.

The homework was to review Healthie's developer experience and come back with a take. Instead of only reading the docs and forming an opinion, I pointed agents at the platform and treated them as test users. One ran nine continuous cycles trying to build something and logging every place it got stuck. Another worked through MCP. I wanted to know what happens to someone who shows up with no context and tries to ship.

What came back was that all the ingredients were there. The API was capable, the engine was there, and there wasn't much you couldn't do. The gap was in getting from an idea and a need to an implementation, and to really taking advantage of everything Healthie has to offer. There are many different ways to build on it, and no obvious path from what a customer is trying to accomplish to the one they should pick. So most customers use a fraction of what's available to them. Closing that is the entire job I was interviewing for. Developer experience also came up unprompted in my first conversation with our CEO & Co-Founder, Erica Jain,, which told me it was already understood internally as a bottleneck.

The ambition I said out loud in my first week is still what I'm after. I want this to be where developers go to start health tech companies.

3. Had you worked with healthcare operators before? What was your prior mental model of what they needed from software?

Only tangentially. I co-founded a mental wellness VR startup, and through that I worked with psychiatrists, therapists and researchers, on both care delivery and on getting a new tool adopted.

What I took from it was that every clinician had their own workflow, their own understanding of the problem, and their own approach. Not variations on a theme. Genuinely different. Which made a cookie-cutter product impossible to build. You could give two clinicians the same tool and watch them use it for two different jobs.

4. You were at Healthie's customer conference in your second week. Forty customers, founders,and  CEOs -- what did that room teach you that a product walkthrough never could?

The morning before the conference, the team walked through who we'd be meeting. Who to engage freely, who has a very direct technical contact. What struck me in that hour was how well we know these companies. Not their account details. Their business, their constraints, what they're trying to pull off.

Then I spent three days listening to people who run care delivery companies talk about the hardest things they've had to get through.

One founder switched billing engines and a payer flagged their claims as potentially fraudulent. The payer demanded documentation on eight hundred claims a month, cited missing provider signatures and missing timestamps, and stopped paying without warning. His advice to the room was to document everything and assume nobody will warn you.

Another founder got the first prescription-only CBD pharmacy license in the country by walking into her state's board of pharmacy and asking for one. Their response was that she'd followed the practice law, so why would they say no.

A CEO said her company is doing well now, and that there were two years where a VC board would have told her to shut it down.

Licensure came up constantly. Every state is close to being another country. One founder had to physically mail a letter across the country to prove she was licensed.

The unexpected part wasn't any single story. It was the range. I went in expecting a customer conference for a scheduling and charting product, and found forty companies solving structurally different problems, several of whom had worked through existential problems that had nothing to do with software.

The most revealing hour was a workshop where attendees picked their own bottleneck and sat at that table. The five tables were scheduling friction, interoperability, patient engagement drop-off, billing, and clinical documentation burden. They chose their own pain, and I was sitting there taking notes on what I was about to work on.

I came out of those three days knowing we have amazingly creative customers, taking on some of the hardest and highest-stakes problems on the path to making healthcare better. That's the thing I'd want people to take from the summit. Not that our customers need help. That they're attempting things worth helping with.

5. What surprised you about how customers actually use the platform versus how you'd imagined?

I knew from previous experience that clinicians are all different. But when I thought about what Healthie is, an EHR with scheduling and billing and charting and telehealth, I assumed the companies would converge. Same primitives with roughly the same use, so there are only so many ways to run a clinic.

That's not what's happening. Customers are bending a traditional EHR into shapes it wasn't designed for, because they're trying to deliver care at scale in ways nobody has done yet. They're using everything in their toolbox. It's the most inspiring part of the job.

The clearest tell is what they've built alongside the product. An orthopedic clinic had already stood up their own web app and database for clinic-specific data. A pediatric behavioral health company keeps its supervisor-to-associate mapping in a spreadsheet, because that's where it fit. A therapy and psychiatry company built their collaborative care model outside the EHR, because their model required it, and is now using the API to pull it back in. None of those companies did anything wrong. They each had a model that didn't have an obvious home, so they created it.

But the more important lesson ran the other direction. The same orthopedic contact had already dismissed  two of her three use cases before I could respond. She figured she'd explore one and assumed the others probably wouldn't work. One of them was almost entirely solvable that day, using webhooks and a release-date field she didn't know existed. She was about to build something from scratch for a problem the platform already solved.

That's the pattern I look for first now. Customers tend to underestimate what's possible, and the cost shows up as work they didn't need to do. Most of the value I delivered in my first month wasn’t from building anything. It was figuring out what a customer actually needed and finding the thing that already did it.

6. Walk me through one specific thing you built and the customer need behind it.

Healthie’s Automation Builder is the clearest example of what becomes possible when you connect the dots across everything Healthie can already do.

A customer describes what they want in plain language. That goes to Claude with access to our full API schema and docs, it produces a validated workflow, and that deploys directly into the customer's account -- writing into the tasks, forms, records, and permissions that are already there, pulling from hundreds of existing capabilities and snapping them together into something that runs automatically. Every step is logged so you can see exactly what fired and why. Nine workflows are live in production. Sixteen more are in review.

What that means in practice: a care team that used to move through five manual steps to trigger a follow-up, reassign a provider, or flag a clinical threshold now has none of those clicks. The platform was already capable of all of it. The automation just removes the human in the middle.

Two builds that show the range:

The first one worked, and taught me something on the way. A customer wanted their initial health screening appointments to automatically reassign to the right primary provider when they get booked. Straightforward on paper. When I tested it, the automation failed with an error: the assigned provider didn't have access to the assigned client. That sounds like a bug, but it isn't. The platform checks provider-to-client access permissions before any automation runs, so the automation can only fire where that relationship already exists. If it doesn't, the whole thing stops. Good thing to know before a customer finds it in production. It also gave me a rule to follow on  every automation: don’t just check whether the steps are right, check  whether the permissions underneath them are.

The second one couldn't be built as asked, and that's the more interesting outcome. A ticket came in asking that when the seventy-two hour appointment reminder goes out, we check whether the client finished their intake forms, and tag them if not. Reasonable request. But the seventy-two, forty-eight and twenty-four hour reminders all emit the same event, so there's no way for an automation to know which one just fired. I put it in the backlog rather than shipping something that would fire three times and look broken.

Three weeks later part of that ticket exists as a pull request against the platform itself, adding the ability for automations to apply existing tags. The trigger side is still open. But that's the loop I care about: a customer request that couldn't be met turned into a platform capability that every customer gets, instead of a workaround for one.

The thing I'd want in the post is that the second outcome is a success. Deciding not to build is part of the job, and it's the part that produces product rather than one-offs.

7. Was there a moment where you thought "this should just exist out of the box," or the reverse?

Both, and learning to tell them apart more easily is most of what I got better at this month. Almost every instance came out of automation work, because that's where you find out fast whether the pieces you need exist.

The clearest "this should exist" came from a pediatric behavioral health customer. They wanted automation around supervisor assignment, co-signature tasks, and unsigned-note follow-ups. All of it depends on knowing which associate reports to which supervisor. You can do it with custom metadata through the API, and that works. But a native field would unlock that entire class of automation for every customer with a supervised care model, which is a lot of them. The same session surfaced a second one: automations should be able to reference a person by their role rather than by name, so that staffing changes don't mean rebuilding every automation that touches them. Both of those are now written down as product input rather than as one customer's problem. That's the loop I care about -- a request that can't be met today becomes a capability every customer gets tomorrow.

The clearest "this has to be built for them" is a call button. A customer wanted a button in the provider's chart view that dials the patient through their own phone system. One click, the operating system's protocol handler picks it up, the provider never leaves the chart. There is no version of that which ships to everyone, and that's fine. That's exactly what the widget framework is for.

The rule underneath both: the closer a request sits to core functionality, the more it belongs in the product. The more it's specific to one care model, the more it belongs in the extensibility layer. What I'm finding is that the Product Catalog is increasingly where those two things meet -- a growing library of everything our solutions and engineering teams have built over ten years, organized so any customer can find what's already possible and start building toward it. A lot of what arrives on my desk as a novel request already has an answer in the Catalog. My job is to close that distance faster.

8. Where is AI actually delivering, and where is it still mostly promise?

Where it's delivering

The clearest case is the automation product described above, and it’s live. Plain language in, a validated workflow out, deployed into a live account, every run traceable. Nine in production and sixteen in review in the space of a few months. That's a category of custom development that customers used to pay for and now configure.

The second place it's real is less of a product story and more about how I work. It's the reason I was useful before I should have been.

AI is extraordinary at getting you into a new domain. Healthcare has an enormous amount of specialized vocabulary, and billing even more so. On my third week I was on a call where a customer asked about a specific Medicare billing modifier and nobody in the room knew what it was. I found out in about thirty seconds, well enough to keep the conversation moving and know what to verify afterward. A month earlier that call would have ended in "let me get back to you."

AI is just as good at getting you into a large codebase. Healthie is a mature product with a lot of surface area, and the fastest way I've found to understand how something actually behaves is to point Claude at the repository and ask it to trace the path with file references so I can go read it myself. That's not a shortcut around learning the system. It's the thing that makes learning it possible in weeks instead of quarters. The senior engineers who taught me my first month told me it takes six to eight months to ramp here. I don't think I'm ramped. I do think I got further into the code in a month than I would have on my own in three.

And AI is good at understanding a customer. Before a call I'll pull together what a company does, how their care model works, what their public-facing product looks like, and what that probably implies about how they'd use Healthie. I show up with a hypothesis instead of a blank page, which changes what the first thirty minutes of a discovery call can accomplish.

Where it's still promise

The honest limit is that these tools are excellent at exploring and poor at knowing what they can't see. They'll give you a confident answer built from whatever was in front of them, and they won’t always tell you when that wasn’t enough. That's not a knock on any particular tool –it's the shape of the technology right now. That means the useful skill is knowing which questions have a verifiable answer and which don't.

The practical version of that: I now ask for file paths and line numbers on anything behavioral, and I treat anything without them as a lead rather than a fact. It's slower and it's effective.

Documentation is where the promise is loudest but where I'd be most careful. My manager and I landed on a distinction in my first week that I keep coming back to. Documentation has two jobs: writing and reviewing. AI is much better suited to reviewing. The risk with writing is confidence. If AI makes a hundred updates and three are wrong, someone has to catch the three, and the tool won't flag them. A weekly pass that identifies what looks stale or contradictory is a job AI can do well. Handing AI the pen is a different proposition.

It’s probably worth adding that the sharpest skepticism I heard all month came from customers, not vendors. At the summit, the terms an AI panel nominated as most overhyped were "AI" itself, "clinical AI," and "mental health" as a catch-all. They were near-unanimous that AI shouldn't deliver standalone therapy, and especially not to children who can't tell the difference. That's forty companies building with AI telling you where they think the line is.

9. Companies are trying to automate on top of messy data and infrastructure, which compounds existing problems. Does that match what you're seeing? What does messy infrastructure look like from where you sit?

It matches, though I'd frame it slightly differently. The problem usually isn't that the data is messy. It's that every part of the system is deep, and each part can be used in more than one legitimate way.

Take any single piece of what we do. Scheduling. Forms. Billing. Permissions. Each one is genuinely complex on its own, and each one has been shaped by hundreds of companies with different care models pulling it in different directions. That's what makes the platform capable. It also means that almost nothing means exactly one thing. A field, a status, a trigger, a permission: the same object supports several valid interpretations depending on how a given company works.

So when someone builds an automation, they aren't just encoding a workflow. They're encoding an interpretation. And automation is an amplifier. If the interpretation is right, you get leverage across thousands of records. If it's off by a little, you get that same leverage pointed at the wrong thing, quietly, at volume, in a system where nobody is watching each individual run.

The concrete version I ran into: a customer wanted to automatically release staff seats after a period of inactivity. A sensible goal. There are several timestamp fields on a user, and their descriptions read almost identically, but they don't mean the same thing. One of them moves whenever the record is written to, which includes routine administrative edits. Build the rule on that one and administering an account makes it look active. Nothing about the automation was badly written. The meaning underneath it wasn't what its name suggested.

That's the compounding. Not bad data, but an ambiguous meaning, multiplied.

Which is why the working rule I've landed on is that documentation tells you what something is for, and the code tells you what it does. For anything an automation depends on, you want tcode. I put that in writing in the prompts I use and it's caught something real every time.

The part I'd emphasize is that this isn't a Healthie observation, and it isn't a new-person observation. On my eleventh day I sat in an engineering retro where every team walked through the problem that had swallowed the most time that quarter. The themes were third-party integrations where vendor documentation didn't match vendor behavior, configuration that spans several levels of a hierarchy, and data shape. Every mature platform in this industry has a version of that list. The companies that do well with automation aren't the ones with clean systems. They're the ones who know where their own ambiguity lives.

10. Every EHR claims to be a flexible platform. What does genuine extensibility mean, and what's the engineering tell?

I'd start with what real extensibility looks like, because we have an unusual amount of it and it's the reason the job I have is possible.

There are five ways to extend Healthie without touching the core product. Widgets, which put purpose-built interfaces inside the provider's workflow. Authenticated frames, which let a partner render their own product inside the chart with identity passed through. Custom metadata, which lets a company store its own concepts on our records. The automation engine. And webhooks, so anything happening in the platform can drive something outside it. Those aren't roadmap items. They're how customers ship this quarter.

That's the substance. The tells are how you'd check it, and I'd frame them as questions a technical buyer should ask any vendor(us included).

Can a new developer get from idea to working implementation, and is there something that shows them how?

"We have an API" doesn't answer this. A repository that takes someone from nothing to a working workflow in an afternoon does. This is the one I care most about, because it's what I measured before I joined and it's the number that moves everything else.

Can the vendor name their extension points, and tell you where each one ends? Every platform has limits. The useful signal isn't whether limits exist, it's whether the vendor can describe them from memory. A vendor who can tell you which object types support custom metadata, and which don't, is a vendor who has thought about extensibility as a product rather than a claim.

Which extensions can your team own, and which require the vendor? This is the sharpest question on the list, and it took a sales conversation for me to say it out loud. A customer's team can eventually own automations themselves. Widgets and authenticated frames can't be self-served no matter how strong that team is because they require changes inside our own interface. That's an architectural fact rather than a policy choice, and knowing which side of the line something falls on is worth more than a promise of flexibility.

Does configuration live where you'd expect to find it? Predictability is an extensibility feature. If your engineers need a guide to know where a setting hangs off, the platform is extensible in principle and slower in practice, and that difference shows up in the timeline rather than the architecture diagram.

And when the architecture runs out, is anyone staffed to close the gap? Every platform eventually hits the edge of what configuration can do. The differentiator isn't whether that edge exists. It's whether someone is staffed to meet you there. That's the function I'm in.

11. When you talk to a customer's CTO or technical lead, what's the question they're actually asking (that they don't always say out loud)?

“How can I trust you to remove this problem in a way that's scalable and affordable, so I can get back to what I actually need to be doing.”

Every word of that is doing work. "Trust you" is about whether the answer holds up in three months. "Scalable" is whether the fix survives their next state expansion. "Affordable" is real, because the alternative they're pricing against is a dev shop. And "get back to what I actually need to do" is the point. Nobody's technical lead wants to become an expert in our data model. They want to stop thinking about us.

The best version of this I heard came from a technical lead at a customer we're scoping now. He didn't ask for documentation. He asked for playbooks for engineering teams, and said his engineers don't yet know everything Healthie already does. Then he asked us to be candid about constraints and tradeoffs. That's the same question. Tell me the shape of the boundary so I can plan around it instead of discovering it.

I heard the commercial version from one of our own account executives, and she asked it better than anyone. She didn't ask what my function costs. She asked when it isn't worth bringing up with a customer. She wanted a qualifying gate. Same instinct: give me the edge of the thing so I can work confidently inside it.

12. Thirty days in, what are you most looking forward to building in the next thirty?

Three things, in order.

1. Automate Builder goes generally available soon, and I'll be leading customer enablement from there. The part I'm most excited about: work that used to require a custom build becomes something a customer's own team configures and owns. That's the direction I want to keep pushing -- building the thing that expands what customers can do themselves.
2. Second, widgets. The gap between a capability a clinical team has access to and one they actually use in practice is significant. A widget closes it -- purpose-built, embedded directly in the provider's workflow at the moment it's needed. I built one this month that connects a provider's chart view to a customer's own phone system in a single click. I want to see how quickly we can get from "here's what we need" to something like that running in production.
3. Third, Visualize+ This is the one I'm most excited about on the customer's behalf. A lot of what companies ask us for turns out to be a question about their own operation. Where are patients dropping off? Which providers have capacity? What's happening to claims? Right now, answering that means someone pulling data and building a view. Giving customers that directly, with alerting on top of it, unlocks a whole category of information for decisions they currently make on instinct or a month late. It also opens the door to the thing after that, which is purpose-built agents working on a customer's behalf inside their own data.

Our customers are trying to do genuinely hard things: deliver care at scale, make the economics work, reach people who aren't currently reachable. They're inventive and they're operating with real stakes. My job is to shorten the distance between what they're trying to accomplish and something running in production. That's a good problem to spend the next thirty days on, and the next thirty after that.