DEV Community: Chad Dyar

The Two Numbers That Beat Hiring a Consultant

Chad Dyar — Wed, 30 Sep 2026 18:43:23 +0000

My first coaching program took six weeks to build and about six minutes to fail. I had the research, the thought leadership decks, every edge case mapped. I walked it into a room of frontline managers and watched their faces do the thing faces do when they have already decided something is a waste of their Tuesday.

So I did the only thing left. I found the loudest people in the room, the ones who hated it most, and asked them what they actually did all day, what got in their way, and what they wished existed instead. Then I threw out everything I had built and started over from their answers. Six months later that same group had a coaching culture they were proud of, one they had built more than I had.

The part of that story that never makes it onto a slide: the fix was not a better framework. It was fewer of my ideas and more of theirs. I built one rule out of that failure that mattered more than the rest: five questions before one piece of feedback. Managers hated it at first. It felt slow. Then their reps started solving their own problems instead of waiting to be told the answer, and the managers stopped needing to be in every deal.

There is a version of that same lesson I learned later, watching who actually improves fastest in any sales org. It is never the top performers, who are already fine, and rarely the bottom, who need something structural. It is the middle sixty percent: the people who show up, do the work, want to be better, and have never had a system built for how they actually learn. Most coaching programs get designed for the extremes and hope the middle absorbs whatever is left. I stopped doing that.

I spent twenty years running coaching infrastructure inside sales organizations, and the two numbers that came out of it are the ones I will actually stand behind in public. A 34% lift in quota attainment for SVS certified reps. A 40% cut in ramp time for the Commercial and SMB segment, six months down to under four. Both numbers carry their qualifiers on purpose. The 34% is specific to that one certified methodology. The 40% is specific to that one segment. Enterprise ramp runs a longer, separate curve, and I am not going to blend the two just because a bigger number reads better on a landing page.

Here is what actually pushed me to build a product instead of just writing about this. Every organization that wanted those results had two options, and both ran through me or someone like me. Hire a consultant to design the program, or hire a coach to run it, and either way you are paying for access to a person's calendar, not just their method. I watched good programs die the moment the consultant's contract ended, because nobody on the inside had ever been taught to run the machine themselves.

The Coaching Operating System is what I built instead: a twelve week self serve kit for a sales organization to build that same coaching infrastructure with its own people, the 5:1 rule included, without ever getting on a call with me. Twelve weeks roughly matches the time it took my own first program to go from a room full of skeptical managers to a coaching culture people were proud of, packaged now as a sequence a team can run themselves instead of living through the version where I learned it by failing first. The constraint I designed against, stated plainly: if a marketing idea for this thing creates an email, a meeting, or a manual step on my end, it is the wrong idea for the product.

I will say the plain thing here instead of dressing it up. There are no customers yet. No case studies, no testimonials, nothing to point at besides the two coaching build numbers above and the method itself (the founding counter on the sales page is still ticking down, which tells you exactly how early this is). The kit launched at $1,497, with a founding price of $997 for the first fifty people while that counter runs. Proof arrives when buyers do, and I would rather tell you that straight than invent something to fill the gap until it does.

What I would do differently, looking back at that first failed program: skip the six weeks of research entirely and spend day one asking the room what they wished existed. It would have gotten me to the same six month result in about six days.

If you run coaching for a sales team and want to see where your own program is thin, the free Coaching Score assessment walks it across six dimensions in about four minutes: score.chadtdyar.com

The Same Bad Week, Told Through a Different App

Chad Dyar — Tue, 29 Sep 2026 18:59:12 +0000

Maya needed stitches. Wick had a cough that would not clear. Benny had a grooming appointment I had booked weeks earlier and forgot about until the reminder text landed the morning of. All three, the same week. I had nothing written down for any of them: no weight history, no med schedule, no note about which vet said what. I was reconstructing my own dogs' health from memory in three different waiting rooms in five days.

I have written about that same week before, for a different app, in the context of tracking Benny's medication schedule specifically. This is the other half of it. Medication is one column in a much bigger sheet. The bigger sheet is everything else: how much Wick has been eating, whether Maya's energy dropped before anyone noticed a limp, whether Benny's weight is drifting in a direction that matters before it becomes a vet visit instead of a food adjustment.

