Building Banani: How a Canvas-First AI Designer Is Raising the Floor on Product Design

Welcome to Just Now Possible with Teresa Torres. Hi my name is Vlad, I'm CEO and co-founder of Bananie. In my previous life I was a designer for more than a decade since I was a teenager, won a few competitions from Telegram, when I was 18 joined one of the fastest growing Ukrainian startups Preply, where I essentially became a lead designer, tried product management and yeah for the last few years I've been together with Vova. We're building our own products and are building our products. Hello my name is Vova, I'm co-founder and CTO at Bananie. I'm building product here and I'm responsible for every technical decision. Before that I was building almost everything that is possible, like starting with trading bots for stock markets and creating applications for augmented reality and eventually I've met Vlad and we decided to be co-founders and this is how Bananie started. Hi my name is Vlad, I'm founding growth at Bananie, where I am responsible for acquiring, working with our customers to solve their problems and retaining them. And in my past life I've been with Google, where I was doing marketing and investing in startups. Excellent. Okay, so tell me a little bit about Bananie, what does Bananie do? Yeah, of course. So essentially we try to build AI product designer, because audience know how hard it is to design user flows, come up with best UX solution for certain feature, new hypothesis and so on. And in simple words, we try to automate big part of the design process and help you get to the great and beautiful design much faster. This is where we are, but essentially our goal is to build a fully autonomous agent that covers everything related to design inside your company. Something that can be your creative companion, if you're a designer yourself and you still want to design things manually, yeah. And we're roughly one year old, but already at the scale where hundreds of thousands of design is generated per week and yeah, have a lot of cool stuff that we already built and that we're building right now. Yeah, I'm excited to get into your story because it's a very unique product compared to what we've had on the podcast previously. Vlad, I'm curious personally from a founder story, you were a designer. I'm curious what motivated you to create an AI designer? Do you have any fears about putting yourself out of a job? Frankly speaking, I think I dreamt about something like Bananie when I was designing myself. So I had experience working like as a freelancer later on in startups that went from seed to I don't know, CDSB, CDSC. And there are a lot of parts of the design process that are mundane, that can be automated. We together with Vova before Bananie, we actually were building a consumer mobile app, an ecosystem of consumer mobile applications and together we saw how design can be also a differentiator for your product. So this is one of the things that kind of was constantly brought up by our previous users in that startup. And yeah, we just want for the world to have more access to get to the great and quality user experience, user interfaces and yeah. I want to add that it turned out that with current product, people also share with us that the way our product looks is a differentiator because it is so easy to use compared to our competitors. Yeah, this is something I'm really bullish on design being a differentiator in the long run. Like I actually don't, even if we have AI designers, I'm not convinced we won't have human designers. I like this idea of can we raise the floor? Can we improve the quality of design overall? And then maybe that allows designers to focus on the harder, more interesting problems rather than just the next workflow that we've done a hundred times. Yeah, exactly. I think there's kind of irreplaceable parts on the human side, which is empathy, being able to dive deeper into the problem. But as I mentioned, there are also like me having experience in Preppy where at some point it was only me and a couple other designers for a 60 people product engineering team. Sometimes you just need things that can help you go through creating thousands of screens in a day. And yeah, this is one part of the problem. And as you said, raising the floor is also a big part of that. So nobody likes to use bad products and there is a lot of conversation about AI slope and how AI essentially turning everything into something similar, something that's not looking good. And there is definitely a big aspect of that in the current execution. That's what we're trying to solve with Bananias to make actually something tasteful. But also if you look on the market, on the media and on the markets, there is also human slope and there is not a lot of conversation about kind of what is average experience where it was like average system. Obviously, there are cool examples like Linear, like other products that are beautifully designed, but if you take on average, oftentimes also what we see from our customers, like solo founders, early entrepreneurs, smaller startups, they simply don't have access to the talent, to the skills. And yeah, I think there is a lot of exciting things coming from different directions. In the taste bar and the market, but also kind of helping people who previously could not be able to do things that they can do now. Yeah, that's great. Okay. So I am hearing a very clear need and like really driven by personal experience of how do we just have more beautiful products, more really well-designed products for those designers that are stretched thin at so many companies. How do we help them with just producing more designs? How did you identify this was a problem that AI could help with? We clearly saw that AI is definitely can help here. I think we were just aware of the fact that like we were at the right time because like GPT just recently dropped and we understood that AI is going to evolve. Like it's gonna evolve into something huge. And this was one point. And I think second point was the fact that before GPT and LLMs, you had to be a real math scientist to kind of work with AI. And this was a really important thing because you needed to understand statistics, probability and stuff like that. You needed to know how to build all of these models on your own using Python and stuff. But suddenly everyone could start building their own stuff. And what we saw is that even though, as Vlad mentioned, we don't really know till now if AI has like their own style and understanding of like emotions and empathy. But what we clearly saw is that in design, you still have a lot of automations. So we understood that we can try at least solve those problems and then we could try to see like how we can utilize it better. Because eventually at that point of time, when we just had an idea, we, I think we wanted to have like a big community of real designers who would design a lot of cool, unique and experimental stuff for us. And then we would try to do some machine learning stuff and train our own models and build really unique designs. But it turned out that the way how LLMs evolved, how big companies developed them. And I think right now it's more of the question like how properly you can utilize everything and if you can keep up with the market. Basically for a lot of companies and products, there is kind of a right time when technology is available and enables to do certain stuff. For us, it was definitely LLMs and we kind of saw in different areas what they can already do. I think the first proof of concepts we were doing like two years ago, a year and a half ago when we were just like playing and looking at what can be done. And just seeing from the, we already knew the problem space quite well at that point. What are the problems of product teams, of designers? Once again, we were building a 10 people team that we built in our previous startup, like both me and Vova and like I had experience in the product team. We kind of knew the problem space and main bottlenecks, I would say, but back then tech was not ready. And we saw a lot of demos on the coding side that something is finally possible. And it wasn't the question if it's AI product or not AI product, but more is it already at the, is AI already at the point where it can be actually applied for this type of stuff that we wanted to experiment with. And yeah, we had multiple iterations to make it work because two years ago, base foundational models where they were completely different beasts and things compared to what they are right now out of the box. And yeah, back then you would need to do a lot of kind of workarounds to get to some at least like basic good results. This has been a theme on the podcast of, for a lot of teams that started early in the GPT phase of like how much they had to do that the model kind of ate up over time. As the model got better and better, more became, that's the name of the podcast, more became just now possible. So I really like this mindset of you knew your problem space, you saw this new technology, you could see how there was an intersection. Building an AI designer sounds really big. I'm curious about what was your first step? What was the first piece you decided to focus on? Yeah, as I already mentioned, we made proof of concepts to just see if it's feasible to do design generation. Yeah, it was, we built on top of existing platforms. Our first kind of working product was plugin for Figma because we just wanted to purely test how generation works without kind of app player infrastructures that is required to render all of this, give you more advanced features that we basically have inside our products already right now. Yeah, so the first step was building proof of concept of if design generation can work at all and if it can be good because even in the days of GPT 3.5, I think 3, you can already generate some basic HTML pages and layouts. But once again, we did some shenanigans and orchestration to get it to some base level where it's possible by real designers, by real product managers and where it actually brings value and can be used. And from there on, after validating that the tech is feasible, validating that we just for this simple Figma plugin, we receive organic users. It was the first signal that, okay, we can try to build a full on product that takes more and more pieces of the work and kind of reimagines the whole workflow of how you design stuff. I wanted to share my personal feeling about that because even though we were building this Figma plugin, for me, the real aha moment was I think when we came up with an idea of we can write a text prompt to generate on the first screen. And then if you can click on this design, and this would call like some function and next screen generation would start. So basically, you can generate the whole flows, but you need to write on the first description. That was kind of my own aha moment of our own product. Yeah. So just to make sure I understand that, that your customer would start with, here's a prompt of kind of the screen that I want. Your product would generate some HTML, some CSS that would produce the design. And then from there, they could click on the design and that would generate the next step in the flow. Yeah. That's very cool. Yeah. So that was like Bobo prototyped this feature and this was, once again, we were just poking around ideas, how things can be re-imagined for kind of this new workflows that we have. And yeah, after also like getting feedback from our users that, okay, like this is something cool. It was also like a nice signal for us that you can bit by bit start introducing new interactions that currently not available from the UX perspective. And yeah, that there is quite big space to just, once again, re-imagine the workflow outside of putting the chat box into familiar product interface. So yeah. It also sounds like that very first prototype, you stumbled into a really nice distribution channel as well of the Figma plugin helped you find your earliest customers. Is that true? Yes. Yes. So that was essentially our first growth channel before we full-on switched to our own platform. Yeah. Like we're quite fortunate because most of our growth is fully organic, so it's 95% just by word of mouth, integrating into existing workflows, starting from the integration with established product that is being used to solve the problem that is used by users who have the problem that we're trying to solve. It could backfire you. For example, Figma started playing very dirty lately because they're scared to lose market share. So they started very heavily rate limiting their API and essentially putting a lot of sticks into the wheel for like competitive like sub products to start. But yeah, definitely like I would recommend in the beginning, trying to find like some distribution platform place where your users are and like find a way to kind of start from there. Yeah. I think one thing that's in the back of my head is that you're playing in what's now a crowded space. It may not have been that crowded when you started, but we have probably half a dozen pretty big like prototyping tools. Like Magic Patterns comes to mind of just focusing on the design piece. One thing I've heard as you've talked about your product is it seems like you have a very this in a positive way, like a very opinionated view, right? Even this piece of you can click to generate the next frame to me is it seems like you're taking a design mindset to this. And I'm wondering if you've talked about as this space gets more crowded as Figma moves into this space, which is the behemoth here. How do you think about what's your differentiator? What makes your product unique? I think what we internally see is that the problem hasn't been solved to the level that we see potential to be solved. I don't know how to frame it the other way. A lot of tries from different sites. There's a whole new market of pipe coding tools is also used for prototyping. On the other side, you have a code that more and more designers start using, which is extremely cool thing in my personal opinion. And on the other hand, we have Figma, which tries to kind of integrate pieces of AI inside their product, but none of them and their direct competitors like Magic Patterns, but essentially nobody solved the problem of generating actually like good, tasteful, beautiful design. So like where the model is understanding the main concepts of how things should look like, it could replicate your brand. And second piece of that is kind of app player. Nobody solved the new way to interaction, to creating design. Once again, Cloud Code and pipe coding tools, they're very unnatural place for designer and product people to hang out. That's what we hear from our users. You want to have the freedom of chatting with an agent, exploring different variations and so on, but you also want to keep the UX of the canvas and you want to have some new ways to generate designs and screens and so on. And yeah, like nobody solved it correctly yet. And the good thing here is that the market is extremely big. The purely product development, product design market is growing very hugely. Dramatic shifts can happen in a couple of years. If you look at the example of Figma, for example, like it's... I think, once again, this is not like, we really respect all of the competitors, but we're gonna have matching patterns and other stuff. They pretty much in a lot of ways developer-focused. Today, to give you an example, we had a big internal discussion, okay, how we should implement reusability and components. And there is kind of a natural pull to adopt the development and coding paradigms. Like when everything that you create is already a component, you're essentially moving the easy way of what agents are capable and trained on foundational level. But it breaks the established behavior of designers, of product managers, who still need a lot of like specialized tools and interactions for themselves. So once again, kind of long story short, like we see that the market is huge, the potential to kind of change the workflow is huge. Nobody yet solved the beauty taste plus app layer combination where it kind of disrupts the space. Yeah. You might just realized as you described this is being a canvas-first tool is already a very big differentiator, right? Like a lot of these tools you start with a chat window, it's producing code. You see the design almost as a static thing. It sounds like from what you described, your users can add elements to the canvas, edit things directly, and there's this AI component on top of it. Is that correct? Yeah. Like we try to every day there is kind of a question, okay, what things we want to hand off to AI, what part of the work we still want to give user the ability to do manually. I think that's kind of what a lot of AI first products have in mind right now. It's kind of how far you go one or the other side. So, yeah, like your summary is pretty correct. But just add to our long-term vision and goal, like we, because there are like multiple layers of the product, there is kind of a part that is doing generation, like orchestration of the actual AI, how it makes the decision to generate something, to use some component, to use some color. There is a big part of the work happening on that side because from the same model, you can get completely different results with different, once again, agent architecture and tools that it can use. And second big component is like app layer and like actual interaction. So, yeah. I think there is one core question that we come back in the team frequently, which is what if the AI is not here to replace, right? The product designer in general, but rather to be autopilot where the designer is still in the driver's seat, but when he needs or she needs to, to switch to autopilot, they can do it, right? And this is the way we are trying to design banana and a lot of features. They are coming from this perspective, right? So the variants and the ability to spin off a few variations and then take it from there. This comes directly from designers who really want to have this perfect balance of control versus AI. Yeah. This is a pain point I hear a lot with the prototyping tools, even just getting it to use the design system or their component library. I remember when Lovable finally let you like click on something in the design to just change a label on a button because it was such a nightmare to try to get the agent to do it correctly. So I can definitely see the power of letting the designer drive with the canvas and then using the AI to augment and then let the designer decide, okay, generate this next frame. And I can even add to that, that like, depending on, that's the thing about design processes is like on different stages, you need different job for AI from AI. So for example, like when you kind of in early exploration stages, you need AI to be like more creative, help you spin up like multiple different, like even visual variations if you're just like starting the products from zero. And kind of, you maybe need some help in brainstorm and stuff. And like moving on to the later stages when you have something established, you want the agents to be very flexible in reusing what you have. And on those like different stages of even like when you prototype and come up with some new feature, like you might need a different kind of degree of autonomy and your involvement. So for example, when you already have PRD of the feature, we don't want you to spend the time and you already have like components system and like example screens. We don't want you to just waste time and kind of manual labor of assembling the screens. Like we, we want to have like full-on autopilot where you can write in, this is not something that we have, but something that like we plan to ship relatively soon. Like integration into your workflow. So you can, when you trust the thing to do and like prototype some flow where there is less uncertainty, you just tell it to do. And like you then have a link or like images in Slack that you can see. But when you in these early stages of exploring, you want to have more degree of control and kind of involvement and like actually use the product to do things yourself. That's like another thing that we basically see not solved yet. And all parts of the design process kind of tried to be treated the same, but when in reality they are not. Yeah. Yeah. I could see a ton of time savings in that sort of production step of like the thinking part of the design work is done and now it's just, we have to skin and use shared components and churn through all the screens, which I know is not most designers favorite part of design. Yeah. Okay. Let's get a little bit into the technology here. I can see how in some ways I can imagine how you could start small with, you have AI that's generating code and there's already a model for this in terms of like other products have done this before. Generating code is one of the easiest, was one of the earliest like use cases for models. But I also feel like this has been one of the hardest areas for models to do in a way that just doesn't look average. And something that I've heard in everything that you've shared so far today is that you are aiming for high quality design. And so I'm really curious, like how do you think about this just architecturally? How are you getting, what do you have in place that makes this, makes sure that you get that higher quality design? I think in a lot of ways, yes, like it, it's relatively easy to get some, something average out of the box, but it's, it takes some trial and error, just playing with a base model with a context to get to some level where it starts to follow some of the initial design principles and guidelines. So there's like quite big room just from the context engineering that you can get from the base model. But this is if we are talking about 2026 state of the AI models and agents, because once again, a year ago, like nobody, like I don't remember a year ago, agents like existed and like tool quality. Right now it's more about, once again, what kind of specialized tool you can give to the agent. So it produces something better quality. So for example, if you have a plain code an AI assistant, yeah, you just can't afford to give it tools to, I don't know, go look up for image references for the designs. And given a lot of more specialized, not skills, but actually like tools to AI that help the job to the end design to, to look better. And there is, we don't, there is no like easier way outside of just trial and error. We experimented pretty heavily on all stages of the company. And like, even right now when, like when each new model comes out, you need to get a taste of, okay, like what it can do, where it's good, what things should be kind of fixed with additional context engineering, with additional post-processing. And yeah, to give you an example, like early models, they were quite bad at some alignment problems and like other stuff. And like you try to find workarounds, okay, how in current state you can fix this with post-processing, with some additional things built on top. And yeah. Yeah. What other thing is that we see is that design is very, once again, like just coming back from the human process, it's, it has its own special needs. You have a parts where you kind of just on the research side, like you decompose and stuff. You think about the user persona, all of the stuff and like, you can teach similar thing to an agent, given it specialized things so it can produce the job better. And yeah, another big aspect is just experimenting with different output formats. If it's plain HTML and CSS or with like some specialized schema. So for example, we tried multiple approaches moving on from very predefined component-based generation when it was highly curated by ourselves because like we trust in our own taste and kind of experience of how things should look. So this was like one of the first approaches where we were just reassembling components that we made on our end. And like we were asking LLM essentially, it wasn't even a code or it was a markup that we came up ourselves and that we later on rearranged. And, but with each model leap, you have new unlocks and you need to rethink, okay, what's, what should we remove? What should we rework? And yeah, current approach is like that we use completely different from the one that we had even like in July. Yeah. And I think one of the, like recently we integrated image generation directly into like main design generation process, which is another big component of visual style of how things look aesthetically. And there are like so many smaller things where you can make tweaks and tune the system as a whole for it to feel a little bit more tasteful, a little bit more beautiful. And yeah, what we see That's it. Super easy, and I think this is why people love it. But what we want to introduce is that special kind of looping mechanism where if the agent clearly understands that it doesn't understand you, it can ask you a question. And it also a bit complicated to kind of describe from the agent perspective what it meant to. So I think what we want to do is to kind of maybe highlight something inside of your canvas, highlight specific element on your screen, on your design, like, do you mean that and do you want to change it in that way or something like that? So I think this is as a step one, can work pretty well. Yeah. Yeah, I can see that being both ways, like the user can highlight something on the canvas and be like, this is what I'm referring to, and the agent can highlight something on the canvas to confirm. We already have something like that, because even though you're working with the whole screens, but we have a special function that is called select, and you can basically select the elements and describe what you want. And basically, the agent would know that, okay, user mentions specifically that part of the screen. Yeah. There is also another aspect to it from the behavioral standpoint. The users frequently, they don't even want to go that way where they select the element. They want to have a very quick ability to choose from predefined actions that they have in mind. And basically, the way we worked with that, we've found, I think, seven or eight actions that are most used by our elements. And we now give the users the ability to really quickly in two clicks fix what they don't like on Canvas. It's like what I have in mind is that you have your canvas tools, but you also have your agent toolbar. I don't think the canvas AI interaction has been, once again, we didn't even scratch the surface of what can be done specifically with this interface. There is a cool demo from off-topic, but there is a cool demo by a founder of TL draw. It's an SDK plus whiteboarding platform and they do interesting side quests for TL draw. And he recently had a demo where you essentially have a Ferris that you can send to do a specific task on Canvas. And it's almost as if you play like a computer game where the strategy computer game where you select something, you send something, and that's once again, the cool thing, what excites us is that there are so many ways to implement this stuff outside of regular chat box on the left side of the screen where you kind of just like tell it what to do. And yeah. I feel like the UX of like, you get to interact with a canvas. I'm assuming you can also talk to the agent. Is it both? They can mix between the two? Right now, no, but soon it will be. We initially started like that. You had essentially a chat where you could have back and forth conversation, but we quickly found out that, so what else for the context, like we have users who have hundreds of screens on the canvas. And it's one thing, it's hard to maintain and allow parallel threads of editing to be happening at the same time when you also need to maintain mental model of, okay, I have chat with this thing, like where is this chat stored? So there is compromises you need to make on the UX side. So for now, like we, at some point we decided to just kill off this conversational state to allow parallel for our agent to essentially do a lot of stuff in parallel. But right now, like we right now exploring the ways how we can make it back to the platform, because I think from the user interviews, we constantly see people just having ChatGPT on the side and like talking to it and then like copy pasting like some of the like specifications that ChatGPT created back to Banana. And yeah, it's a recurring pattern, so it gives us, once again, another indicator and signal that we should play around that area. But yeah. But underneath it's essentially, you can imagine it doing all of the thinking you have like in Claude or in ChatGPT where you use thinking models. It does all of that, but without over blowing you with text information, because once again, you're really focused on a lot of the visuals that are happening on the canvas. So the user is primarily interacting with the canvas. Yeah, like you have a prompt box that's where you can type the prompt or like we have a quick actions that you can, there are like two ways. Like you can, one way is to use the prompt inside, but also we fully support you designing without any prompts. So as what previously said, we have like variation shortcuts, you can click on the screens. We get your feedback if you dislike something and like launch regeneration from pre-selected options. Like you didn't like the typography, you had some alignment issues. So we try to keep both ways of interaction, like trying to intertwine them a little bit. But yeah. Okay, let's get into the hood a little bit. Like I think you, you have this really great UX experience of everything is being driven through the canvas, but you have a prompt box. I've heard you several times refer to the agent, but, and I've also heard a lot about tools. So let's talk a little bit about what's happening behind the scenes of this canvas. What, tell me a little bit about your architecture. Okay, so like, I think people sometimes miss, to be honest, what is real agent and what is not. And they expect to see like something as a message history or like agent communicating to you or asking you questions or stuff like that. Like event, the agent is just a type of architecture. And what it does is like, if you ask it something to do, it might take multiple steps to accomplish this task. It can also loop inside of like this agent itself and then come back to you with a response. And so the way our agent works is that we have like a couple of steps before we start generating and after we finish generation. So first of all, we need to understand what exactly we are generating. Is it like a full plain screen and we're generating it from scratch, or do we need to make some edits? Then we are trying to understand like, okay, is there anything we can get from the project or maybe from the user, like some themes or some references or stuff like that. And we are making our agent like to start this reasoning process of, okay, what should I eventually generate? And we start streaming. At the moment when we start streaming, we are trying to it to our users, because I think this is kind of tricky part. And when we are talking about our competitors and what differentiates us from them is that they all are building applications under the hood. So everything that you see rendered is just real application. But what we are trying to generate is just like a mockup, even though it's just an HTML and CSS. And that is why we can make your experience a bit like interactive because you're not just waiting and seeing like loading spinner or something like that. You actually see how your screen is being generated. And I think this is really cool. So another thing that we have inside of our agent is an ability to split your prompts into multiple steps if you are asking to make some changes inside of an existing design. So basically, imagine that you have a mobile application like Instagram-like, and you have there your profile page stream. And you ask like, okay, can you change the avatar from rectangular type to circular type? Can you change the font size of my name and can you change how the row of images look like? Like not three images in a row, but four. And so instead of regenerating the whole screen, our agent would split it into different steps and it would kind of inject these changes directly into your screen. And you can see it also being streamed. And in parallel, we also generate you images. And what else? I think that's it. Yeah. I hear a lot of parallels with Claude code, right? Like I'm generating my to-do list. I'm working through it. You can see, but for you, it's not I'm editing files. It's I'm editing things on the canvas. It might evolve into something like editing files, but yeah, I think the main difference between like our agent and Claude code, for example, is that for us, it is extremely important to save all of your session history. So like in Claude code, you can just open new tab and you work in the same code base and you're typing and you're like asking for different things and you can experiment. And like if you accidentally closed your tab, you lost all of your results. For us, because like each step in design, it was your own decision. And if you like created something and it didn't work, and then you like kind of disliked it and then you duplicated stream and asked to make some changes, we want to see every of these step inside of the history. And we want to share it with agent because this is how your like decision change chain looked like. And this is really important because like, even though if the agent generated you something and you didn't like it, you can ask to revert because we have all of the history. So it's kind of similar, but only because we are not generating applications, we don't really need all of the stuff that Claude code has under the hood. And so we are trying to utilize all of the capabilities of the agent, like in a bit different way. It sounds like though, you must be doing a lot to maintain state and history. So just in terms of, I'm curious about if the canvas is being generated with code, you must still have some separate system for just that history of actions taken and decisions made. And I know talking to a lot of teams, a lot of work goes into how do you maintain that state? How do you maintain that history? I think like when you're building an AI Can you do something like X, but do Y? So like, keeping this history and kind of natural flow that you usually have. That's one thing you've talked a lot about is the designer in the driver's seat and then the agent also acting on the board and this idea of what I think you even dismissed collaboration as just something that's required in 2026. But I think what's interesting is your agent is almost a collaborator, just like another teammate might be a collaborator. And I'm curious about this, exactly this context problem you're describing of your canvas could have a lot of things on it. I feel like humans can open a busy canvas and orient themselves and figure out where to work. But I'm curious what you have to do behind the scenes to make that possible for your agent. This is basically why Vlad mentioned that creating a full chat history is a bit tricky because the way it works right now for us, and I think it's easier to imagine in a way how our canvas looks like. So inside of our canvas, we have just like multiple instances of screens. So just screens. And we have a sidebar with a screen list. And each screen has their own version. So basically, if you work inside of one screen and you make some edits, you can revert anything from that. And when you click between screens, this is the moment when we actually like collect all of the needed data and forms this context into the history. And so for each screen, we have kind of different history, but all of those screens, they share similar context, similar stylistic references, similar like goal of the app of this project. Like what exactly should be done. And so that is why we can't just like present all of this history because it would feel a bit broken, you know, like to the user. Because like at this screen, we have like this interactions and this, we have this interactions. And yeah, it doesn't feel like fulfilled. You know what I like about that is that it's almost like you're creating lots of context windows, which is really great. But I, it feels like it also poses a problem of when your agent has to work across screens. Yes, once again, good thing is that context window is increasing the amount of time, like the loop, what I mentioned before, like when agent can come circle back and make a decision, okay, here I'm stopped. The duration is increasing. Cursor had the swarm of agents that was working for three days. So kind of it's. There is less problem of, okay, like how you make everything like compact, clear, but kind of how you direct the agent to pull up the information that it needs at the moment and like how you compress it to kind of fit in the context window and not in the full context window. And that's kind of a separate problem on its own. Like when you build in this type of stuff and but once again, the cool thing is that the context in last year, context windows increased the time that you can spin up an agent increased and just overall trend line right now. Like in our work, we make a lot of kind of bets on where the models would be in the half of the year. And sometimes you need to wait out for certain things to happen. Sometimes certain things can kill you, but you can, you can't work without kind of making it some sort of hypothesis. Okay, like where things would go, like in the next half a year. And I think with a lot of stuff, if you're trying to sometimes put something back because like we're 80% sure that it's going to be solved and focus on kind of those fundamentals that we don't see being solved there. This is a piece of advice I hear a lot of people talk about this idea of you want to be building on the edge of what's possible today, not in the realm of what's possible today. But I'm curious about what nobody really talks about is how they make those decisions. How are you judging what might become just possible in a few months or with that next model? Right now we already have quite a lot of, we already have historical data. Okay, like where things kind of trending towards to. And it's much easier to make those judgments like right now than like it was two years ago. But it's just overall look at the trend line of where things are going. So for our case, like we, we found, we saw that kind of was a trend line, like a year ago, like models have no spatial understanding at all. Like you, they could put like one thing here when you can see here, don't align things. But with each kind of incremental model, like it improved and you kind of see the trend line. Okay, like probably sort of like smaller things like alignment issue, like they will be solved in a year and you need to focus kind of on the bigger problem of, okay, like how we orchestrate this thing as a whole, where like alignment is not a problem. And like where you actually need to combine images for the design and you need to focus on like other stuff that, you know, on the orchestration level that the models themselves want to do because they aim for like much bigger general intelligence that, that we as a player already kind of tuned to do the task for us. So I don't know if it's. Like, I just wanted to share my own experience of it. And I think it's, it's kind of a bit of an advice to everyone who is building something. It's really important to, to dream of the things that are not even possible. And like, I think this is how you should create your vision, vision of the company. It's not always about like what should and can we build today. It's always about like, I would love it to be like in two, five, 10 years. And so when you dream and you have this vision, then you try to align your dreams with the reality. And at some point they are intersecting. And so this is a great approach, I think. Yeah, it's almost like you're pulling the future forward. Right? Yep. Something like that. And also answering to this question, like currently what I'm seeing and I'm expecting to see in the next couple of months, something related to like post open cloud app. So I, I think we would see some apps that can work locally because it unlocks a lot of things for the apps. For example, the way how we can store the context history and memories. You are not constrained of the servers and databases. You can store everything you need on your local machine and you can fetch it and grab it like instantly. And yeah, it already feels like a future. Yeah, for sure. Vlad, I want to go back to the example you gave because I can see this example of we see the model make alignment mistakes, but we also see it getting better over time. So we're not going to focus on that problem. We're going to focus on this higher order problem. But pragmatically, like your user, especially if they're designers, they're going to see that alignment problem and be like, this is no good. So how do you balance those two things? There are two ways. Like you can fully ignore it and you can add some temporary workarounds. In our case, I think like we did both. Like we, we saw areas where there is improvement, but like we consciously decided, okay, like we, we know this is not good. This is not if we were living in the ideal world, like we would not generate design where the button is misaligned with an icon near it. But also like, you need to think about unlocks that you already give to users like in current state. So even like with some alignment issues, like what are the days for our product, it already unlocked quite a lot of users and teams to, once again, spin up some mid fidelity designs. So it was used for quite a long time as like low fidelity, mid fidelity prototyping. And on the other side, like we immediately gave some features for you to actually fix those issues. So like we know that our users, they use Figma. So one of the first things we did is to kind of keep in the workflow that you already have is like Figma expert. And we know that if you see the problem with icon and like you see a speed unlock and kind of workflow unlock for you, like on that side, you will copy design to Figma and you're gonna fix this like one small issue. And we're making a bet that like we won't have such things like in the next half a year. And we're not thinking that, okay, we should stop our work and yeah, because when the inevitably like certain things are solved, like they're happy that you were not overinvesting in this specific area and you focused on the fundamentals that don't change over time. I really like that because what it shows me is that you have a very clear vision of the value you create. So this decision you're making about what to focus on in the short run versus what will the model get better at is what is this core value? It's not about a perfectly aligned button. It's about being able to very quickly spin up mid fidelity design. Yeah, like I will add on our end that once again, it doesn't mean that we don't aspire and don't see ourselves like generating something that the real senior professional designer would do. It means like that we're essentially like taking a like a real human being. Like you, when you start, like when I started designing, it looked horrible, but like eventually I learned like some skills, learned taste and so on. And already at this point, we, we feel so many unlocks that can be done. And with new workflows, we're like putting more effort into experimenting like with existing models, with tuning, like open source models and like trying to steer them in the direction that, that we don't see changed on the foundational models level. Yeah. Yeah, great. All right. We are coming up on time for people