u/Embarrassed-Sail8142

I'm planning to build a custom client portal and lightweight directory tool. I’ve heard Bubble is the veteran king of no-code, but the learning curve looks massive. workflows, responsive canvas settings, database constraints, etc. On the flip side, I keep seeing Base44 popping up everywhere for rapid AI app creation.

For anyone who has used both: how do they compare for a non-technical founder? Is Bubble still worth learning or are AI-native builders taking over...

i run a small home services business and most of my customers find me while they're out and about. when i checked my analytics, over 80% of visitors were coming from their phones, which tbh surprised me.

my current website technically works on mobile, but it still feels clunky. buttons are too close together, some sections don't line up properly, and the contact form isn't great on smaller screens. i'm worried people are leaving before they even get in touch.

i'm planning to rebuild the site anyway, so mobile experience is probably my biggest priority this time around. i don't really want to spend hours tweaking separate mobile layouts every time i update a page.

for anyone who's been through this, what website builder ended up giving you the best mobile experience without a ton of extra work?

I'm working on a platform concept connecting freelance videographers with local event organizers. I need a site where creators can list their services, clients can browse/book them, and payments can be held or processed securely. Has anyone successfully built a two sided marketplace using AI or no code platforms?

As a solo founder with a business background, I've spent years believing I needed a technical co founder or expensive dev agency to launch a web application. Now with full stack AI platforms, is it viable to design, launch, and maintain a functional software product completely on your own?

we’re looking into different delivery services for our e-commerce business and trying to understand which providers are actually reliable from both a business and customer perspective. beyond just delivery speed, we’re looking at things like package tracking, consistency, customer communication, handling higher order volumes, and how well the service works during busy periods. are there any providers you would recommend based on reliability and overall customer experience?

We moved AppSec tooling ownership from the security team to engineering about six months ago. Not because security was failing, but because the tools were effectively invisible to the developers generating the code, including the ones we rely on as SOC 2 AI coding tools in our audits. In the old model, findings surfaced in a security dashboard, got triaged by a security engineer, and then handed to a developer as a ticket. By the time the developer saw the issue, it was already several steps removed from the code that produced it.

With AI coding, that delay got worse. The person who prompted the code often no longer had the implementation context when the ticket arrived. Engineering ownership changed the feedback loop. Findings now show up in the same surfaces developers already live in: IDE diagnostics, PR discussion, CI output. Fix rate improved and the backlog shrank, mostly because the distance between generation and feedback got smaller.

The tradeoff is that coverage decisions become more contested. Security engineers know what should be caught. Engineering managers know what developers will actually keep turned on. Those priorities overlap, but not perfectly, and we've had real disagreements about what belongs in the IDE tier, what belongs in CI, and what's just too noisy to be useful.

So how are other teams handling it? Has moving more AppSec ownership into engineering actually improved review and remediation for AI-generated code, or does it just create a different class of tradeoffs?

our gtm is dragging because half my week i deal with fixing bad data. leads come in, then it is either a manual search through linkedin, a company site check, or running it through some random tool just trying to figure out if they are even close to our icp. i’m selling a developer infrastructure tool, and the standard firmographic data out there completely misses the mark. a generic tool might tell me an account has 500 employees, but it won't tell me what their actual engineering stack looks like, what backend infrastructure they run, or if their dev teams are actively contributing to relevant open-source projects. this morning i realized i missed a follow up on a hot enterprise account because i was stuck manually scrubbing a cold CSV list of dead lookups, and that hurt.

i see ai powered enrichment tools advertised everywhere, but i can't tell what is real and what is just a pretty UI selling the exact same recycled, scraped domain data under the hood. would love to hear what is actually working for yall to enrich technical accounts, or if the only answer is to just stick with manual research and keep it lean. i need to know.

vendor came in last week and demoed what they called a "vulnerability management tool." looked a lot like our Tenable setup with a different UI and a bunch of process and reporting bolted on. that's what broke me. i couldn't tell if we were being upsold on workflow features or if there's a real architectural difference i'm not seeing.