That is what Pawformance tracks, and it is the app I built out of that same bad week: activity, food, weight, general wellness, over time, for all three dogs, in one place I can actually open in a waiting room instead of trying to remember it out loud.

Three dogs changes the math on this in a way one dog never would have taught me. With one dog, you can hold most of it in your head, because there is only one appetite, one energy level, one set of quirks to track against. With three, Wick, Maya, and Benny each have a separate baseline, and a change in any one of them only reads as a change if you know what normal looked like for that specific dog a month ago, not what normal looks like for the other two. A single shared notebook page does not scale to that. A single app screen per dog, checked in thirty seconds each, does.

The objections I hear are all reasonable, so I will take them straight. My vet's portal already stores records: it stores what the vet recorded, not what I noticed on a Tuesday that never became a visit. My dog is healthy, I do not need to track anything: that was true of Wick's cough for about four days too, until it was not. 11pets and PetDesk are free: they are, and neither one is built around the day to day pattern noticing that catches a problem before it is a problem. I would forget to log things after the first week: that is the actual risk, and it is the one I designed the app to fight by making the log take seconds, not minutes. I do not want another subscription just for my dog: fair, which is why the core tracking is free, and the $6.99/mo Pro tier only matters once you want the deeper history and trend view.

What I would do differently, if I were starting over: build the three dog profiles and the shared household view before anything else, instead of after. I built Pawformance the way most solo builders build things, one dog's data model first, then realized a real household has more than one animal and more than one person checking in on them, and went back to rebuild the foundation. Faster to design for the actual waiting room from day one than to retrofit it in later.

The free tier does the daily job on its own: log activity, food, and weight, no cap on how many entries or how far back you look at that level. The $6.99/mo Pro tier is for the moment the vet asks a question that needs history, not just a snapshot: unlimited dogs instead of one, health trends going back months instead of the last entry you happened to remember to make, and a vet prep report you can hand over or export instead of narrating it from memory in the exam room. That last one is the exact moment that started this whole thing: standing in a waiting room with three separate stories in my head and nothing to hand anyone that proved any of them.

I did not build the vet prep report as a feature to round out a pricing tier. I built it because I was the guy verbally reconstructing a cough timeline for a vet tech while she waited, and a printed page would have taken thirty seconds instead of the two minutes I actually spent second guessing my own memory.

Wick's cough is the clearest example of why the "my dog is healthy" objection does not hold up under its own weight. He seemed fine for days. The cough was there before it was a symptom worth calling anyone about, and the only reason I caught the pattern at all was noticing it again on day three, not day one. A tool that only matters once something is already wrong misses the entire window where catching it early is still cheap and easy. That window is short, and it closes quietly.

Track your dog's health like a vet does, free: pawformance.app

The gap is momentum, not knowledge

Chad Dyar — Tue, 22 Sep 2026 17:49:47 +0000

I've worked out since I was fifteen. Gymnastics first, then weights, then whatever kept me moving through opera training and twenty years of a career that had me on planes more than I was home. Thirty five years of showing up, on and off, and at fifty I am busier and more tired than I was at twenty five. Not less motivated. Busier.

That distinction sat with me for months before I built anything. I kept hearing it from my own gym friends, the ones who show up at 6am three times a week and the ones who show up once a month and feel guilty about the other three weeks. I asked around, half research and half therapy. Every single person said some version of the same sentence: it's not like college anymore. Nobody needed a class on macros. Nobody needed convincing that consistency works. What they needed was something that closed the gap between knowing and doing, on a Tuesday night when the couch was right there and the gym was not.

So the app doesn't coach, and it doesn't add another dashboard telling you what you already know. Momentum tracks one thing: did you show up. Streaks, not scores. A habit log that doesn't punish you for missing a day, because the punishment is usually what kills the habit by week three.

What I got wrong the first time

The first build had a full nutrition module: macro targets, a food database, barcode scanning, the works. I built it because every fitness app has one and I assumed users would expect it. Three weeks after launch, usage told a different story. People opened Momentum to log a workout and closed it the second the app asked them to also log breakfast. The nutrition module wasn't wrong on its own. It was wrong for what this app was trying to be, which is a consistency tool, not a tracking tool. I pulled it in the second version, and usage of the core habit log went up.

