Ramp & Vercel Fireside Chat

We were thrilled to host June's Chat8VC event alongside our portfolio companies Ramp & Vercel in NY. We were honored to feature Nik Koblov (Head of Engineering) and Nico Bevacqua (Head of UI / UX Engineering) from Ramp as well as Guillermo Rauch (CEO) and Lee Robinson (VP Product) from Vercel for a discussion anchored around the future of frontend engineering.

‍As a reminder, Chat8VC is a monthly series hosted at our SF office where we bring together founders and early-phase operators excited about the foundation model ecosystem. We focus on having highly technical, implementation-oriented conversations and give founders and builders the opportunity to showcase what they’re working on through lightning demos and fireside chats. This can be a fun side project, related to a company they’re starting, or a high-leverage use case within a company operating at scale.

If this conversation excites you and you’d like to chat more with our team about it or attend future Chat8VC events, please reach out to Vivek Gopalan at [email protected] and Bela Becerra at [email protected]!

‍ 

Nik Koblov (Ramp) :  My name is Nik Koblov and I run the engineering team at Ramp – I’ve been at the company since the early days. I was engineer number eight and met our CTO Karim in the fall of 2019. It has been an incredible journey from our scrappy West Village office to this incredible space. We're now over 800 people and are continuing to crank on all cylinders. 

Prior to Ramp, I was at Affirm in SF for three years. I built up my foundational fintech knowledge at Goldman.

Nico Bevacqua (Ramp) :  My name is Nico Bevacqua and I've been around Ramp for three years now. When I joined, there were four engineers focused on frontend. Prior to Ramp, I served as a Principal Software Engineer on the cloud team at Elastic. 

Guillermo Rauch (Vercel) :  Fun fact, Nico and I go way back. We've known each other from the JavaScript frontend community for many years. We're both from Argentina and obsessed with frontend. My name is Guillermo Rauch and I’m the founder of Vercel, where we provide the best frontend infrastructure for companies in the world. Our users are obsessed with the customer experience and prioritize offering a fast, delightful product to their customers. 

Lee Robinson (Vercel) :  I'm Lee! I’ve been a product engineer my whole career and amateur designer. I’ve been at Vercel for about four years now helping run our product teams and spend a lot of my time growing and educating the Next.js community, which is our open-source React framework. 

‍‍

BG (8VC): It’s very hard to structure frontend teams and define what culture and productivity means. The Vercel team published an exceptional blog post on what design engineering means. Let’s start by digging into the design engineering discipline at Vercel.

Guillermo: I love the design engineering function because it speaks to the crossover of two disciplines: design and engineering. For me, this has been the long-held promise of a lot of the technologies we've been working on like React. When React came out, there was this new idea of the component that became a unit of collaboration for the company. Designers historically had their mock-ups, sketches, symbols in libraries and products like Sketch and Figma. Conversely, you have the engineers whose lingo is mostly functions, classes, strings and other data structures. There was never a common protocol for those two roles to communicate.

The old idea was to throw over a screenshot and that was a unit of collaboration. "Hey, here's the screenshot, can you implement it? Just make it pixel-perfect." That was the designer. Then it evolved to, "Well, the designer cares a lot more about how to deliver or hand off requirements and ideas to engineers." With the launch of React, we now have the concept of a component so there's a common language. I wrote an article way back in the day called Pure UI that posited that because we have the notion of a React component, now design and engineers have an actual protocol. They can talk about state, properties and parameters. So now designers are like engineers and engineers are like designers. To me, that was a breakthrough moment. 

There’s something that is spiritually very enduring and it will not change with the fashion of frameworks – as an industry, we've coalesced around the standard of a UI component and it's really exciting. Design engineering is the function that specializes in its implementation – the implementation part is very important. A design engineer lives in the product and what is actually real as opposed to that illusion that something is going to be pixel-perfect. We've come a long way since then – the productivity gains are massive, in addition to the delight for customers and speed of execution once teams establish design engineering functions.

BG: Lee, can you share more about what you were doing in your design engineering and frontend engineering team two years ago? What has changed? Is there a north star you're sprinting towards?

