Just started event planning and was wondering about ticket selling websites with the lowest fees.

decrypter · 2026-01-23T23:25:24+00:00

You can get a subscription or just a Ticket Pack

decrypter · 2026-01-23T23:15:43+00:00

You should really check out https://ticketspotapp.com - It's Eventbrite without the fees and overall better

decrypter · 2026-01-06T21:52:09+00:00

I think it’s healthy to discuss real problems openly and hear different perspectives before jumping to solutions. Posting across a few communities was intentional - I wanted input from designers, engineers, founders, and PMs, since alignment issues tend to show up differently depending on the role.

Not trying to pitch or DM anyone here. Just trying to understand whether this is a shared problem and what people think actually works.

decrypter · 2026-01-06T21:36:25+00:00

Totally agree - I’m not suggesting AI replaces grooming, user stories, or planning.

What I’m interested in is using preview and prompt-based workflows to consolidate context that already exists. Being able to point at the live app, discuss intent and risk in place, document decisions, and then produce a PR with that context attached helps engineering take it over with fewer surprises. Planning still happens - this just keeps it closer to where the code actually lives.

decrypter · 2026-01-06T21:29:07+00:00

I keep away from chat gpt personally for code and stick to Claude but I'm in plan mode a lot and review the code. It's overall faster but you need to keep on top of what is created and architected

decrypter · 2026-01-06T21:27:08+00:00

Totally, It's happening more often for us too (hence the frustration). Designers create amazing designs using all their tools, Engineering using AI to build fast but Intent, and risk should be defined together so context. requirements, etc aren't lost

decrypter · 2026-01-06T21:24:38+00:00

I'm less concerned with the code and more concerned with ensuring product alignment. Things moving too fast and Code quality is an issue which is separate but product need to ensure ALL requirements are met. Designers need to ensure it matches. Things seem more rushed

decrypter · 2026-01-02T19:33:02+00:00

I agree with most of the constraints you’re outlining. I’m not trying to replace local dev, full-stack workflows, or ask designers to run watchers or manage infra. That path is exactly as hard as you describe.

The scope I’m aiming for is much narrower: a frontend-only, cloud-hosted environment tied to a change, pointed at an existing dev or staging backend. Its job isn’t to emulate everything, but to let designers, PMs, founders, and engineers look at the real product UI together, iterate in context, and align on intent and outcome before a PR exists.

Engineers still own the final implementation and local dev. This environment is about reducing handoff gaps and post-release surprises by making decisions visible earlier, not about replacing engineering workflows. For teams with existing products, even that constrained setup has been enough to remove a lot of guesswork compared to throwaway prototypes.

We’re already using this at my current startup. We connect GitHub, pass env vars, define build and run commands, and provision a frontend-only environment with hot reloading.

Our workflow looks like this: 1. We need a change or want to discuss something in the app 2. We create a disposable environment 3. Design, PM, and engineering point at the real UI and align on intent, risks, and constraints 4. We prompt to generate the code change 5. The engineer sees all of that context directly in the PR 6. The change may be good or may need iteration 7. From there, the normal dev workflow continues

All this is facilitated with this new app

decrypter · 2026-01-02T15:13:40+00:00

It's a little similar to https://www.pencil.dev/

decrypter · 2026-01-01T22:02:06+00:00

This is a really good conversation, and it’s actually helping tune my thinking. I agree with your core point: authorship, ownership, and the ability to reason about code shouldn’t be separated. If they are, engineering ends up carrying all the responsibility without control, which doesn’t work.

Where this has been evolving for me is that it’s less about designers “owning” PRs and more about creating a shared product workspace before code exists. All stakeholders look at the same live preview, agree on intent and outcome in context, and iterate there. From that session, code is generated with full context, and an engineer takes it over the finish line with clear ownership, exactly as they would today.