What actually moved the needle

Two things, both smaller than I expected. The first was the streak visual itself: a simple chain that breaks visibly when you miss a day instead of quietly resetting a number somewhere you can't see it happen. People told me the visible break bothered them in a good way. It made missing a day feel like a small thing to notice, not a private failure to hide from. The second was AI food scanning, added later and against my own instinct that it would be a gimmick nobody used. It isn't a nutrition coach. It's a five second log instead of a fifteen minute one, and that friction difference is the whole reason people actually use it on a Thursday when they're tired.

The objection I hear the most

Free apps always get worse or disappear. I hear it constantly, and it's a fair thing to worry about, because a lot of apps in this space got bought, bloated with ads, or shut down entirely. I don't have an answer that erases that history. What I have is a different structure: one person, accountable, building a tool for a problem he actually has, not a growth number he's trying to hit before an acquisition. That's not a promise. It's just a different set of incentives, and I think it shows in what the app chooses not to do.

What I would do differently

I would have shipped the stripped down version first. Building the full nutrition module before I had real usage data cost me weeks I didn't need to spend, and the lesson generalizes past fitness apps: build the smallest thing that tests the actual belief, which in my case was that the gap is momentum, not knowledge, and let real people using it tell you what to add next. I had the belief right from the start. I just built around it before I tested it.

The gap I kept hearing about was never knowledge. It was momentum. That's the whole app, and it starts free.

Showing up at 50 is a different problem than showing up at 25

Chad Dyar — Tue, 15 Sep 2026 13:57:28 +0000

I have worked out since I was 15. At 50, I'm busier and more tired than I've ever been, and not one bit less motivated. That gap between wanting to show up and actually showing up is the entire reason Momentum exists.

The gap isn't knowledge

Here's what I kept hearing when I talked to my gym friends while I was building this: nobody was confused about what to do. Everybody in that conversation had read the articles, knew the macros, could tell you the difference between progressive overload and just moving weight around. The gap wasn't knowledge. It was momentum, the actual mechanical act of doing the thing again tomorrow after you did it today.

Every single person said some version of the same sentence: it's not like college anymore. Nobody's handing you a schedule. Nobody's waiting on you at the field house. You're building the whole structure yourself, at the exact age when your calendar has the least room in it, and the apps built for 23-year-olds chasing a six-pack weren't built for that problem.

What I actually built

Momentum tracks workouts and streaks, and that's close to the whole feature list on purpose. I didn't want a dashboard full of numbers nobody checks. I wanted the one number that actually predicts whether you keep going: did you show up again. The app logs consistency the way you'd log it in a notebook if you were disciplined enough to keep one, except it remembers for you and it doesn't judge you for the week you missed.

There's a food-scanning feature in there too, and I want to be straight about what it is and isn't. It gives you a fast estimate, not a lab-grade nutrition report. If you're chasing exact macros down to the gram for a competition, this isn't that tool. If you want a quick read on whether today's plate was in the neighborhood of what you're after, it does that job well. I built it to lower the friction of logging, not to replace a dietitian.

The build choices that mattered

I kept the tech stack boring on purpose. This is a habit tool, and a habit tool that's slow to open or breaks on a Tuesday teaches you to stop opening it, which is the exact failure mode the whole app exists to prevent. Every design decision got run through one question: does this make it more likely someone opens the app tomorrow, or does it just make the app look more impressive in a screenshot. Streak tracking won that argument every time over a fancier analytics view.

The free tier isn't a trial that expires and starts nagging you. It's built to actually work for someone who just wants to track streaks and nothing else, because the whole premise of the app falls apart if I'm the one adding friction back in through a paywall three weeks after someone commits to the habit.

The schedule problem I kept designing around

A 50-year-old's schedule doesn't hold still the way a college kid's does. My gym friends aren't training at the same hour every day, and neither am I most weeks. Every design conversation I had while building this kept circling back to the same constraint: whatever the app asked of someone had to survive a calendar that changes week to week, not just a calendar that's merely full. A habit tool that assumes a fixed routine is building for the person who least needs the help. The person who needs it is the one whose Tuesday and Thursday don't look anything alike.

Where I compare it to what's already out there

