B2B websites as revenue engines.

Hi, Margus. Thank you so much for having me. I'm super excited for this podcast, especially because you are the person focused on websites and I'm focused on websites. It's like two nerds who can talk about specific things. I'm super happy to be here to talk a little bit about our approach for building websites, especially for B2B. I know you have a lot of expertise here. It will be an amazing talk.

Cool. Maybe let's start with your agency - who is it for, what's the vision?

Peakout is quite a new agency and we are focused on building marketing websites, mostly for B2B tech companies. I don't mean only SaaS products because we also have clients creating software as a B2B tech service. But in most cases, that's our audience. We feel very comfortable talking with B2B tech companies. We understand their needs. My co-founder and I also created software in the past, so I think we understand this niche. We take the whole process - from brainstorming the website, building the positioning and messaging, going to design, then implementing infrastructure. By infrastructure, in most cases I mean Webflow, but we're also exploring tools like Framer. We start with building the foundation, add infrastructure, and then if the company is already ready, we can add growth around the website. That's how we understand packaging a website - different small puzzles, small plugins, adding AI, adding Clay, adding some kind of personalization. The website in our opinion is just the product that is created. It should be used by the marketing team, by the sales team. It should be an asset, not just a static thing you take a budget for with no ROI.

You already mentioned so many things I want to unpack. On your website, you mention that websites are revenue engines, not just brochures. What does that actually mean in practice? What's the biggest difference between a website that's just a marketing asset and a revenue engine?

From our point of view, when we're super realistic - your business website doesn't have a lot of traffic. When you look for tips to boost your conversion, you'll get a lot of advice like "do A/B testing on your button" or "check if your button should be green or red." Those tips are interesting and they work, but in e-commerce or SaaS when you have the audience and the metrics are statistically accurate - that works. Not all businesses have this privilege. We understand that the website should be the growth engine you can use in the sales process. When you're doing outbound, you want to attract clients to your business, you invest in different channels, you do ads, you do outbound, you do events. And then the lead comes to your website. In most cases, there is totally different communication there - totally different case studies, a static thing we did in the past. The most upsetting thing is that usually companies are growing. When you go to a discovery call with the sales team, they'll prepare a personalized deck for you - they'll showcase case studies relevant to your industry and niche. But then the website is totally separate. By "growth engine," we understand creating an asset that can support this whole journey. If you invest in outbound and your goal is to set a meeting, instead of sending a generic Calendly to everybody, you can use the website as the engine and create a personalized booking link for each prospect. Instead of just saying "here's our Calendly," you say "here is the page I prepared for you. On this page you'll find case studies relevant to your situation." So the idea is to squeeze more from these websites. Not only fancy things like IP-based personalization or connecting MCP servers to Webflow - those are super cool. But in most cases, we can take care of communication and think how we can use the website in the whole journey.

Yeah, it's basically making the website an online salesperson who can tell all the story that salespeople would tell during a call. Now we can leverage it even when we're not on the call, not controlling the narrative, but we can control it with the website and give all the relevant context.

Exactly. And especially in your space, in SaaS, you can take care of different data points in this journey. You can have some chatbot, you can make the experience unique, you have 20 to 30 languages on your website. As you said, this website is going to be like your salesman working 24 hours, seven days a week. I'm not saying it will close deals because in B2B services you need to go to the call and provide a lot of touchpoints. But why don't you use the website as a very important piece of the equation?

Yeah, it can already do 70% of the job and you just have to close it. Also, the things you're doing are really foundational. You can do all the testing you want, but if the website isn't functioning foundationally well, then what's the point of testing? I really like the approach because often companies have a website that got designed five years ago and it's just sitting there. Maybe every five years they'll redesign it. But it's not even about the design. Course design should look nice, but it's about how the website actually works and functions.