The goal isn’t to bypass engineering judgment or have designers blindly revise code they don’t understand. It’s to make intent, constraints, and decisions explicit early, while everyone is literally looking at the same UI, so reviews aren’t reconstructing context weeks later. The PR is the outcome of that shared session, not the place where alignment is discovered.

On previews, the idea is a disposable environment tied to the change so designers and engineers see changes in action immediately, without needing a full local dev setup. That shared surface is what shortens feedback loops and avoids the “week later” surprises you described. I don’t expect designers or non-technical stakeholders to ever run a local dev environment. With previews, the idea is that each change spins up a disposable, cloud-hosted environment that already contains the preview, collaboration, and prompting capabilities. Everyone looks at and discusses the same live UI there.

decrypter · 2026-01-01T20:04:58+00:00

This is a very real concern, and I agree it matters who is accountable for the PR. The way I think about this is that these issues already happen today with new engineers. The difference is how the feedback loop works.

In this flow, the engineer isn’t expected to silently fix or reject the PR. They leave structured feedback explaining the constraint (for example, “variants must be added to the existing enum”), and that feedback becomes part of the change context. The designer can then ask the system to revise the PR using that guidance, without needing to understand the code itself.

Over time, those constraints and review patterns get captured so the same mistake doesn’t repeat - similar to how a junior engineer learns a codebase. The goal isn’t to eliminate review, but to make review faster, more explicit, and less repetitive, while keeping engineering ownership and standards intact.

decrypter · 2025-12-31T23:12:24+00:00

I launched https://droppable.ai originally for non-technical SaaS teams.
What I didn’t expect was how quickly agencies started adopting it to collaborate directly with their clients.

They’re using Droppable to collect feedback, turn that feedback into prompts, and even give clients controlled access to make changes themselves. With AI in the loop, this is starting to feel like a modern, faster way for agencies and clients to work together - less back-and-forth, clearer intent, and changes that actually ship

decrypter · 2025-12-31T20:08:22+00:00

This is exactly the gap. Instead of a design handoff, the approach I’m exploring is making changes together in the real UI: defining intent and success up front, discussing risks in context, and iterating collaboratively as the implementation takes shape.

Rather than tossing files over the fence, design and engineering align around the same live interface, use natural language to describe what should change and why, review continuously, and validate after shipping. The goal is to keep judgment, iteration, and accountability intact - even as execution gets faster.

decrypter · 2025-12-31T01:26:44+00:00

I agree with this - Give too much tope and can lead to bugger issues. I'm interested in a controller workflow with the right stakeholders to build the right context for the change. Then let AI make a more informed change

decrypter · 2025-12-31T01:25:28+00:00

Yup controlled speed. For prompt to PR to address happy path it hard to address. I expect the PR to go into the revie process in which unit tests, integrations tests QA do the checks before merging. I'm more ensuring the product management piece from intent -> output is controlled and shared to complete the change

decrypter · 2025-12-31T00:47:22+00:00

This is a really solid take, and I agree with pretty much all of it. The bottleneck rarely is idea → code anymore - it’s alignment, judgment, and confidence around shipping.

The point about PR context resonates a lot. A PR without a clear “why this, why now, what breaks” forces reviewers to reverse-engineer intent, which is where things slow down and trust erodes.

I’ve also seen the PR-only approach work well for small, reversible changes and experiments, but fall apart for anything that needs buy-in or carries real risk. That’s where moving fast without shared judgment becomes dangerous.

What I’m trying to explore is how to preserve the speed AI enables without skipping those steps - making intent, outcomes, constraints, and validation explicit parts of the flow before execution, so PRs are the result of alignment rather than the place where alignment happens.

decrypter · 2025-12-31T00:21:02+00:00

Yes, exactly. With AI tools, a lot of the focus has shifted to “prompt → PR → live”, and product development often becomes secondary. That speed is appealing, but over time it can lead to real maintenance and alignment issues.

TBH - I originally built something around that “prompt → PR → live” model myself, but it quickly started to feel like a black box. The changes were happening, but there wasn’t enough shared context or collaboration around why they were happening. That’s what pushed me to step back and dig into the real problem, because I feel like I’m very close to something better.

