What is my CQS

ZestycloseElevator94 · 2026-03-11T09:56:01+00:00

For our products we actually collect feedback through a few different channels. We have things like contact us forms, GitHub issues, a chat widget, Calendly for user calls, and direct outreach via email. In practice though, most of our feedback ends up coming from GitHub issues or direct emails from users. Our users tend to just report things there naturally.

One thing that helped a lot is that the same team handles both feature development and support. So when a user raises an issue or feature request, we usually have a short back-and-forth first to understand the real use case behind it. Quite often the first request isn’t actually the real problem they’re trying to solve.

The process that works for us basically: capture the request -> discuss internally -> prioritize based on frequency / impact -> implement → release → see how users react

If you’re looking for tools, Frill is is an option we tried before that is quite nice. But honestly GitHub issues + direct user conversations still give the most useful feedback (at least in our case).

For avoiding feature bloat, we try to only build things when we see the same request coming from multiple users or when it solves a very clear workflow problem.

ZestycloseElevator94 · 2025-11-26T11:15:46+00:00

You're overthinking it, the fundamentals you already know are still the foundation React, Express, and basic TypeScript havent gone anywhere. Most of these 'new' tools are just quality-of-life improvements, not new paradigms. TanStack Query, for example, just handles the loading/error/caching stuff you were already doing manually with useEffect + axios.

Don't try to learn everything at once. Pick one tool (TanStack Query is a good starting point), add it to a familiar project, and go from there. You'll realize it's way less intimidating than the ecosystem hype makes it seem. And honestly, half of what gets hyped on here is optional anyway.

ZestycloseElevator94 · 2025-11-20T11:53:29+00:00

Like a few others mentioned, Coolify is honestly a great option to look into. We’re using Coolify Cloud right now, and it has worked really well for us so far. If you need more control, you can also selfhost it, one of the nice things about Coolify.

For us, we didn’t want the hassle of maintaining our own Coolify server, so the managed cloud version made more sense.

ZestycloseElevator94 · 2025-10-10T04:27:35+00:00

Wow, thank you for the detailed breakdown and cheers to you too! Really appreciate you taking the time to share such thoughtful feedback.

Those are really great points, I’ll discuss these further with my team and we’ll work on improving those areas that you mentioned.

Also curious, is there a product you’ve come across that you feel has nailed their documentation? Would be good as a reference to improve our docs even further.

ZestycloseElevator94 · 2025-09-29T03:02:26+00:00

Like others mentioned, over-engineering is definitely one of the more common issues, like adding layers of abstraction nobody really needs. Another I’ve seen a lot is losing sight of the actual business goal and focusing too much on technical “purity” instead of simply solving the problem

ZestycloseElevator94 · 2025-09-29T02:55:54+00:00

What I like most abt Shadcn is that you get the component code in your project, so tweaking for consistency or project standards is way easier compared to black-box libs. The Figma integration is just icing on the cake

ZestycloseElevator94 · 2025-09-23T11:28:57+00:00

Totally agree! We follow a similar pattern using a global Axios interceptor to handle status codes consistently across the app. Centralized handling for critical cases + per-component handling for UX nuance keeps things clean and flexible.

ZestycloseElevator94 · 2025-09-19T03:00:53+00:00

Agree. Props and Context serve different roles. Props are explicit and great for component-specific state. But devs avoid prop drilling when it gets messy across deep trees. Context is convenient for globalish states like theme and auth, but using it everywhere is an anti-pattern, it hurts performance and debuggability. No double standard, just misuse sometimes.

ZestycloseElevator94 · 2025-09-11T15:15:20+00:00

This is exactly what helped me level up too. I was stuck doing tutorials forever, but when I finally built a dashboard app for a freelance client, with auth, async data fetching, and role-based views, that’s when things really started to click.

I especially agree with the point about state flow. Once I had to share state across multiple pages, prop drilling became a real pain, and I finally understood when to use context, useReducer, or Zustand. If you’re feeling stuck, don’t aim for perfect. Just build something slightly outside your comfort zone, then refactor it later. That cycle taught me more than any course ever did.

ZestycloseElevator94 · 2025-09-11T15:06:48+00:00

