DEV Community: Chad Dyar

I Built a Pet Health App in Two Weeks Because My Notebook Failed Me

Chad Dyar — Fri, 10 Apr 2026 19:00:44 +0000

I Built a Pet Health App in Two Weeks Because My Notebook Failed Me

I was keeping a notebook to track health data for my three dogs.

For about two weeks, it worked. Then I needed to find a pattern in Maya's energy levels and the notebook turned into a pile of inconsistent entries I couldn't read or share or filter in any useful way. That, combined with an incident where I took my mom's dog to the vet and couldn't answer a single question about her history, pushed me to just build the thing.

Two weeks later, Pawformance was running in production. Here's how I built it and what I learned.

The Stack

Frontend: Lovable
Backend: Supabase (auth, database, real-time)
Payments: Stripe
Analytics: PostHog
Error tracking: Sentry
Uptime monitoring: BetterStack

The Lovable and Supabase combination is what made the two-week timeline possible. Lovable handles UI scaffolding fast. Supabase removes the need to build auth, manage database infrastructure, or set up API layers from scratch. Together they let me stay focused on the data model and the product logic rather than the plumbing.

The Data Model

This took the most thought. Here's the core structure:

users (handled by Supabase auth)

pets

id, user_id, name, species, breed, birthdate, weight, photo_url, created_at

health_events

id, pet_id, user_id, event_type (visit / symptom / observation), title, notes, date, created_at

medications

id, pet_id, user_id, name, dosage, frequency, start_date, end_date, notes, active

vaccinations

id, pet_id, user_id, vaccine_name, administered_date, next_due_date, administered_by

weight_logs

id, pet_id, user_id, weight_lbs, logged_at

activity_logs

id, pet_id, user_id, activity_type, duration_minutes, notes, logged_at

Everything scopes to user_id and pet_id. Supabase Row Level Security policies enforce this at the database level so a user can only read and write their own records. For the multi-pet dashboard, queries join across pets where user_id matches. No duplication, just proper relational structure.

The shareable vet report queries across all these tables for a given pet and generates a structured output. That was the original reason I started building. If I had had this when I took my mom's dog to the vet, I could have answered every question the vet asked.

Payments: Stripe and Three Tiers

Three tiers:

Free: single pet, core logging
$3.99/mo: unlimited pets, medication reminders, vaccination scheduling
$7.99/mo: everything in $3.99 plus AI symptom checker, shareable vet reports, weight trends, multi-pet dashboard

Stripe Checkout handles the subscription flow. Supabase stores the subscription tier on the user record and the frontend gates features based on that value. The 14-day trial is set at the Stripe level so it applies automatically without extra logic on my end.

The integration was straightforward. The main thing I'd do differently: build the billing portal link into the app earlier. I added it later than I should have and it created unnecessary friction for testing the upgrade flow.

Observability: PostHog, Sentry, BetterStack

PostHog handles product analytics. I track key events: pet created, health event logged, report generated, upgrade initiated. With 8 users and 22 pageviews per week, the event volume is low, but the data is already showing me where people drop off in the onboarding flow.

Sentry catches errors in production. I integrated it early and it's caught a handful of things I wouldn't have found otherwise. One malformed date input that broke the weight chart. One edge case in the medication reminder logic where end_date being null caused a render error. Small things, but the kind that erode trust fast if they surface repeatedly to users.

BetterStack monitors uptime. Pawformance is not handling any level of traffic where downtime is a crisis, but the habit of monitoring matters. It also sends alerts if the Supabase instance or any external service dependency goes down.

What Worked

The Lovable and Supabase combination delivered on the two-week timeline. I was in production with auth, multi-pet support, full logging, and a working report before I'd spent a month on this.

Row Level Security in Supabase is the right way to handle per-user data scoping. Setting it up at the database level means I don't have to trust that every query in the application code has the right filters. The policy enforces it regardless.

PostHog session recordings have been more useful than I expected at this traffic level. Watching how the two or three active users actually move through the app told me things I couldn't have inferred from the event data alone.

What I'd Change

The data model for health_events is a little too flat. I used a single event_type field to distinguish between vet visits, symptoms, and general observations. That worked fine until I wanted to add structured fields specific to vet visits (like vet name, clinic, and cost). I ended up adding those as optional columns on health_events, which is fine but not clean. I'd probably split this into separate tables for vet_visits and observations with a shared parent structure.