Lee: Two years ago, we hadn't really embedded design engineering into Vercel’s DNA. Certain teammates were proficient with these skills, but we hadn't given them as much space to work, build and ship independently. I love that our design engineers have true product ownership – they will go in and find an area of the garden that hasn't been well-kept and make it better. We just shipped an improvement today of our product that hadn't received love in a while, and the design engineer went in and made full stack product, UI, accessibility and backend changes. They shipped the changelog for what the image looked like, got into the CMS, and handled the whole process. They operate top to bottom, just like a founder executor.

It’s invigorating to have folks like that who care deeply about the results and getting product out while maintaining an extremely high quality. Similar to Guillermo, I also felt like frontend development didn't get the respect it deserves. A lot of people thought that it was somehow lesser than and over time, the best designers I worked with throughout my career really cared about the details and the code. They cared about the implementation and the component model such that designers and developers could work together. Fast forward many years with powerful AI tools, it’s easier than ever for designers to learn how to code and build wireframes that actually work. Conversely,  engineers are learning more about the requirements of great components for design. The relationship between both roles has converged and therefore, expedited the design engineering function.

BG: Nik, you’ve previously mentioned Ramp frontend engineering is run very differently from backend engineering. Walk us through how these two teams differ. 

Nik: We’re slightly contrarian, but keep on proving what Keith Rabois once said: "Just behave as a cult." You believe in something so obsessively and ignore everything that other people say. From the early days, frontend engineering was developed as an independent unit. It’s also a function of people that we were exceptionally fortunate to be connected with – Nico included! Ramp is a low-process, high-trust environment. That DNA was established fairly early on into the frontend team. 

As we scaled, we were confronted with challenges such as divvying up ownership, especially as we became multi-product. Once we started going into e-commerce, accounts payable and procurement, we were forced to contemplate how to organize frontend engineers around this. Nico extended his agency and ownership to the extent that our backend tech lead on the card product, for example, could take a vacation and the frontend tech lead could run the business seamlessly. We always aim to instill a strong ownership mentality. 

Seeing you have co-founders that are engineers, agency and ownership has permeated across the organization. We have a forward deployed engineering team that sometimes gets embedded with our marquee customers that require customization. Given this, we treat the frontend team as the internal forward deployed unit that gets embedded in hard problem spaces where you need to partner with data specialists, applied scientists, backend engineers and designers. We created this cellular structure of agency – I trust Nico, Nico trusts Eli, Eli trusts people who work on particular projects within the team. High trust goes bottoms up and top down, empowering the team to do their best work. 

BG: Nico, I’d love to hear about the transition at Ramp from single product to multi-product? Perhaps you can walk us through the interaction and dependency on design, product management, the backend team and ops. How have you tried to evolve the culture, productivity and prioritization? 

Nico: There are two fundamental components – org structure and systems thinking. With regards to org structure, we built different frontend teams so the entire reporting org is basically frontend engineers reporting to other frontend engineers. This is something that Karim (Ramp CTO) inspired – he likes creating healthy tension within the organization that makes it interesting to collaborate and determine trade-offs. 

BG: How did you adjust reporting structure when you went from single to multi-product around flexible and malleable resources? Which one was static? 

Nico: We try to organize around small pods. There are separate units of organization, which are quite similar to Google’s Circle system. I belong to the frontend organization, but also am part of the product pod. Then we have some team members who float across pods – it’s exceptionally valuable to be able to throw certain people at nebulous problems or opportunities and figure out the 0 to 1. 

BG: What do you do about code ownership and fungible resources? Who stays staffed on a project and who moves around?

Nico: If the project merits funding, you end up hiring or transferring in a permanent person. There’s obviously a knowledge transfer period when someone new joins. Perhaps they stay on for a while or just a few months until they can fully roll off and move on to the next experiment.

BG: And what  SDLC changes did you go through for single product to multi-product to builds for QA versus dev environments? 