MyFitnessPal is the obvious comparison, and it's a good tool for a different job. It's built for optimization: precise logging, a huge food database, the kind of detail someone training for a specific number wants. Momentum is built for consistency. The people I talked to who'd tried MyFitnessPal and quit weren't quitting because the app failed them technically. They were quitting because the app was asking them to optimize something they hadn't shown up for reliably yet. You don't need a better spreadsheet at week two. You need a reason to open the app at week two.

What I'd do differently

If I rebuilt this from scratch today, I'd delay the food-scanning feature by a few months and ship pure streak tracking first, then watch what people actually asked for before adding anything else. I built the scanning feature because I assumed people would want it immediately, and some do, but I'd rather have spent that early time hardening the one feature the whole app depends on: the daily check-in has to be fast enough that opening the app is never the hard part. The workout is the hard part. The app should never be.

Free to start, no credit card, and it's built for the person who already knows what to do and just needs the structure that makes doing it again tomorrow easier than not doing it.

The paywall, the vet waiting room, and the free tier I capped on purpose

Chad Dyar — Wed, 09 Sep 2026 17:26:10 +0000

Maya needed stitches. Wick had a cough. Benny had a grooming appointment. All in the same week, and I had nothing written down for any of them. Three dogs, three sets of instructions living in my head, and a vet tech asking me when the cough started while I scrolled my camera roll looking for clues.

A few weeks later I was in a vet waiting room with my mom's elderly dog and had no health history to show anyone. Two versions of the same failure in one month. That is usually when I build something.

What I built

CareCadence is a medication tracker and adherence tool. The human version came out of the same moment as the dog version of the problem: adults managing their own prescriptions, and caregivers managing meds for aging parents who cannot always answer "what is she taking and when did it change" from memory in a hallway.

It is a small web app. Reminders, dose logging, a med list a caregiver can actually read, and a prep sheet you can hand a doctor instead of performing the memory test again. Unglamorous software. The category does not need glamour. It needs to work on the worst day of your month.

The hallway moment is the one I kept designing for. Somebody's adult daughter standing outside an exam room, being asked what her father takes and when the dosage changed, holding a phone full of photos of pill bottles taken at different kitchen tables over two years. She does not need a wellness score or a streak animation. She needs the list, dated, readable, in her hand before the doctor stops waiting for the answer.

Then January happened

In January 2026, Medisafe, the biggest name in this category, moved core tracking behind a $10 a month paywall with a free limit of two medications. If you have ever watched a category leader reprice, you know what came next: a wave of people looking for somewhere to go, many of them retirees on more than two medications, exactly the people a two-med free limit squeezes hardest.

Suddenly my little app born out of a bad month in vet waiting rooms had a market event pointed straight at it.

The sentence I refused to ship

Here is where this becomes a build story about marketing instead of code.

The obvious move was to plant a flag that said "the free unlimited alternative." It writes itself. It would have converted. And it would have been false, because CareCadence's free tier caps at three medications. The paid tiers exist because interaction checking and caregiver sharing cost real money to run, and I would rather charge for those than quietly degrade the free product later, which is the move I just watched a competitor's users get burned by.

So the framing rule became: say the cap out loud, every time. Free tier, real and useful, three medications. If you are managing more than that, you are the paying customer, and the price is on the page. A capped free tier stated plainly beats an unlimited one with an asterisk growing inside it.

My own automated content system flagged this the hard way. A queued post about CareCadence went out for review with a "stayed free" angle, and it got killed in editorial for exactly the reason above (the free tier has a cap, and my own pricing page says so). When your marketing pipeline can contradict your checkout page, one of them is lying. Fixing the copy is cheaper than fixing the trust.

The 500 that was actually 19

One more confession, because Dev.to is where I keep the receipts. In August I audited the app's marketing surfaces against production data. A checklist page claimed "Used by 500+ patients and caregivers." The actual user count in the database that morning was 19.

The claim was aspirational boilerplate that slipped in during an early build pass and never got challenged. It came down the same day. The functional description stayed, because the feature is real even when the crowd is small. Nineteen people tracking their meds deserve a page that tells them the truth.

Treat marketing claims like assertions. Run them against production. A claim you cannot back with a query is a bug, and it will ship itself if you let it.

What I would do differently