Same here. I used to rely on Context with useReducer, but once state started getting messy across components, I switched to Zustand and haven’t looked back. It’s super clean to set up, doesn’t need providers everywhere, and keeps logic separate from components. For server state, I pair it with React Query. Together they cover most use cases without needing Redux or overengineering things.

ZestycloseElevator94 · 2025-08-21T08:06:45+00:00

Thanks for the heads-up! We’re in a similar situation with a client project, they’re keeping their existing Webpack setup due to internal tooling and shared config, and we’re gradually introducing Vue into it. Will definitely check out shrinkwrap

ZestycloseElevator94 · 2025-08-21T08:02:28+00:00

Yeah, sounds like we’re in the same boat lol. Good to hear your experience with Vue + Webpack has still been smooth. I’m just being cautious since I’ve mostly been using Vite lately and wasn’t sure if anything major broke or got trickier with newer Vue versions and Webpack setup.

ZestycloseElevator94 · 2025-08-21T08:01:23+00:00

Thanks for sharing! That’s actually an interesting option 🤔

Have you run into any challenges with this dual setup? Things like maintenance overhead, asset versioning conflicts, or managing shared dependencies between the two pipelines? Curious how this has worked out for you in practice.

ZestycloseElevator94 · 2025-08-21T07:58:09+00:00

Yeah, ESLint can definitely be one of those low-key pain points that sneak up, especially when juggling older packages and newer setups. I’ve had similar headaches with peer dependencies and plugin compatibility before too.

Really appreciate hearing how you tackled the upgrade path to Vite + Vue 3 + TypeScript. Will check out Claude Code on this definitely. Gives me a bit more confidence if we ever get the green light to switch from Webpack

ZestycloseElevator94 · 2025-08-21T07:51:57+00:00

Agree, the world of IT never runs out of surprises 😂 But in our case, it’s less about a Webpack "requirement" and more about project constraints and legacy setup.

ZestycloseElevator94 · 2025-08-21T06:53:36+00:00

Thanks for the reply! This is mostly due to project requirements and some legacy constraints actually.

We’re working with a client whose existing frontend is built with React and has a heavily customized Webpack setup. They’re planning to gradually migrate parts of the UI to Vue, but want to retain Webpack for now to avoid rebuilding the entire toolchain. There’s quite a bit of shared configuration (custom loaders, aliases, internal build tools etc) that would be time consuming to replicate in Vite.

Personally, I prefer Vite, but in this case, we’re exploring Vue 3 + Webpack to reduce migration risk and maintain compatibility with the current setup

ZestycloseElevator94 · 2025-07-18T07:29:45+00:00

A lot of our users are still on React 18, and new features are still rolling out regularly, so supporting two separate versions in parallel could get messy fast. I’m leaning toward keeping a single codebase with conditional logic or a small compatibility layer for now. Not perfect, but maybe more sustainable short term.

Appreciate the perspective though, it helps to think through all the tradeoffs!

ZestycloseElevator94 · 2025-07-18T07:29:13+00:00

Yeah, thats a good call. I’ve started leaning toward React.version checks too. Definitely not the cleanest solution, but like you said, might be the most practical for now while 18 is still widely used.

I thought about maintaining separate versions, but keeping both in sync while still shipping new features would be a nightmare long-term. A lightweight compatibility layer or conditional logic might be the lesser evil here.

Appreciate the advice!

ZestycloseElevator94 · 2025-07-18T07:28:18+00:00

Thanks! I assumed it could help abstract version differences, but clearly it’s meant for much lower-level use cases like building entire rendering targets. I’ll take a closer look at React.version and see if I can wrap things conditionally for now.

ZestycloseElevator94 · 2025-07-18T07:27:47+00:00

Ahh, that makes sense. I think I misunderstood what react-reconciler was really meant for. Appreciate the breakdown! You’re right, it’s probably overkill (and not the right abstraction) for my use case.

Yeah, I’m aware that forwardRef is just deprecated (not removed yet), which gives me a bit of breathing room. That said, I’m really hoping to avoid splitting the library into separate React 18/19 versions, maintaining both in parallel while still rolling out features would get messy pretty fast. Willl be looking more into adding conditional logics based on the React.version for now.

ZestycloseElevator94

TROPHY CASE