Guillermo: There’s a systems component as well as an org chart component. The systems component has been significant because we create frontend infrastructure that we give to customers as a service. Obviously, we dogfood it extensively to build our own frontends. It's a great hack that we have because we prove our own product through the experience that we deliver to our customers. The design engineering thinking is that it doesn't matter how appealing your design is if it doesn’t perform well. Performance is exceptionally important – we consistently measure ourselves against it. If someone is working on a frontend initiative at Vercel, they're deploying it on Vercel. They're getting a preview URL as well as a feeling for the product and what it's going to be like in the hands of customers. We collaborate a lot around this preview URL – it's like what Google Docs did to Word Docs.

It turned every Word document, edit, suggestion and comment into a URL. A heuristic for effective collaboration across the organization is this open flow of information, transparency and consistent feedback loop. We've now extended this to feedback from customers. So preview URLs are internal. We roll out product incrementally to customers and work on their feedback as part of the preview process. There’s a lot of overlap actually with the Ramp team in terms of how they manage product as well. It’s important for the frontend team to get the judgment of how the product feels for themselves. But a lot of us have these suped up MacBooks and then the customer loads you cold on Netscape Navigator in MS-DOS (which is impossible, but we deal with similar scenarios). It’s critical to get real-world feedback. 

Lee: We invest at every layer of the stack. From the framework layer (actual code being written), to the preview infrastructure, how you test and validate and stage your changes, and then also, of course, the production infrastructure. But in doing that and dogfooding for ourselves to help build our product better, we extract a lot of things that we inject back into the tools. So sometimes it's all the way at the framework level. We'll work with the Next.js team or the Svelte team, and we'll say, "How can we make the feature flag authoring experience easier? Wouldn't it be better if the programming model was framework native and framework aware as to how we define our flags, so that we could use them and not get layout shifts in our application?” 

When I get to the preview stage, I need some kind of tooling that is aware of my code as well as those changes. We built this toolbar that shows up on your preview deployments – it has the context and awareness of  all the flags I've loaded from LaunchDarkly or Statsig or any of these feature flag providers. And there's also a button for me to comment and collaborate with my team and share it with everyone.

Now I go into production. Well, you can use that introduction because we thought, wouldn't it be great if we had a staff toolbar that only rendered for Vercel employees? So when I go to the docs and I see that this section needs to be worked, I can just leave a comment and tag it. And then when I get a message that we're rolling out a new product, I just get sent a link that has the feature flag embedded into the link. So I get a deep link into our product that has a flag on it, which has just been incredibly impactful for improving our iteration velocity. And then we package all of that and we ship it to customers as our product.

BG: Let me bring it back to culture. Nico, you’ve created a distinct culture amongst your team. Let’s talk through this further. 

Nico: The confused_cat reaction started in Slack actually. Anytime someone would send a slightly distracting message, I’d share a confused_cat meme as it’s lighthearted. This joke started there and has now become a central tenet of our culture. The broader point is really not being afraid of being self-deprecating in favor of making the culture marginally better iteratively. And I think there's tremendous power in that. 

BG: Guillermo, coming back to culture, productivity and teamwork, if you look back at the last five years of Vercel, is there anything you’ve had to consciously change or evolve as a leader? 

Guillermo: We're obsessed with feedback and the flow of feedback. The biggest change is that there's overwhelming amounts of feedback, and we've had to create mechanisms to share, rank and summarize it. We're constantly in this battle, but it's a battle for ever-growing amounts of feedback and then distilling the signal from the noise. 

You have to aggregate and stack rank feedback. Open-source makes it even more overwhelming with Next.js having a million monthly active developers. You look at my X account and I have 20 pings a minute from, "I don't know how to do Y in Next.js." And I actually welcome and I love it – I'm always sorting through it and trying to understand, aggregate and establish patterns from it. But we've also invested in a lot of tooling around organizing feedback. 