Write the pricing page before the landing page. Every dishonest sentence I almost shipped came from writing the exciting copy first and reconciling it with the actual product later.

Put the free-tier cap in the first screenful, on purpose. The users who leave when they read "three medications free" were never going to pay, and the ones who stay convert calmer, because nobody feels ambushed at the paywall.

And audit copy against the database on a schedule, the same way you run tests. My user counter and my marketing page disagreed by a factor of 26. The database was not embarrassed. The page should have been.

Why I stopped scoring performance and started asking about it

Chad Dyar — Sat, 05 Sep 2026 22:44:37 +0000

Twenty years running sales enablement programs taught me that performance reviews miss the person almost every time. I wrote Performance Is Personal after watching one more coaching framework skip the part where someone actually has to change, not just get scored. The book walks through what real behavior change looks like in practice, with the awkward middle included. If you manage people, or you are the one being managed, the ideas here might save you a few bad quarters. The awkward middle is where the work actually happens.

HomeGrown vs Gardenize comparison page

Chad Dyar — Sat, 05 Sep 2026 22:44:33 +0000

Gardenize tracks what you planted and where it needs care. HomeGrown starts from what's actually ripe in your garden right now and turns it into a recipe you can cook tonight. Different halves of the same problem. One is a planner, the other is a cook. I built HomeGrown because I kept staring at tomatoes on my counter wondering what to do with them before they went bad. The app tells you what to make with what you have, not what you should have planted six months ago. Full comparison: thehomegrown.app/gardenize-alternative

How to Talk to Humans

Chad Dyar — Thu, 27 Aug 2026 23:22:31 +0000

Why Your Best Code Won't Matter If You Can't Explain It

I spent two years watching brilliant engineers tank career conversations. Not because they weren't smart. Because they tried to translate their intelligence directly into words, and somewhere between their brain and the other person's ear, everything got scrambled.

One of them built a system that cut database query time by 68%. He got into a room with a non-technical stakeholder to pitch for resources. Thirty seconds in, he was deep in indexing strategy. The stakeholder checked out. The project didn't get funded.

Here's what happened: he was speaking to someone else's context, not the person in front of him.

The gap between knowing something and being able to explain it to a human who doesn't share your frame of reference is not a soft skill. It's a hard constraint on how far your work travels. It affects whether your ideas get adopted. Whether you get promoted. Whether you can influence decisions that matter. Whether anyone actually understands what you built and why it matters.

Most engineers I've worked with treat communication like a tax on "real work." You finish the thing, then you have to go explain it to people who don't get it. Tolerate their questions. Try not to be frustrated that they need it spelled out.

That's backward.

Explaining something to someone who doesn't speak your language is a skill. A learnable one. Not something you're born with or not. It's not about dumbing anything down. It's about meeting someone in their world first, building a shared understanding, then moving together toward the technical reality.

The difference between a mediocre explanation and one that sticks is usually this: you stopped assuming what the other person knows, and you started assuming what they care about. You built a bridge from their problem to your solution instead of just describing the solution and hoping they could figure out the bridge on their own.

I wrote "How to Talk to Humans" because I kept seeing the same pattern across teams. Engineers who could architect systems that scale to millions of requests, but couldn't articulate to their manager why that architecture mattered. Product people who understood the feature but couldn't explain it to customers in a way that made sense. Leaders who had the right strategy but couldn't bring people along because the words didn't land.

The book is built on one core idea: communication is not decoration on top of competence. It's a tool that makes your competence visible, transferable, and valuable to other people. And like any tool, it has techniques.

The chapters walk through real scenarios. How to explain something technical to someone non-technical without losing precision. How to listen for what someone actually needs to hear, not what you think they should know. How to move a conversation from confusion to clarity without sounding like you're simplifying. How to know when you're speaking and when you should shut up and listen.

None of this is theory. It's all grounded in conversations that actually happened, mistakes I watched happen, and what changed when people started thinking about communication the way they think about code: as a problem to solve, with constraints, patterns, and things that work better than other things.

If you've ever felt like your work didn't get the credit it deserved, or you watched someone less capable than you move up because they communicated better, or you've been in a room where everyone nodded but nobody understood what you said, this book is for you.

You already know how to solve hard problems. This teaches you how to make sure other people understand the solution.

