Anybody worked with a web design firm they're happy with? We're currently on Webflow but open to other options, just looking to eyeball other portfolios that have some B2B experience.
I'm biased here, but I might be able to help! I build B2B sites on webflow. Here's my work. Happy to chat.
If you’re open to smaller teams, I’d take a look at DigiHelp. We’ve done Webflow projects, internal tools, automation and startup websites. Usually easier to work with than larger agencies because you’re talking directly to the people building it. digihelp.si
Built my entire website on html through Claude. If this is something that fits your bill, it'll be pretty cheap and easy to do with a template
brian.barker we do that; would caution against full vibe-coding (we discuss this a bit in our recent webinar yesterday). for a b2b org you end up with some pretty substantial technical debt that you'll have to pay off later (what my team calls 'deferred expensive')
but even we're the wrong fit, very happy to just advise / connect you with smart people to answer questions
Andrew S. Respectfully disagree. I’ve built and shipped 10+ products that were largely vibe-coded, and the key factor wasn’t the coding style—it was having clear requirements, good architecture decisions, and ongoing iteration. Technical debt isn’t unique to AI-generated code. I’ve seen plenty of traditionally developed products accumulate just as much debt. The difference is that vibe coding lets you validate ideas and reach product-market fit significantly faster. For many startups, speed of learning is actually more valuable than spending months engineering the “perfect” solution upfront. If the product gains traction, you can always refactor. If it doesn’t, you’ve saved months of development time. AI is a tool. Bad engineers create technical debt with or without AI, and good engineers know how to manage it either way.
Technical debt isn’t unique to AI-generated code. I’ve seen plenty of traditionally developed products accumulate just as much debt.
1000% agree with this!!
The difference is that vibe coding lets you validate ideas and reach product-market fit significantly faster.
Definitely agree with this too, but my lens is generally coming from slightly more mature companies who already have PMF and are trying to leverage themselves into a market position. (we work with SeriesB+ all the way up to Fortune 1000 companies basicaly)
For many startups, speed of learning is actually more valuable than spending months engineering the “perfect” solution upfront. If the product gains traction, you can always refactor. If it doesn’t, you’ve saved months of development time. AI is a tool. Bad engineers create technical debt with or without AI, and good engineers know how to manage it either way.
I generally agree with this, but like lemme use vibe coding as my metahpor here. When you're vibecoding, the thing that matters the most by far (in my exp) is the plan. What are your specs, docs, strategy, data sources, context rules, plugins, skills, definitions, etc etc. If you don't do these parts well, you end up with very fast, very bad code. I'd suggest that this extends to the entire systems architecture for a B2B company, and that jamming through a website at max velocity opens you up to the same times of long-term debts that jamming through a claudecode prompt gets you without proper setup. Obv there's a tradeoff between speed and quality and you can't knock startups for wanting to go fast!
I think we’re actually pretty aligned. My point wasn’t that planning, architecture, or documentation don’t matter. Quite the opposite. The most successful AI-built products I’ve seen had very clear specs, constraints, and ownership from day one. Where I disagree with a lot of anti-vibe-coding takes is that they often assume the problem is AI itself, when in reality the problem is usually a lack of engineering discipline. If someone can create a mess with Claude, they’ll create a mess with a team of developers too. For a Series B+ company with an established product and existing customers, I’d absolutely be more cautious. The cost of mistakes is much higher and technical debt compounds across teams. But for startups still searching for product-market fit, I’ve found that the risk of moving too slowly is often greater than the risk of accumulating some technical debt. You can refactor code. It’s much harder to recover the time spent building something nobody wants. So for me it’s less “vibe coding vs traditional development” and more “appropriate level of rigor for the stage of the company.”
yeah def aligned there! 🫡