I also built the free tier too generously in one specific way: the core logging experience is complete on free. That's intentional from a product philosophy standpoint, but it means the upgrade motivation is mostly about power users who have multiple pets or need the report. I'm comfortable with that trade-off, but I should have stress-tested the conversion logic before launch rather than after.

Current Numbers

Users: 8
Revenue: $0
Pageviews per week: 22
Months since launch: several

I built this and then essentially didn't promote it. The numbers reflect that. The app works, the infrastructure is solid, and I'm now actually starting to put it in front of people.

If you're a dog owner who has ever tried to track health data in a notebook and watched that system fall apart, or if you've stood in a vet's exam room and realized you couldn't answer basic questions about your pet's history, the free tier is a good place to start.

pawformance.app

Happy to answer questions about any of the technical decisions in the comments. The Supabase RLS setup and the Stripe trial logic are the two things people usually want to dig into.

The Vet Visit That Made My Side Project Real

Chad Dyar — Tue, 07 Apr 2026 14:13:42 +0000

The Vet Visit That Made My Side Project Real

I built PawFormance for three reasons: Wick, Maya Rudolph, and Benny Hartz. My corgi, my Australian Shepherd, and my other corgi, respectively.

Like most side projects, it started with scratching my own itch. I had notebooks with scribbled dates, a Notes app full of "when did we last deworm?", scattered vet receipts, and that nagging feeling that I was forgetting something important about my dogs' health.

So I did what developers do. I built something.

The Technical Part (Spoiler: Not the Interesting Part)

The stack was straightforward. Next.js for the frontend, Supabase for the backend, Vercel for hosting. Built a CRUD app for pet health records—vaccines, vet visits, medications, weight tracking. Added some charts because data visualization makes everything feel more legitimate.

The build itself was unremarkable in the best way. Modern tooling is so good now that the actual construction of a pet health tracker is almost boring. Authentication? Solved. Database? Done. Responsive design? CSS Grid and Tailwind make it almost trivial.

I finished the MVP in a few weekends. Deployed it. Used it myself for a couple months. Felt good about actually shipping something instead of letting it rot in a private repo like so many other projects.

The Part I Didn't See Coming

Three months after launch, Wick started limping.

Not dramatically—just favoring his back left leg. At first I thought maybe he'd overdone it at the dog park. But it persisted. So I scheduled a vet appointment.

This is where PawFormance stopped being a side project and became... something else.

Sitting in the exam room, the vet asked when I first noticed the limp. I pulled up the app. I'd logged it four days ago, noting it was worse after walks. She asked about his weight trend. I had six months of weigh-ins charted. She asked when his last vaccination was and whether we'd had any recent medication changes. I had exact dates for everything.

The appointment went from "let's figure out what's happening" to "let's treat what's happening" about fifteen minutes faster than usual.

Wick's fine, by the way. Mild strain, some rest, good as new. But I sat in my car afterward and realized something I should have known but didn't really feel until that moment:

The value of what you build reveals itself in the quiet moments, not at launch.

What I Learned Building for My Own Dogs

When you're heads-down in code, you think about features. Edge cases. Performance optimization. Will the calendar component handle timezone differences? Should I add photo uploads? What about multi-pet households?

What you don't think about is the relief of having your dog's entire health history in your pocket when you need it. You don't think about the subtle confidence boost of being able to answer your vet's questions with precision instead of "uh, maybe March? Or was it April?"

You definitely don't think about how tracking your dog's weight over time will let you catch that gradual gain that indicates you've been a little too generous with the treats.

The technical problems are solvable. The emotional impact is unpredictable.

Still Just a CRUD App

I haven't raised funding. I'm not scaling to millions of users. PawFormance is still fundamentally a database with a nice interface. But it's useful. And it's used. Not just by me—other dog owners found it and started tracking their pets too.

Some sent me emails about their own vet visits going smoother. One person thanked me because they finally had all their dog's information organized before an emergency trip to the animal hospital. That one made me tear up a little.

This isn't a post about growth hacking or technical architecture. It's about the weird gap between shipping code and understanding what you actually built.

The product worked the day I deployed it. But I didn't understand its value until Wick limped and the data was just... there.