It's much easier to build a good website and focus on fancy things if you already know who your ICP is, what you sell, what your offer is. Very often we do a small exercise when we start working with clients. We ask for materials like the sales deck and presentation. If possible, we also take transcripts from sales calls. And then we compare that with the communication that is on the website. Almost every time, the most important heading, the website structure, the case studies used are totally different from what the sales team actually says. We're not even talking about implementing good infrastructure. All those things come later. But how do you use a website properly if we didn't do the foundational work? Companies decide to do websites once for two to three years. Usually the marketing team wants a new website, they get the budget, they find an agency, they do a new website and everybody is happy for a moment. But in the process of creating the website, there is no input from the sales team. Marketing has different KPIs - attracting marketing leads. Because of the lack of communication between sales and marketing in the process, salespeople don't understand that they can also use the website during calls. We had examples for early stage companies, some startups looking for product-market fit. A good website, a good landing page can be a very good asset for demo calls. Instead of creating presentations, they just share the screen and navigate the website, showing the journey.

Yeah. And the most ironic part is that most of that information is sitting there in the company - the sales team has those presentations. They know exactly what the ICP is, what they need. It's sitting there, but it's not leveraged for the website.

And what about HR? What about careers? You can also build for that to build the employer brand. We need to do a lot of education because in most cases we talk with marketing teams and we need to ask them to bring different people to the table because it's hard to get all angles. There's usually no person like you at Pipedrive - the person responsible for the whole landscape, the middleman between different departments.

Yeah, basically because the website sits in the middle of the company and it should connect all the different departments. You already mentioned those personalized landing pages and in the intro I mentioned the conference system you built. Could you dive deeper into that? Where did the idea come from? How was the process?

Sure. For background, I was attending the first Clay conference. Clay is a very interesting tool in the go-to-market space - I'm also a community lead in Poland and investor in Clay. They were having the first conference called Sculpt. Clay has a lot of angles when it comes to the tool. You can enrich information about leads, create content, do a lot of research. But in most cases, when you go to a conference like this, there are people doing lead gen and outbound. Those kinds of agencies, in most cases, they're not my clients. But their clients might need our services. So my goal was to be remembered as "this is the cool person who understands Clay, but also creates websites and knows how to connect those two worlds." The idea was super simple. When it comes to the system: it works like creating a blog post or case study in Webflow. You design the page once. You sit with your designer, create the Figma design, go to Webflow, build it once, and use the CMS. You define what variables you're going to use. For a blog post you have the title and content. But in this idea, I wanted to use variables like the person's name, company name, company logo. It's like creating a very good outbound message - instead of "hi first name," you have "hi Margus" or "hi John." The logic is: you build it once in Webflow, then Clay is your engine for enriching this information. During the conference, by the end of each conversation, we'd exchange LinkedIn URLs. By having that LinkedIn URL, I can have plenty of data points. When you paste this URL into Clay, Clay can go to your LinkedIn, enrich information, find the company you work in, find the company logo, find the company colors. So Clay is the research agent. And what's super important is that Clay works like Excel - you have columns. And columns are also important for Webflow because every piece in the CMS is a different column. It's like a database, but you don't need to fill in the information manually. When you have some kind of trigger - and a trigger can be anything, I created a small Slack app - I was pasting the LinkedIn URL, it was sent to Clay, Clay was doing research. And by the end of the research, there's an integration between Clay and Webflow, or you can use the normal API and HTTP requests. You send this data to Webflow and you have a personalized landing page. Three stages: build once in Webflow, do the research via Clay, then use that in the sales process. By the end of the conversation, after a few minutes, I was sending a follow-up on LinkedIn: "Hi Margus, it was great to talk with you. Here is my booking link." And instead of a generic Calendly, it was "pickout.com/sculpt/firstname." This is how you can use Webflow at scale, programmatically, without asking a developer to create each page.

And you are in this podcast thanks to this system you built. So I guess it worked. But another good example of how companies could use their website as a business asset. Most companies visit a couple of events or conferences per year. Instead of just sharing their homepage, why not do that? And sometimes it's not that complex and it's not going to take months to build it out.