we keep getting pitched both and i'm not fully clear on where the line is anymore. from what i can tell, one just finds issues and the other is supposed to help manage the whole mess after that. but looking back, i think we've been buying tools to solve what's actually a workflow problem, which is probably why nothing has stuck.

every vendor page makes it sound like they do everything. when you look closer it feels like half of them are just scanner plus workflow, remediation tracking, and reporting glued on.
and the one we saw last week didn't change that read at all.

we're not trying to buy something huge and overcomplicated if a scanner is enough, but i don't want to pick the wrong thing and end up with a tool that only tells us what we already know with a nicer interface.

for people who have actually used both: what's the practical difference day to day? is it mostly scan results versus remediation workflow or is there a bigger gap in how they fit into an actual security program. and how do you tell when you're being sold a real thing versus a scanner with a project management layer on top.

we've been pulling in more threat intel lately (KEV, EPSS) but i'm not convinced any of it is changing how we prioritize vulns in practice

rn the flow is basic: scanners fire, we get a pile of CVEs with CVSS scores (~2k new ones a quarter off Tenable), we dump them into tickets and teams work the list mostly by severity and asset type. we've bolted on KEV/EPSS flags in a few places but it still feels like "CVSS first, everything else if we remember."

i'm trying to figure out how ppl are wiring threat intel into the vuln workflow so it drives decisions instead of just being extra columns in a report. we’ve bolted on KEV and EPSS but it still feels like CVSS is making the decisions and everything else is just metadata. or exploit attempts we've seen internally but in practice it all ends up as more metadata on the same backlog.

some talk about custom scoring models that blend CVSS, exploitability, asset criticality, business context. others seem to use simpler rules like "if it's KEV and internet-facing, it jumps to the front of the queue." i've also seen this logic live in very different places: inside the vuln tool, inside SIEM/SOAR playbooks, or just hacked together w/ spreadsheets and scripts.

for ppl who've made threat intel change what gets patched first, what did you end up doing that worked?

we're on Snyk for SCA and Tenable for infra scanning. both are running, both are producing findings, and they have never once talked to each other.

Snyk findings go to the dev team in GitHub. Tenable findings go to ops in a spreadsheet that someone exports every two weeks. different owners, different severity definitions, different SLAs, different everything. we're a ~200 person eng org with maybe 4 people who sit close enough to both sides to even notice the gap.

part that gets me is it's not even a clean split. a Log4j-type library shows up in Snyk at the code level, then shows up again in Tenable once it's running on a host. same CVE, two findings, different severities, nobody reconciling them. and when it really matters, like that library sitting on an internet-facing host, neither team feels like it's theirs to fix. the dev team says it's an infra problem because it's in prod. the ops team says it's a code problem because it's a library.

we've talked about dumping everything into Jira with a shared workflow but the asset models don't map. Snyk findings point to repos and PRs. Tenable findings point to IPs and hostnames. you can't just merge those without losing the context that makes either one actionable. my CISO keeps asking for a single risk number across app and infra and right now i have no idea how to produce that without it being made up.

has anyone gotten this to work or are you just maintaining two programs and hoping nothing falls through the middle?

Hit a weird milestone with my infra tool: total strangers are signing up. Random engineers are finding the site, reading the docs, and making accounts.

But the moment they hit the pricing page? Total ghost town. No feedback, just a silent bounce.

Because they use personal emails or read docs anonymously, I can't tell if it's a student on a hobby project or a staff engineer at a funded startup quietly running a pilot. How do you actually unmask the company identity and tech stack behind anonymous dev traffic?

we had a critical last quarter that sat unpatched for 6 weeks. CVSS 9.8, internal system, no internet exposure, no known exploit in the wild. meanwhile a CVSS 6.5 with an active exploit kit and a public-facing asset got patched in 3 days because a dev flagged it after seeing it on twitter.

that gap is what broke my trust in CVSS as a prioritization signal. the 9.8 looked scary on paper. the 6.5 was the actual fire.

since then we've been trying to rework how we decide what gets fixed first. we started weighting KEV membership harder than base score, because if CISA is tracking active exploitation, that tells us more than a severity number does. we also started pulling EPSS scores to get a probability signal on whether something is likely to be exploited in the next 30 days, not just whether it's theoretically bad.