"How to Talk to Humans" is available now on Amazon. https://www.chadtdyar.com/books/how-to-talk-to-humans?utm_source=devto&utm_medium=community&utm_campaign=devto-20260827-howtotalktohuma

A sales agent lied to my database, and the test caught it before a buyer did

Chad Dyar — Wed, 19 Aug 2026 16:58:33 +0000

I run two sales agents in production now. InboxCopilot reads inbound email and qualifies leads. EnrichmentMessenger takes a CSV of prospects and writes first-touch messaging for the ones worth touching. Both of them write to the same attribution schema, a Postgres setup where every agent action logs as a touchpoint and gets a capped share of revenue credit when a deal closes.

Before either agent touched a real inbox or a real CSV, I ran them cold. Skill file verbatim as the system prompt, JSON Schema output contract, AJV validation on every response, zero retries, zero coaching. If the model can't follow its own instructions on the first try, the instructions are wrong, not the model.

InboxCopilot went 3 for 3. EnrichmentMessenger went 2 for 3.

Row 2 of the EnrichmentMessenger test was a prospect with no usable information. Not enough to enrich, not enough to message. The agent's job in that case is simple: skip it, log nothing, move on. Instead it returned a disposition of created, an empty enrichment payload, and a null message. That disposition is supposed to mean "this became a real sourced lead." Nothing about that row earned it. If that output had reached the database unexamined, it would have written a lead_created touchpoint for a lead that didn't exist in any meaningful sense, a phantom lead with a live attribution record.

Sourced pipeline is this product's cleanest number. It's the one metric that doesn't need a cohort comparison or a minimum sample size to mean something. A single phantom row poisons it quietly, because nothing about a bad created disposition looks wrong from the outside. The row exists. The lead exists. The number is just wrong.

I went in expecting a model failure. It wasn't. The skill file's disposition logic had a step-order conflict: a match-first read let the model assign created before the no-basis check ever ran. Given a row with almost nothing to work with, the instructions let the agent find something plausible to say instead of forcing it to say nothing. That's not a hallucination. That's a skill file that let ambiguity resolve toward action instead of toward silence.

The fix was to rewrite the whole disposition decision as one ordered tree with the no-basis check first, not as a set of conditions the model picks through in whatever order looks convenient. Ambiguity now resolves toward skipped_no_basis by default, with zero touchpoints attached, and only escalates toward a real disposition when the row actually earns it.

Re-run cold: EnrichmentMessenger 3 for 3, the same row now correctly skipped. InboxCopilot unchanged at 3 for 3. Six for six combined, no regression.

The schema carries a hard 50% cap on AI attribution credit regardless of how many touchpoints a deal accumulates, so a defect like this couldn't have inflated any single deal's number past that ceiling. But it could have created deals, and pipeline that was never real is worse than a capped number that's honest. The production assertion suite for the schema now runs 21 checks, all passing, and the ordered-tree pattern from this fix is the one I use for every disposition decision I write now, in this project and outside it.

If you want the receipts: schema and views at commit a231d16, the repo reaching shippable v1 shape at af7ec15, and the docs made fully accurate to the shipped code at 5d58f51.

No traction numbers here, because there aren't any yet. The kit launched with no case studies, and the plan was always to let the attribution data speak for itself once it exists. What I can show you today is that the test caught its own worst mistake before a real prospect ever touched it. If the "what can this actually claim" question interests you more than the pitch does, the methodology behind it is at stack.chadtdyar.com/deep-dive.

A cold run caught a bug in my own attribution layer. Here's what broke and how I fixed it.

Chad Dyar — Wed, 19 Aug 2026 14:23:29 +0000

I built two AI sales agents that share one attribution layer, and before I let either of them touch a real inbox, I ran them cold against a test dataset built specifically to catch the failure mode I was most worried about, the one I'd have been embarrassed to find after launch instead of before it.

The Agentic GTM Stack is InboxCopilot and EnrichmentMessenger, one shared attribution layer underneath both. Every action either agent takes gets logged as a touchpoint tied to a lead, and every touchpoint gets a capped, conservative slice of revenue credit: 50 percent ceiling, hard cap, written into the schema itself so no code path can quietly raise it later. The schema is plumbing. The reason the plumbing exists is the actual product. I did not want to ship an agent that could claim credit for something it did not do.

