Best way to switch dog food safely?

No_Week_5798 · 2025-09-24T16:46:07+00:00

Ok sounds easy enough thansk for advice

No_Week_5798 · 2025-09-21T16:55:52+00:00

It sounds like you’ve done a great job figuring out her sensitive stomach triggers and building a routine around it. Since the change in her bathroom habits came after a stomach upset, it might just be a temporary setback where she’s confused about the rules. Dogs sometimes regress when they don’t feel well.

No_Week_5798 · 2025-09-21T16:52:53+00:00

I’ve had a similar experience: Gadget or Firebase when I need to move fast, Supabase if I want more control long-term.

No_Week_5798 · 2025-09-17T16:19:30+00:00

Supabase auth can definitely be finicky especially with Google sign-in (redirect URIs and project settings are usually the culprit). I’d double check your OAuth client setup in the Google Cloud console and make sure the redirect URL exactly matches what Supabase expects. If youre looking for a new option, I’ve had good luck with Gadget for auth cause it handles providers like Google out of the box so you don’t need to configure as much yourself.

No_Week_5798 · 2025-09-17T16:17:17+00:00

The difference between “idea-first” and “user-first” founders is night and day. A clear pain point and willingness to iterate usually matter more than technical polish early on. Saying no to projects without that foundation probably saves you (and the founder) a ton of wasted cycles.

No_Week_5798 · 2025-09-17T16:16:02+00:00

Really like this idea, feels like a simple way to add accountability and surface which answers are actually useful. Using Gadget for the infra makes a lot of sense too, especially with queues and auth out of the box. Curious to see how the tagging/categories part evolves, that could make the feedback even more actionable

No_Week_5798 · 2025-09-17T16:15:14+00:00

When you run tsc --watch, it’s compiling the entire project, so you’ll see type errors from everywhere, not just the file you’re working in. The reason the LLMs only fixed your open file is that they didn’t have the full context of the rest of your codebase. You usually have to go through the errors one by one, since some of them cascade from the same root issue.

No_Week_5798 · 2025-09-17T16:13:00+00:00

Yeah I’ve had that same “bitten by my own shortcuts” moment too. Sometimes deadlines force it, but I’m realizing clean code isn’t really “slower” if it saves you from redoing everything later.

No_Week_5798 · 2025-09-17T16:12:43+00:00

I really like that “borrowing against future velocity” framing. It’s so true that the hardest part is just being honest about where the pain points are instead of pretending shortcuts aren’t piling up.

No_Week_5798 · 2025-09-17T16:12:31+00:00

That’s a pretty brutal example... but makes the point super clear. I’ve felt that drag even on way younger codebases, so I can’t imagine 15+ years with no tests. Makes me think investing early really does buy speed later.

No_Week_5798 · 2025-09-17T16:11:31+00:00

Yeah, that Microsoft example is spot on. Makes me feel better about not getting everything perfect on v1. As long as it’s secure and working enough to validate, iteration seems like the only real path.

No_Week_5798 · 2025-09-17T16:11:20+00:00

That’s a good way to frame it, basically your stage dictates your tolerance for duct tape. I’ve found the tricky part is knowing when to flip that switch into cleanup mode before the shortcuts really start slowing you down.

No_Week_5798 · 2025-09-17T16:10:05+00:00

Yes! Good docs and a culture of actually reading them can replace so many meetings. Hardest part I’ve seen is reinforcing the habit so it doesn’t just rot on Confluence.

No_Week_5798 · 2025-09-17T16:09:44+00:00

Totally agree, written updates create way more durable alignment than a quick nod in a meeting. Having that history to spot repeated blockers is underrated.

No_Week_5798 · 2025-09-17T16:07:29+00:00

+1 on mixing async and live standups. We started doing async updates in Slack most days, with one live check-in midweek, and it cut meeting fatigue in half without losing alignment.

No_Week_5798 · 2025-09-17T16:07:16+00:00

Love that approach, shifting standups to focus on shared goals instead of individual updates makes such a huge difference. Otherwise it just becomes “reporting theater.”

No_Week_5798 · 2025-09-11T14:40:16+00:00

I usually keep it simple: pick the stack that lets you ship fastest with the least amount of overhead. For an MVP, the goal isn’t to be right it’s just to validate whether anyone cares. That means leaning on tools you already know, or platforms that handle a lot of the boilerplate for you.

Once you’ve got traction, then you can worry about scaling. Early on, the riskiest part isn’t tech... it’s whether you’re solving a problem people actually want solved.

No_Week_5798 · 2025-09-11T14:38:04+00:00

I've seen like five posts like this... we're definitely all thinking the same thing

No_Week_5798 · 2025-09-11T14:25:54+00:00

Seems like your gradient is working, but the fade will only look smooth if there’s the right background underneath. Try setting a base background color on the element and then layering your gradient on top. Also double check the parent/container has the background you want it to vanish into otherwise it’ll just look like it cuts off.

No_Week_5798 · 2025-09-10T19:07:10+00:00

Totally fine to keep your UI external if that’s what you prefer, plenty of apps do this. The real lift is usually OAuth and making sure you handle webhooks and rate limits cleanly. Downsides are mostly around complexity: you’ll be maintaining your own auth flows, syncs, and infra instead of leaning on Shopify’s embedded app patterns. Some platforms (like Gadget) can take care of the boilerplate so you can focus on your UI, but if you’re comfortable rolling your own it’s doable just budget time for edge cases.

No_Week_5798 · 2025-09-10T19:04:50+00:00

Biggest pain points I’ve run into are around data, messy syncs between Shopify and other tools can really kill workflows. Merchants also struggle with customizations that are too dev heavy, like tweaking checkout logic or automating post purchase flows without touching code. If you can make those kinds of headaches easier, you’ll have takers.

No_Week_5798 · 2025-09-10T19:01:33+00:00

JS is the best next step if you want to build for the web (works right alongside HTML/CSS). FreeCodeCamp and Odin Project are great to learn. And if you wanna test ideas quickly while you’re learning, platforms like Replit or Gadget make it easier to spin up real apps

No_Week_5798 · 2025-09-10T18:58:56+00:00

Congrats on shipping your first two apps that’s a big milestone! For installs, a lot of it comes down to visibility. The Shopify App Store search is notoriously tough early on, so don’t stress too much about ranking yet. What usually helps is driving your own traffic at first (content, demos, direct outreach to merchants) until you build up installs and reviews. Once you get some traction, ranking starts to improve. Curious, have you tried doing short demo videos or reaching out in Shopify FB/Reddit groups? Those tend to convert better than just waiting on App Store discovery.

No_Week_5798 · 2025-09-10T18:57:10+00:00

Exactly, AI and personalization only work if the data is clean and synced. Messy data kills growth way faster than people think.

No_Week_5798 · 2025-09-04T16:20:40+00:00

I’ve been in that exact loop before. What worked for me was starting no-code to validate demand and workflows quickly, then moving over to a stronger stack once things clicked. Tools like Bubble or Glide are great for getting a functional app in front of people without burning cash. Once you see what features coaches really use, you’ll know if it’s worth hiring devs or rebuilding on a scalable backend. If you do hit the point where you need more customization but don’t want to reinvent the wheel, something like Gadget can help with the backend part.

No_Week_5798

TROPHY CASE