the other thing that changed our whole triage was adding asset context. a critical on a dev sandbox and a critical on a customer-facing auth service are not the same ticket, full stop. we started tagging assets by exposure (internet-facing vs internal) and business criticality (revenue-impacting, customer data, compliance scope), and tbh those two factors now outweigh CVSS in almost every call we make.

it's still messy ngl. some teams still sort by base score because it's the default view in the scanner and nobody changed it. and we still haven't figured out a clean way to handle disagreements about what "business critical" actually means for systems that sit somewhere in the middle.

we've been trying to move security earlier in the dev cycle for about six months. the intent is right. the execution keeps creating friction we didn't plan for.

rn we have SAST running in CI and Snyk on every PR. in theory devs catch issues before they hit prod. in practice it's two different kinds of noise landing on the same build. the SAST side throws false positives the dev can't confirm without pulling in security to read the finding. the Snyk side flags real library vulns, but plenty of them are buried in transitive dependencies where the fix isn’t something you can actually implement yourself, and you’re stuck waiting on upstream. build goes red, dev either burns time chasing a finding that turns out to be nothing or suppresses one they can't fix anyway. gate ends up feeling like a tax either way.

eng lead brought it up in our last planning meeting. the security gate is becoming a place where velocity goes to die. not because engineers don't care, but because the signal is bad enough that the gate has lost credibility. when everything blocks the build, nothing feels important.

we looked at reachability analysis to cut the dependency noise down to vulns our code actually calls, helps on the Snyk side, does nothing for the SAST false positives. talked about tuning the rules and only failing above a certain threshold, but then you're back to severity score as a proxy for priority, same problem we have on the vuln management side. also talked about making findings non-blocking and routing to a backlog, but that backlog just becomes another queue nobody looks at.

part of this is that we block the build on SCA at all. a SAST finding in our own code is the dev's to fix, gating on it is fair. a transitive dependency with no patch available isn't theirs to fix, blocking the merge just punishes them for something upstream. every time i raise that though, someone says we can't knowingly ship a known vuln and it stalls right there.still can't figure out how you make security feedback feel like something that helps the dev get their work done instead of something standing between them and the merge button.

for teams that have gotten this to work: what did you change and what did you have to give up?

Choosing between hiring another SRE and paying for an infra management service is rarely straightforward, even if everyone starts by looking at cost. A new hire brings long‑term ownership, context, and flexibility, but they also need time to ramp up, and they can only handle so much on their own. If they become the next "go‑to person," you may end up with a new bottleneck instead of a fix.

A service may be quicker to start and may bring experience from other environments, but it adds coordination overhead and depends on how well it fits your stack and culture. It can help cover gaps in on‑call or maintenance, yet it can also create confusion about who is responsible when something goes wrong in production.

Some teams have used services as a temporary bridge while they grow their own team, or as a way to offload routine work so internal engineers can focus on product‑specific reliability issues. Others tried it and concluded that bringing more work back in‑house was a better fit.

If you've actually lived with both models, has paying for infra management services ever clearly beaten hiring another SRE in your case, and what did you measure or notice that convinced you one option was better than the other?

I am selling an infrastructure dev tool and I am losing my mind with our pipeline right now.

On paper everything looks great. Our tools are flagging warm signals everywhere. But the second I actually start doing outreach, nobody cares, nobody answers, and nobody even remembers interacting with our brand. It is completely dead.

I am honestly tired of these generic platform intent scores that just tell you Company X is interested based on some random page view.

I need actual data that tells me which technical teams are really looking into our space or testing related technology right now, so I know who is actually worth contacting this week.

Ideally I want something that works well with our CRM and helps us prioritize accounts based on real activity instead of filling the system with more weak signals.

Is there anything out there that genuinely helps with real GTM intelligence and pipeline generation? Would appreciate hearing what has actually worked for people here.

we're on Snyk for SCA and Tenable for infra scanning. both are running, both are producing findings, and they have never once talked to each other.