If you've got dogs (or cats, or both), and you've ever scrambled to remember dates during a vet visit: pawformance.app

Start Tracking Free — because the data you'll need is always the data you forgot to write down.

Tags: saas, automation, indiehackers, productivity | I have a chronic illness that sometimes puts me on the couch for a full day

Chad Dyar — Mon, 06 Apr 2026 14:01:53 +0000

Tags: saas, automation, indiehackers, productivity | I have a chronic illness that sometimes puts me on the couch for a full day without warning. I also run a senior enablement role at a tech company, maintain six web apps, and have 17 published books. The math does not work unless some of the output runs without me. So in February, I spent two weeks building an autonomous content publishing system. The Problem: I was creating content for nine platforms every week: LinkedIn, Pinterest, Mastodon, Substack, Medium, Dev.to, IndieHackers, Quora, and my personal blog at chadtdyar.com. Each platform has different formatting, character limits, and audience expectations. I was spending 4-5 hours per week just reformatting the same ideas for different channels. The Architecture: Database is Supabase Postgres. A marketing_queue table stores every piece of content with fields for platform, day of week, body text, status, and source. Validation functions run on insert to catch formatting issues before they reach the publish queue. Content generation uses weekly batch sessions producing all nine platforms worth of content from a single story seed. I use Claude to help draft and adapt, but every story comes from real experience. Publishing pipeline: a scheduled task checks the queue daily and routes content to each platform. Short-form auto-approves. Long-form stays in review until I manually approve. Monitoring: PostHog tracks pageviews across all six apps and the blog. Sentry catches errors. What Worked: The Supabase validation layer is the unsung hero. Batching content from a single seed story keeps the week coherent across platforms. What I Would Do Differently: Start with fewer platforms. Build the review queue first. Invest in content validation earlier. The Result: The system published to 40 accounts on a day I could barely hold my phone. I am now building ContentForge at contentforgehq.com as a product version of this workflow. If you are building something similar, the key insight is: validate everything before it enters the queue, and never trust auto-publish without a safety layer.

Life in a preacher's family taught me about living two lives. The Gospel Trilogy dives into the tension between faith and messy

Chad Dyar — Sun, 05 Apr 2026 16:17:14 +0000

Life in a preacher's family taught me about living two lives. The Gospel Trilogy dives into the tension between faith and messy reality. It's more than just a play; it's a conversation starter.

https://www.chadtdyar.com/books/the-gospel-trilogy

I've managed engineering-adjacent teams for two decades. The pattern is always the same:

Chad Dyar — Sun, 05 Apr 2026 16:17:13 +0000

I've managed engineering-adjacent teams for two decades. The pattern is always the same:

New hire is on fire. Shipping fast, volunteering for extra projects, staying late.
Six months in, quality starts slipping. Not dramatically — just enough to notice.
By month 12, they're either checked out or actively looking.

The problem isn't workload. It's that nobody taught them how to sustain.

High performance isn't about doing more. It's about knowing what to protect. Your energy. Your focus. Your recovery time. The things that make the work good in the first place.

I wrote a book about this called Bring Your Best Self To Work. It's not a self-help book — it's a framework for people who are good at their jobs but keep running themselves into the ground.