So the cold run was testing something narrower than whether the agents worked. It was testing whether the attribution layer would catch them when they didn't.

InboxCopilot passed clean, 3 for 3. EnrichmentMessenger did not. First pass came back 2 out of 3, and the failure was the kind I'd been dreading since I started writing the schema: a lead with no real work product behind it (null message, empty enrichment, nothing an agent had actually done) still got a disposition of created. That disposition is the one that emits a touchpoint. A phantom-sourced lead, credited like a real one.

Finding the actual defect

My first assumption was a model problem, the agent hallucinating a result it never produced. That would have been the easy story to tell and the wrong one. The real cause was step order.

EnrichmentMessenger's disposition logic ran a match-first read: check whether the incoming record matched an existing pattern, assign a disposition based on that match, and only after assigning it, check whether there was any actual basis for the match at all. On the lead that failed, the match-first branch fired, assigned created, and the no-basis check that should have caught the empty enrichment never got a chance to run, because by the time it would have executed, the disposition was already written.

It is a boring bug in the sense that boring bugs are the ones that actually ship. Nothing exotic. Just a conditional that checked things in the wrong order, in the one part of the system where order was the whole point.

The fix

Version 1.1 rewrote the disposition decision as a single ordered tree instead of a set of independent checks, with the no-basis check running first, before anything else gets evaluated. If there is no real basis for the lead (no message, no enrichment, nothing to point to), the disposition resolves to skipped_no_basis and the touchpoint never gets written. Zero credit, because there was nothing to credit.

Re-verification: EnrichmentMessenger 3 for 3. The exact record that failed the first pass now resolves correctly: skipped_no_basis, zero touchpoints. Combined across both agents, 6 for 6, no regression on InboxCopilot. The production substrate's full assertion suite runs 21 for 21.

What I'd do differently

I would have written the no-basis check first the first time, obviously, if I'd seen the failure mode coming. What I'd actually change is earlier than that. I'd design every disposition path as an ordered tree from the start instead of a set of independent checks that happen to run in whatever order the code lists them. Independent checks feel modular while you're writing them. They stop being modular the moment one of the things you're checking is "did anything real happen here," because that question has to come before every other question, every time, or it doesn't mean anything. Attribution systems earn trust in exactly one direction, and a single phantom credit on day one would have spent all of it.

The commits, if you want to look: af7ec15 for the point the repo reached shippable v1 shape, 5d58f51 for the Phase 4 close where the docs finally matched what the code actually did.

What's not in this post

You will find no traction numbers, revenue numbers, or customer counts here, because none exist yet. The Agentic GTM Stack launched without a single case study, on purpose, because the entire pitch is that it does not claim credit it cannot back up, and the fastest way to violate that on day one would have been to publish a made-up "early results" number. The first proof this product gets to point to is its own attribution data, running live on a public dashboard, filling in as real usage happens instead of being backfilled to look good on launch day.

If you want the deeper technical writeup on how the attribution layer itself is structured, that lives at stack.chadtdyar.com/deep-dive. The kit itself is at stack.chadtdyar.com, one-time purchase, self-deploy.

Why I Built a Free Medication Tracker When Medisafe Already Exists

Chad Dyar — Wed, 19 Aug 2026 14:23:13 +0000

Maya needed stitches. Wick had a cough. Benny had a grooming appointment. Same week. When the vet asked me when Maya's last vaccine was, I stood there scrolling through two years of phone photos, trying to date a bandage. Three dogs, three appointments, and nothing written down for any of them.

A few weeks later I was in a different waiting room with my mom's elderly dog, and the same scene played out with higher stakes. A new vet, a dog the family had loved for years, and no health history to hand anyone. The whole medical record lived in my mom's memory, and my mom was stressed enough that her memory was not cooperating.

That waiting room is where CareCadence stopped being a note I kept meaning to write and started being a build. Because the scene repeats everywhere, and the human version is worse. An adult child sits in an ER intake chair and gets asked what medications their father takes, at what doses, since when. The answer exists. It is in a kitchen drawer two towns away, in handwriting nobody can read under fluorescent lights at 2 a.m. The version of CareCadence for people caring for aging parents came from that same moment, and that version is the real product.

The market already had a winner, sort of