Snyk findings go to the dev team in GitHub. Tenable findings go to ops in a spreadsheet that someone exports every two weeks. different owners, different severity definitions, different SLAs, different everything. we're a ~200 person eng org with maybe 4 people who sit close enough to both sides to even notice the gap.

part that gets me is it's not even a clean split. a Log4j-type library shows up in Snyk at the code level, then shows up again in Tenable once it's running on a host. same CVE, two findings, different severities, nobody reconciling them. and when it really matters, like that library sitting on an internet-facing host, neither team feels like it's theirs to fix. the dev team says it's an infra problem because it's in prod. the ops team says it's a code problem because it's a library.

we've talked about dumping everything into Jira with a shared workflow but the asset models don't map. Snyk findings point to repos and PRs. Tenable findings point to IPs and hostnames. you can't just merge those without losing the context that makes either one actionable. my CISO keeps asking for a single risk number across app and infra and right now i have no idea how to produce that without it being made up.

has anyone gotten this to work or are you just maintaining two programs and hoping nothing falls through the middle?

selling a dev workflow tool into mid sized companies right now and i feel completely stuck between two bad options. either I buy a massive generic list and waste weeks emailing people who don't even have the problem we solve, or I go super manual, research every engineering team's stack, and move so slow that I barely hit any accounts. there has to be a better way to find teams that actually have the right technical setup and are showing some kind of real intent before I bother them.

what does your actual day to day look like when you’re trying to find qualified prospects? if I could just tighten up the filtering so I know they actually care about this specific workflow, everything else would get way easier. right now it just feels like total guesswork.

had our quarterly program review last week. i put up the dashboard. 103,412 open findings. the CISO's first question was "how many of those could actually get us breached right now." i had no answer. not a bad answer. no answer. that's when i realized the number we've been managing isn't a security metric, it's a scanner output.

not exaggerating on the count. some of these are years old. some showed up last week. most of them have a severity attached and nothing else. team is not small and not inexperienced. we've been doing this long enough to know the list is mostly inaccurate. problem is we can't prove which part is inaccurate and which part is the thing that gets us breached, so everything sits in the queue looking equally urgent and nothing moves.

we've tried working by CVSS. you end up patching things that don't matter on systems that aren't exposed while the stuff with actual exploit code in the wild ages out past SLA because nobody could agree on asset ownership. we've tried working by asset criticality. that breaks down the moment you realize half your asset inventory is stale and nobody knows who owns the thing.

what we're running into now is that the volume itself has become the problem. it's not that we don't know how to patch. it's that the backlog is so big that triage takes longer than remediation, and any time we make a dent, the next scan cycle adds more than we closed.

i've been looking at cutting the list down hard: internet-facing assets only, KEV entries only, or systems in compliance scope only. any of those would get us to a number the team can actually work. but i'm not sure if that's a real strategy or just a way to feel better about ignoring 90k findings. how did other teams break out of this. did you draw a hard line somewhere and just accept that anything outside it doesn't get touched until the priority queue is clear?

i just checked my nespresso tracking and it suddenly shows veho as the delivery service instead of the usual one i normally see. ive never had a delivery come through them before so i’m not so sure what to expect. has anyone had nespresso or anything else delivered through veho before… should i worry?

I’m gonna say this bluntly because I’m seeing it first-hand running a small DTC brand. Everyone obsesses over CAC, ads, creatives, email flows… but completely ignores last mile delivery until it starts breaking the support. We started with a cheaper last mile setup through a partner (GoFo). In theory it looked great, they offered low cost per shipment, easy integration, etc.

In reality, as volume scaled, it slowly turned into:
more “where is my order” tickets
more tracking confusion
more refunds tied to delivery uncertainty
more time spent by support on issues that shouldn’t exist

Nothing catastrophic, just death by a thousand small issues. A peer suggested we test Veho for last mile delivery on part of our orders. Slightly higher cost per shipment, but the argument was simple, reduce downstream friction. And that’s the part I think people underestimate in ecommerce delivery decisions. It’s not just shipping cost vs speed, it’s shipping cost vs operational drag.

at what point does cheaper per label stop making sense once you factor in support load, refunds, and customer experience? It feels like most teams only realize it after they’ve already scaled into the problem.