Exactly, because you just build the page once and then you don't even need a developer to create those pages. And especially when you invest in events - offline events are costly. So why not prepare yourself to use the website as something that can bring higher conversion and create a wow effect? During the conference, your potential lead will talk with plenty of other competitors. So why not do something more? And it's always the problem with events that you can't really measure how successful they were. This is a good way to measure - you can see how many people are visiting those personalized landing pages. Really a missed opportunity for many companies.

Maybe let's discuss Webflow a little bit more. What changes when you start creating more pages at scale? Any limitations, quirks, problems you're noticing?

That's a super interesting question because I think the biggest Webflow limitation is not connected with the tool itself, but with the fact that Webflow is so open and gives you so many possibilities. It's super easy to go to Webflow and build something in a totally different way than the previous developer did it. When we are thinking about scale, the biggest limitation is having a clear system to build those websites and pages. When you have a smaller website it doesn't matter that much. But the scale will cause problems. If you have 100 static pages and you're not using a utility class for global padding - and then there's a quick request to make the container wider or the padding smaller. If you don't have a utility class, you need to click through 50 or 100 pages and change it manually. But you can do it very easily when you decided from the beginning to use one framework, one class naming convention. In my opinion, the biggest limitation is not directly connected with Webflow - it's working with code without having a proper foundation and proper documentation. The biggest problem, especially when one agency creates a website and then someone new comes in-house, is that this person doesn't understand how they built it, but creating a new CSS class in Webflow takes seconds and you can overwrite things. And then by the end of two years, there are 200 CSS classes loading that all do the same thing. I mention Client First because this is the biggest framework in Webflow, created by one of the best agencies in the world. This is like having a framework when you're building apps. If you don't have these foundations, you're going to have a big monster in Webflow that's super hard to manage.

Yeah, Webflow has a proper learning curve if you really want to do it right. Yes, you can open it tomorrow and start building, but to build it properly takes real expertise. The same thing happens - some agencies or freelancers build the website but they don't think into the future. What does this company need in two years? It's not the issue of Webflow itself, it's the culture around Webflow and the educational part.

And understanding that this is a professional tool. I'm not saying you need to be a web developer. You need to have some kind of foundation. Especially when you're a designer who got this promise that you can go to Webflow and build something without this foundation - of course you can create a decent website, you can tweak it, but the foundation might not be powerful enough. Maybe now you won't see this problem, but after 20 or 30 pages it will be a mess. And the mess is very frustrating because the best thing to do is a rebuild. The rebuild is painful for both the agency doing it and for the company - the company doesn't see the value because they're just trusting an agency that did an audit and said "you need to trust us - adding a new landing page takes us 10 hours, but after cleanup it'll take three hours. But to do the cleanup, we need 300 hours." These are very hard conversations because they need to pay for something where nothing visibly changes.

Do you see any potential alternatives coming? I know you mentioned Framer, but do you see something that might potentially change things?

I think there are two things. And I don't say they are competitors - I think they are tools for companies at different stages. On one side, there's vibe coding. Of course the design isn't perfect yet, but for companies just starting that want to look more legit and build an MVP, they can vibe code something and at the very beginning it will probably be enough because you're just looking for traction. Then you have Framer. Framer is very interesting because it's super focused on design. Companies that have maybe not perfect product-market fit yet, but understand what they want to present, and they don't need a very big website with 20 to 40 pages - they just need something they can iterate quickly. Framer can be very helpful because you work only with the designer. You don't need to wait for developers. Of course, the CMS isn't as powerful and there's no strong API yet. But for a company that just needs ten pages that are easy to control and have nice visuals, Framer is probably what Webflow was planning to be in the beginning. I feel Framer and Webflow aren't really competitors - they're going to cover different companies with different needs. I see companies starting with Framer and if they get market traction, switching to Webflow, because they'll hire a growth person, need content editors, need different seats. When you come to scale - multiple languages, lots of case studies, testimonials, resources, ebooks, you need a strong CMS and API integrations - Webflow will be the perfect tool.

Before we wrap up, I always want to have a "things nobody says out loud" section. What would you say, Brian, in your field - something that many people think and know, but nobody really talks about?