Lee: I have a ton of respect for open-source contributors, maintainers and framework authors who are dealing with so much feedback from a diverse set of voices, whether it’s hobbyists or enterprise customers. The key challenge is figuring out the signal from the noise, which informs prioritization. And when you get to a scale that we're at with Next.js, it's a whole new set of community management problems to make people feel heard and to help that positively impact the culture of what it means to listen to feedback. We like to quickly determine what might be a fluke instead of a meaningful problem to guide how we allocate internal resources. Every flag is worth a quick pass – you never know if it might be the kernel of our next big breakthrough…

BG: There’s a Steve Jobs vs. Jeff Bezos dichotomy in approaching product scope as well as listening. Jeff Bezos has indexed very heavily towards being totally monomaniacal about going direct to ask the customer. In some cases, you have to be ahead of the game or make people think differently. Lee, you're managing and interacting with this really vast open-source community. How do you decide when to listen and integrate feedback vs. acknowledge receipt?

Lee: Going back to the framing of Bezos versus Jobs, you have to do a little bit of the immediate action of customers saying, this thing is busted, this thing is bad, it's not working out. It's really important to have the velocity in your product organization to be able to make changes fast enough to go back to the customer and say, I heard you and we made this better, even if it's 10% better.

What Jobs did really well and ingrained within the Apple philosophy is that they have a strong opinion about what they're building. They have a vision for where they're going – you need to internalize the north star over the course of the next 1, 5 and 10 years and govern the behavior to build that ecosystem.

BG: Nik and Nico, any strong philosophies around prioritization and how you listen to customer feedback? Any unique approaches? 

Nico: Velocity is exceptionally important. You really need to have a strong opinion as to how the product should operate and be used to ensure it’s not irritating for customers. Key point of differentiation is that most B2B products don't prioritize UX, but we put a very high premium on it. If you look at some of our recent launches, like travel booking, this is essentially a B2C product inside the B2B product.

This makes it a very interesting challenge – for a travel booking product, there are so many data points that you could squeeze into a screen. You need to be opinionated on what matters to the person booking a flight. Our approach entails having everyone care about the user experience in the company. We started a project that is called Project UX where we have inputs from customers, sales reps, our engineers, PMs designers – everyone's commenting on copy, how design could be improved etc. It’s a very bespoke process, but requires velocity as well. 

BG: So Nik, let me throw you a curveball. During our last conversation, you made a directional comment about promotions, which is often challenging to approach. In front-end and design engineering, what is the criteria for impact? Is the criteria very different from an AI or database engineer compared to front end? How do you determine impact?

Nik: I actually spent an hour with our Head of Design this afternoon reviewing both orgs – we aimed to determine how to grow both designers and UX engineers. It’s a hard problem, which stems from the fact that these professions are extremely craft-based. As the organization scales, there's a natural tendency for individuals to measure progress by managing large teams. In the craftsman-based professions, it's quite different. If I throw five extra designers to a very talented designer, is this a force multiplier or am I getting over the reverse inflection point where the velocity of the team and the quality of the output is going to decline?

There are different archetypes as well – there’s the craftsman as well as the nurturing, listening manager. You need to figure out what persona you fall under and be open to switching as well depending on your superpowers. For example, at the start of my career I never wanted to manage a team. This is the largest organization that I’ve managed in my whole career – every day I'm scared and humbled. 

BG: Guillermo, Vercel recently launched v0. I’d love to hear more about the philosophy behind v0 as well as the types of generative UI adoption you’re seeing. 

Guillermo: First of all, I’m glad we're not just talking about AI as a hot entity to be optimized because the main idea is that you're building amazing product experiences. Then, you work backwards to apply AI if necessary. Perhaps you make something really fast – this might take trusty front-end engineering that creates a snappy UI. But then it might also leverage AI because you're navigating a complex information system and want to auto-populate or suggest a bunch of data to the customer. You ultimately shape latency not just in the classical software engineering sense, meaning there's a bunch of transactions you're shaving off and optimizing. There’s also the total holistic time – for example, I spent five hours a day doing this thing and with AI I could have spent half of it.