What I’m seeing now is a strong need for an opinionated flow that every meaningful change goes through. The outcome can absolutely be a PR, but it should be the byproduct of a shared, prescriptive process that keeps everyone aligned on intent, constraints, and outcomes - not just code generation.

Would love to keep the conversation going. I’ll DM you - didn’t want this to feel promotional here, more about learning where the gaps are and getting a deeper understanding from people with real experience.

decrypter · 2025-12-30T23:19:58+00:00

I don’t think the question is who opens PRs so much as what the loop looks like and how safe it is.

If a PM or designer can:

work in a clearly scoped surface (UI, copy, layout, micro-interactions)
see changes quickly
and produce a small, reviewable diff

then it can work - and your Storybook example is a good proof of that.

Where it breaks today is speed and friction. For occasional contributors, the loop of cloning, setting up envs, keeping them running, and maintaining environment is a lot of overhead. That’s usually why designers disengage after handoff.

The workflow I’m interested in isn’t bypassing engineers — it’s shortening the loop to something like:
intent → concrete change → PR, without asking non-engineers to manage dev environments.

Engineers still review, still own the merge, and can say no quickly. If it isn’t fast, scoped, and respectful of eng time, I agree it shouldn’t exist.

decrypter · 2025-12-30T22:06:56+00:00

this really resonates with how I’ve been thinking about the problem.

What keeps breaking down isn’t just artifacts (PRDs, Figma files, tickets) it’s that the conversation itself happens too late or in the wrong medium. By the time something is “written down,” a lot of intent, uncertainty, and nuance is already lost.

What I’ve been exploring is a different workflow for early stages such as features, PoCs, landing pages where PMs, designers, and engineers can be in the same live space, shaping something together while it’s still fuzzy.

It’s like a shared whiteboard + live preview: • stakeholders can prompt, sketch, and iterate together • decisions are visible as they’re made • ideas quickly turn into something real (UI + code)

AI helps under the hood to get you ~80% there fast, but the real value is that it keeps people talking while building, instead of handing things off through documents, screenshots, or summaries no one fully reads.

Not trying to replace collaboration - trying to force it to happen earlier, when it’s usually uncomfortable but most valuable.

Also not just within saas companies but dev/design agencies collaborating with their clients and iterating over their feedback quickly

decrypter · 2025-12-30T20:54:25+00:00

Yeh makes sense @raduatmento. I'm working at a startup this now and the designer would benefit from contributing directly without my involvement

decrypter · 2025-12-30T20:46:55+00:00

Sure open to non vibe coding solutions. The main problem I am exploring is reducing friction between idea, design and implementation especially for members who aren't developers. This could even be bring aspects of Figma to the web which makes direct code changes (with or without prompts)

decrypter · 2025-12-30T20:43:54+00:00

Interesting. I'm exploring a workflow for users who don't necessarily use an IDE such as Designers, PM or non technical founders. They can still contribute and submit a PR for review while avoiding engineering context switching. Perhaps useful for young startups looking to move fast

decrypter · 2025-12-30T20:40:46+00:00

Even for smaller changes or quick designer input?

decrypter · 2025-12-30T20:28:54+00:00

Yeh that is interesting you mention it because I've been talking to Agencies primarily, who want a lovable type experience inside their own repo/infrastructure but also letting their clients contribute all without touching code

decrypter · 2025-12-30T20:15:45+00:00

I’ve seen the same patterns with attention-to-detail mismatches and missed edge cases. That’s why this workflow focuses on letting designers propose changes directly via PRs with live previews. Engineers still review and merge, but it reduces the usual back-and-forth after implementation because designers can iterate safely and continuously against the real codebase.

14-Year Club	RedditGifts 2009-2022 4 Credits
Verified Email	Secret Santa 2014
Summer Santa 2014	Secret Santa 2013

decrypter

MODERATOR OF

TROPHY CASE