I would say that treating websites as a cost is something that is super deep in clients' backbones and they always treat it as a cost. But they understand that it can be valuable - in the past they had bad experiences with different agencies. The second thing is: we use websites every day as users, so we think we know everything - we know what the best hero section is, what we like and don't like. It's not like cars. When your car is broken, you go to a professional and you trust them. But with websites, even if you go to an agency, you treat it very personally. Especially when companies are smaller and you have a CEO who has been personally connected to the website from the beginning. We understand that we should give agencies free hands to create the website as an asset. But no one wants to detach from this very strong personal connection with websites.

What do people need to stop overcomplicating about B2B websites?

More focus on communication, less focus on tool stack. If you don't have proper communication, proper structure, if you're not navigating the user through good pages - having a complex service doesn't mean you need one very long page about the service. Maybe create divided sections and make the whole buying journey easier. Right now I see a lot of hype over tools, frameworks, Webflow, vibe coding, and we are thinking 10 steps ahead, but we are not focusing on building foundation first. Also, a video explainer under the hero is such a powerful thing. And it doesn't matter if the website is built on Framer or on Webflow. You need to have this asset. So start with creating the foundation, the structure, the site map of the website. Maybe take this budget and create a good video asset - a good explainer that shows the problem, shows the features. Then focus on whether it will be Framer, Webflow, custom build, or whatever. A good video explainer can bring you a lot of money to the table.

Maybe just quickly - AI tools you've included in your process?

Claude is our assistant in everything. We have different predefined prompts - for example, preparing for workshops with clients. We use AI to prepare ourselves, do research, analyze things before workshops, define what kind of questions we should ask. Claude helps us with brainstorming, structuring things, and also creating copy. Especially being an agency from Europe working with clients who aren't native English speakers, Claude is a very big power-up. We're always transparent that we use AI for writing content. In 90% of cases the copy is fine - clients from the US are just tweaking small things. Regarding Cursor - we use Cursor and MCP servers for creating CMS items without spending hours manually pasting page titles, meta descriptions, creating alt tags for images. You can write one prompt and ask to check if there are broken links in your build. We use the Webflow API. If you're migrating to Webflow from a different platform, MCP and API can be super powerful. My favorite use is creating small descriptions of fields in the CMS to make the experience super easy for clients. Instead of just saying "write heading here," you say "write heading here - the heading should be this kind of length." You don't need to do this manually for every client. If you define it once, you can do it at scale. And by the end of the day, clients are not paying you for hours that are not productive. You can use the same hours to create better video explainers, better animations, better design.

Love these examples. Last question - work you're most proud of and why?

Okay, we're a new agency and I believe the best projects are upcoming. But we had a few projects with very good client impact. We did a website migration for a Polish software company called Rigby - migrated from a custom build because they hired their first growth manager who wanted Webflow. Just by doing the migration and taking care of the foundations, organic search views in Google were doubled within a few weeks. That was very positive feedback from the client - and impact without even touching the content itself. We migrated the same blog posts but just took care of the foundation, prepared a better structure, took care of SEO foundations. Also, we had one project for a go-to-market agency where we connected Clay and Webflow. We created a content repository - like a Wikipedia about stablecoin companies because they were focused on that industry. We created around 300 landing pages in Clay, brought them to Webflow, and packaged it as a product. It was a lead magnet. They got over 300 leads from that. It was a new way to package content into a product that is educational and brings value. And I'm still waiting for the project where we have the opportunity to help a client with the whole journey - start with the foundation, create good design, add Webflow on top of that, add some content repository, create the whole engine. That's the project I'm waiting for and probably what I'll be most proud of.

Nice full circle moment - we started discussing how important foundational parts are, and now we end with you being most proud of the work where you created really strong foundations. Thanks for taking time, Brian. I loved the conversation. Thanks again, Brian. I hope it's going to be one of many podcasts we can do together.

For sure. As I mentioned at the beginning, two nerds that love websites can talk for hours. Thank you so much for the invitation. It was a pleasure.