That's the mature and positive way of looking at how to embed AI into products. This is when we came up with the idea for v0. As the name suggests, v0 represents the analysis paralysis or writer's block moment that every person has when creating something new. You don't want to start with a blank canvas. You have an idea in your head and want to translate that idea into reality. Anytime I have a free moment, I try to dogfood our products and create front-ends. How awesome would it be if we could get to that v0 faster. We’ve learned there's a clear opportunity for AI to enhance everything that we do. v0 is the tip of the spear for us in terms of introducing an AI native product.

The most significant learning is that every other function at Vercel can be enhanced with AI, especially support. We cut down ticket numbers roughly by 10% Instead of users hitting a wall and not being able to proceed, we handled refusals and the ability to file a support ticket easily. We then found a similar instance with documentation searches – helping the community learn Next.js is a huge frontier opportunity for us. Learning has actually been at the heart of everything we do at Vercel. The secret sauce of the growth of Next.js has been how much effort Lee and a bunch of people in the early days of Next.js put into documenting the education materials of the framework.

We always had this attitude that everyone can learn Next.js. We try to always explain it from first principles. Some of the hardest jobs in computer science are people organizing documentation and clear product explanations. 

With AI, we can make the learning and documentation process entirely generative. There's a ground set of facts that are the new things we bring to the world – we call this the frontier data of Next.js. It might actually emerge from an open API spec or even just parsing the code. From there, we can create generative learning experiences for any skill level together with v0 generative UI experiences. While I'm teaching you what an effect is, I can actually render an example just in time with a button you can click. We're taking v0 and making it incredibly accessible and intuitive such that it doesn’t even feel like AI. It's just a natural extension of how we do everything ourselves.

BG: Lee, you’ve mentioned the AI SDK release. What are the top three features there and why?

Lee: The big idea is that when you look to build a TypeScript AI application today, there's a ton of great models you can choose from, but they all have slightly different APIs and SDKs. Setup for each is also quite distinct. Some support function calling or tool calling, some don't – the requirements are all different. The AI SDK is trying to be a bridge to any model provider. It makes a one-line function call, one-line code change to move between them and provides great utilities that every AI application needs, which is streaming back text to build your chat-like interface and generating structured data. 

If you think about a Ramp use case, you might want to have a text input that can allow the user to talk about their expense report. However, the format you get back actually needs to be a JSON because you want to pre-populate some filters or information and it expects a certain schema. You get a Zod schema that allows you to say, “here's how we want the data to come back.” Let's use the power of an LLM, but it has to conform to this spec. And we want to add a lot more utilities to make working with AI models easy, whether it's a local model or whether it's any model that you would prefer to use.

BG: Nico, I’d love to hear more about AI applications at Ramp. 

Nico: My answer is pretty similar to Guillermo's in spirit – for us, it starts with the use-case. You don't want to throw AI at everything, but more so how can we apply it in a way that benefits the customers and gets them excited? The Ramp tour guide is sort of an experiment where we are trying to also reduce the burden of support and increase customer delight. If you just take the query from the customer and instead of getting a help center article, you're shown exactly what steps you need to take to complete that action. It’s delightful, especially as the responsiveness continues to improve.

Audience Question #1: The way in which Ramp applies AI into the product is usually subtle. What do you think are the bottlenecks in terms of moving from a product that is enhanced by AI towards a product that's actually AI-driven and reflects this not only in the interface, but the way the product works? Is the bottleneck on model performance? Is it suboptimal for different products?

Guillermo: What you were just talking about is quite profound because the idea of guiding the customer has been a successful technique in GUI software for decades now. AI, when applied correctly, is actually bringing transparency to the processes that it's automating, which is actually contrarian to the vision of what you would call AI-driven, right? 

In order for something to be truly entirely AI driven, we have to get to a point of reliability in the systems that is not there yet. In the absence of flawless AI, you have to take the user on a journey and be very transparent each step of the way about what it is that you're doing.

I always call out that if you look at the broadly deployed successful commercial AI products, they all involve humans in the loop in a way where the human acts as the editor and accepts a suggestion from the model. This continues to be the way we can get AI to production. Being realistic about the current state of technology and establishing the right expectations with the customer is how you get to a successful outcome.