Medication apps are not a new idea. Medisafe is the one everyone recommends, and it earned that. But the free tier caps you at two medications, and past that cap you are paying about ten dollars a month. Two medications is a rounding error for the people who need tracking most. The average person managing an aging parent's care is juggling far more than two, across multiple doctors, with schedules that change after every appointment.

I kept turning that over while I built. A caregiver in the middle of the hardest logistics of their life reaches for the standard tool and hits a paywall on the list itself. The list is the whole point. Charging for the list is charging for the exact thing people are panicking about.

What free means here

CareCadence tracks unlimited medications on the free tier. Doses, schedules, adherence, the history a doctor actually wants to see when they ask "how long has he been on this?" There are paid tiers, Plus at $4.99 a month and Family at $9.99, and they exist for households that need more than the core, but the core never gets ransomed. The tracking is the product, so the tracking stays free.

That decision is bad revenue math on a spreadsheet and correct everywhere else. I did not build this app to arbitrage a competitor's pricing mistake. I built it because I have stood in that waiting room twice, and the second time it was not even my dog.

The build itself

The stack is the same one I use across all seven of my apps: Lovable on the front end, Supabase underneath, Capacitor to get it onto phones. Boring on purpose. A solo founder shipping a health-adjacent app does not get to spend novelty points on infrastructure, because every point spent there comes out of the reliability budget, and a med reminder that fires late is not a bug, it is the failure of the entire premise.

The hard part was never the database schema. Medications are just rows. The hard part was designing for two users at once: the person taking the medication and the person worrying about the person taking the medication. Those two people need different things from the same data. One needs a nudge at 8 a.m. that does not feel like a nag. The other needs to answer a doctor's question from two towns away without making a phone call that starts an argument. Most tracking apps pick one of those users and quietly abandon the other. The waiting room taught me you are usually both at different points in your life (sometimes in the same year).

What I would do differently

I would have started from the caregiver. The dogs got me building, and the origin story is true, but the person this product actually serves is the one holding a parent's med list in an intake chair. It took me longer than it should have to see that the "for people" version was not the spinoff. It was the destination.

I would also name that audience earlier in the marketing. "Medication tracker" describes the database. "The med list your family can actually find in an emergency" describes the product. I am still learning to write the second sentence first.

If someone in your life takes more than two prescriptions, the free tier is the whole pitch: carecadence.app. Never miss a dose, start free.

Eight days after launch: zero purchases, and what I am changing

Chad Dyar — Tue, 18 Aug 2026 14:23:04 +0000

I shipped a self-serve product two Mondays ago. Sales page tested clean on two devices. Checkout works. Monitoring is quiet. Eight days later: zero people have finished the free assessment that is supposed to be the front door, and zero purchases.

That is not a soft launch story with a happy ending yet. It might still turn into one. The honest version of this post is the one where I tell you what I actually know eight days in, not the one where I dress a flat line up as a slow build.

What the product is

A twelve week self-serve kit for sales orgs that want to build coaching infrastructure with their own people, no consultant, no calls with me, ever, by design. The whole point is that it works whether I am paying attention to it or not, which shaped the marketing too: it cannot rely on me showing up either.

What I instrumented, and what I did not

PostHog tracks every step of the assessment: started, completed, email submitted, results viewed. That part is solid. The sales page only fires a pageview. There is no buy-click event, so I currently cannot see whether people reach the page and bounce before checkout, or never reach the page at all. That gap should have shipped with the funnel instead of after it, and it is the first fix.

The real number

Zero assessment completions in eight days reads like a conversion problem. It is a traffic problem. A one time batch of launch posts went out the day the page went live, most of it lost to a platform gate I had already decided on before launch and knew would apply, and little went out after that. Traffic that never arrived cannot convert.

What changes this week

The fix is not a better landing page. It is putting this product into the same weekly content rhythm everything else I market runs on, instead of treating launch week as the whole campaign: one assessment link, repeated weekly, across the platforms actually live for me.

If the number still has not moved after a real month of real traffic, that is a more useful piece of information than the one I have now, because it moves the conversation back to strategy instead of tactics. Right now there is not enough traffic yet to know which conversation this is.

Free assessment, if you run coaching for a sales team: chadtdyar.com/coaching-score.