Chapters cover energy management, the myth of work-life balance (it's work-life integration), and how to have honest conversations with your manager about sustainability.

If you've ever felt like you're performing well but paying too high a price for it, this might resonate.

There's a weird overlap between sales conversations and code reviews. Both require you to:

Chad Dyar — Sun, 05 Apr 2026 16:02:15 +0000

There's a weird overlap between sales conversations and code reviews. Both require you to:

Listen before you respond. The worst code reviews are the ones where the reviewer skims and reacts. The best ones start with "help me understand why you went this direction."
Separate the person from the problem. "This code is wrong" vs. "I think there might be an edge case here" — same feedback, completely different outcome.
Ask questions that open doors. "Have you considered X?" beats "You should do X" every time.

I wrote a book called How to Talk to Humans aimed at salespeople, but developers keep telling me it changed how they run 1:1s and give feedback.

The core idea: communication isn't a soft skill. It's the infrastructure everything else runs on.

If you lead a team or work cross-functionally, the chapters on "strategic silence" and "the 3-second pause" might be worth your time.

LinkedIn just announced they're deprioritizing "humblebrags" and promotional content in favor of authentic storytelling. The tim

Chad Dyar — Sun, 05 Apr 2026 16:02:14 +0000

LinkedIn just announced they're deprioritizing "humblebrags" and promotional content in favor of authentic storytelling. The timing is perfect, because sales leaders have been fighting this same battle internally for years.

I've spent two decades in sales enablement, and the pattern is always the same. Someone creates a brilliant discovery call framework. It gets documented. Then it gets turned into a 47-slide deck with corporate messaging, compliance disclaimers, and exactly zero personality. By the time it reaches the sales floor, nobody uses it because it sounds like a robot wrote it for other robots.

The best sales conversations I've ever heard sound nothing like the approved pitch deck. They sound like two people actually talking. One person asks a real question. The other person gives a real answer. Something unexpected happens. Both people learn something. That's the structure that converts.

This is why I built the 4-Minute Yes And Call Brief. It's not another framework to memorize. It's a forcing function that makes you extract the actual story from a discovery call. What did the prospect say that surprised you? What did you learn about their world? What question would you ask differently next time?

The "yes and" part comes from improv comedy. You can't plan the perfect call, but you can train yourself to notice what's actually happening and build on it. That's a skill. It requires practice. Most sales teams skip this step entirely and wonder why their onboarding takes six months.

LinkedIn's algorithm change isn't really about algorithms. It's about what works when humans are deciding whether to keep reading or scroll past. Corporate humblebragging doesn't work because it's not interesting. Nobody cares that you're "thrilled to announce" something. They care if you learned something useful and can explain it without jargon.

The same principle applies to discovery calls. Prospects don't want to hear your positioning statement. They want to know if you understand their actual problem and whether you've helped someone like them before. That requires you to have real conversations and remember what happened in them.

The 4-Minute Yes And Call Brief trains that muscle. After every call, you take four minutes to write down what actually happened. Not what was supposed to happen. What did. Then your team has a library of real stories instead of theoretical ones.

If you're building sales enablement tools or training programs right now, this is the shift worth paying attention to. The tools that win are the ones that help people sound like people.

TITLE: Teaching Kids About Emotions with Dogs as Guides

Chad Dyar — Sun, 05 Apr 2026 14:45:33 +0000

TITLE: Teaching Kids About Emotions with Dogs as Guides

Understanding Raw Emotions
Kids experience emotions intensely and often can't articulate them. Recognizing this is the first step in helping them grow.
The Role of "The Wiggles, the Woofs, and the Why"
This book uses three dogs to teach kids about emotions. Wick, Maya, and Benny serve as guides, each embodying characteristics like calmness, joy, and persistence.
Building Emotional Awareness
Through stories, kids can learn to ide

TITLE: How Dogs Teach Kids Self-Awareness: A Practical Insight

Chad Dyar — Sat, 04 Apr 2026 16:12:26 +0000

TITLE: How Dogs Teach Kids Self-Awareness: A Practical Insight

The Challenge of Self-Awareness: Kids struggle to understand their own actions. Dogs, with their simple, honest interactions, offer a unique way to teach this skill.
The Role of Wick, Maya, and Benny: In "The Sparkle, the Snuggle, and the Song," these dogs aren't just characters. They're guides, showing kids the impact of their daily choices.
Practical Lessons from Play: The book uses playful scenarios to demonstrate how

My Stack for Building and Monitoring 6 Web Apps as a Solo Developer

Chad Dyar — Sat, 28 Mar 2026 04:40:10 +0000

I run six web apps as a solo developer with a day job. Here is the exact stack and how the pieces fit together.

Hosting and deployment: five apps are on Lovable (one-click deploy from their builder), one (ContentForge) is on Vercel. All use custom domains through Cloudflare for DNS and SSL.

Database: Supabase (Postgres) for all six apps plus a central "command" project that holds cross-app analytics, book sales data, and the marketing engine.

Payments: Stripe with tiered pricing on every app. Free tier, mid tier ($3.99-4.99/mo), premium tier ($7.99-9.99/mo). No paying customers yet, but the infrastructure is ready.

Analytics: PostHog for product analytics across all six apps. One project, events tagged by app name. This lets me compare engagement across apps in a single dashboard.

Error tracking: Sentry with one org and separate projects per app.

Uptime: BetterStack monitors all six domains.

Email: Resend for transactional email.

The key architectural decision: one central Supabase project acts as the hub. It connects to each app's project through Supabase edge functions. This gives me a single place to query across all six apps, run marketing automation, and track portfolio-level metrics without logging into six different dashboards.

Current numbers are small (364 total pageviews last month across all six apps), but the monitoring infrastructure scales. Every tool on this list either has a generous free tier or has a free tier that covers my current scale.

The apps: contentforgehq.com, momentumfit.app, thehomegrown.app, getpillpal.app, pawformance.app, palettepro.design.

Code and details at chadtdyar.com.

The Compounding Gap: What Happens When AI Stops Resetting Every Session

Chad Dyar — Sat, 21 Mar 2026 17:22:07 +0000

About a year ago I stopped treating AI as a tool I use and started treating it as infrastructure I build on.

The difference sounds academic until you live inside it.

What the old model looked like

Open a new chat. Explain who I am, what I'm working on, what my standards are. Get a draft. Close the tab. Next day, repeat. Every interaction was a cold start. The AI was a temp worker who showed up fresh every morning with no memory of yesterday.

What the new model looks like

Context persists. My AI systems know my writing voice, my active projects, my preferences for how I structure arguments and present data. When I sit down to work, I'm not onboarding a new assistant. I'm picking up where I left off.

The shift didn't require exotic tooling. It required asking a different question. Instead of "can AI help with this task" I started asking "what would this workflow look like if AI were present at every layer?"

Where the gap is now

Most people I talk to are still in the old model. New chat, fresh context, isolated sessions. They're "using AI" the same way they were a year ago.

The people who shifted to persistent systems six to twelve months ago are in a different category. Their outputs are compounding because every interaction builds on the last. The reset tax they used to pay every morning is gone.

From the outside, both groups look the same. Both "use AI." But the outputs are diverging in ways that are increasingly hard to ignore.

The part nobody says out loud

This gap will keep widening. The barrier to building persistent context is dropping every month. Memory systems, custom instructions, persistent agents, these are all getting more accessible. The people who start building now will catch up faster than early adopters did. The people who wait will be further behind than they expect.

What I'd tell someone starting today: stop asking AI to help with tasks. Start asking what your entire workflow would look like if context never reset.

How a 15-Year Opera Career Became a Sales Training Framework (And How I'm Shipping It)

Chad Dyar — Thu, 12 Mar 2026 12:53:45 +0000

I did not expect my background in professional opera to become the core IP of a sales training book. But here we are.

The through-line is ensemble performance. For fifteen years I sang with professional opera companies. The thing that separated great ensembles from competent ones had nothing to do with individual skill. It was whether the performers were building one shared story or several individual stories that happened to share a stage.

When I moved into sales enablement, I kept watching the same pattern on account team calls. Skilled individual sellers showing up on the same Zoom window and telling different stories. The prospect could feel it. The deals slowed or died in ways that had nothing to do with the product or the price.

The framework I built from this is in a book called Think on Your Feet, Land on Your Numbers. The core principle is "yes, and" from improv: you build on what your scene partner gives you instead of redirecting or correcting. Applied to sales, it means your team picks up the baton from each other on calls and tells one coherent story the prospect can follow.

How I built the training module

Three components, in the order teams should learn them.

Simulation first. Before anyone reads anything, run call simulations where the only rule is that each person must acknowledge what the previous person said before adding their own content. "Building on what [teammate] just said..." is a legitimate bridge. Do this twice and the concept clicks faster than any written explanation.

Call analysis second. Pull recordings from real multi-person calls. Identify every moment where a team member failed to build on what the previous person offered. Call them "thread breaks." Count them per call. This creates a measurable baseline and surfaces specific moments to debrief.

Pre-call brief third. Four minutes, three questions, one shared destination before anyone dials in. This is the structural fix that makes the listening habit stick.

How I'm distributing it

ContentForge, which I also built and run. One core idea from the book goes in. Platform-specific content for eleven channels comes out. The blog post is the long-form anchor. Everything else adapts to format. I'm testing whether leading with the opera backstory outperforms leading with the sales principle. My bet is the personal story pulls harder. Early data this week will tell.

The lesson I'd give builders creating training content: experiential first, conceptual second. Always. The teams that adopted the framework fastest did the simulations before they read a single page of the book.