‍Lee: We’ve been talking a lot internally about this idea of an AI native user experience – for a lot of products in the market, nobody has designed this yet. Few know what the AI native UX of this product vertical looks like. In a lot of cases, I don't think the technology is there yet, but we can start thinking about what it might look like in a world where we had the reliability we needed or we had the latency or consistency requirements that we needed. Groq has made an interesting entry here. You can get a response back in 200 milliseconds. So for certain UIs, that can make a massive difference. I know a lot of other models are also catching up on speed, but reliability is the difference between actually going all in on an AI first UX versus augmenting the existing experience. It’s worth still thinking about and designing towards.

Audience Question #2: My question is a bit philosophical, but if you look at the web development evolution, we started with static pages and then had Backbone, Angular, React etc. I really enjoyed a single page application. Then everyone was like, "Oh wait a second. It does not work with Scrollers, so we need to step back and we have server-side rendering." Is there anything we stopped using in the last 10 years that should be brought back to life? 

Guillermo: When Google came out, a lot of the other search engines were creating overwhelming amounts of UI because they had sports results, white pages listings as well as a ton of news. The search input was part of this overwhelming amount of information. When Google came out, they were like, "You know what? We're just going to simplify everything and revert back to the query." If you look at the success of ChatGPT, it’s a nod to this. 

In fact, something they had been surprisingly bearish on is overwhelming marketing websites because in the age of AI, you want to short circuit to input. Capturing input is the most important. I do think more products need to personalize experience to reflect the level of competence and experience of the user and their preferences. I don't think we're there yet. When I come back to most products, I'm actually always getting the same thing again and again and again.

It's almost like they're context free. What actually makes AI really useful is populating into the context window. We're missing the AI context you can pass from application to application. And of course there's a ton of privacy implications to this, but the web will become incredible once it's completely generative, which goes back to your insight about server-side rendering. Server-side rendering is actually there in the service of creating a spontaneous response just in time to a request. It’s somewhat unclear how we get there, but just-in-time personalization of every experience could really catapult the web into the next level.

Nik: That’s spot on. If you open the Ramp homepage in a couple of months, what Guillermo alluded to will be in production. Predicting user intent is key. Going back to the most natural interface between a human is actually the biggest AI lift, which goes back to original Google simplicity. Especially from the design standpoint, we need to be able to handle bad questions and figure out intent. It's a combination of personalization, simplicity as well as capabilities of the language models on the backend.

Audience Question #3: I’m interested to know as you're building businesses that are selling to consumers as well as businesses with a very wide range of technical backgrounds, how does your design philosophy change to account for that?

Nico: It really depends on what your ideal customer profile looks like and then working back from there. Usually you should not assume that your customers are going to be very tech-savvy. That’s the mistake that happens a lot where people assume every customer is incredibly knowledgeable about the product that you're building. You need to build products that are very explicit in what inputs they need and make it very obvious what is to be filled out to provide the outputs that the customer expects, broadly speaking.

Nik: There's a natural human tendency to build for your existing users who are great at your product and people forget about the new users. You kind of grow this sort of silent, frustrated majority in your user base that might result in churn or misunderstanding of your product behavior. In addition to obsessively interviewing customers, it’s critical to be very honest about who you're building for and whether a user can easily figure out how to use the product on day one. 

Guillermo: One of the things Lee consistently pushes for is maximizing exposure hours. Your job if you're working on product or design is to maximize exposure hours. Maximizing exposure hours entails studying people who use the product and conducting a very simple test. If they are confused you likely will need to redesign.  Even just watching someone  onboard can challenge all these assumptions in your head because you’re an expert in your own product. 

At the last Vercel Ship, we said, "You know what? We're going to stop drawing pixels of UIs. We're going to demo every single product and feature that we're going to announce. If a team doesn't have confidence in their ability to demo it, then it doesn't make the cut." So it becomes a fitness function. Can you demo this thing? And by the way, it's totally okay to embarrass yourself. We have a safe embarrassment space, also called Friday demo days. You can join this Zoom and embarrass yourself in front of the entire company demoing something that's going to break.