Inside Canva’s $3B ARR AI Design Rocketship — CTO Brendan Humphreys on Magic Studio & Canva Code

Thank you.

Yeah, it's an amazing journey to be on, and we're at a fantastic point right now. Absolutely.

It does feel a little surreal, but I do recall when I joined the company, when I made the decision to join, I could really understand that there were multiple pathways to revenue. It was a really simple idea that was very captivating. I'd actually tried to build something similar in my spare time. And so I really believed it was very easy to believe in the business model. And that made it very easy to get on board 100%. And I think I've been there ever since.

That's right. Yes. So, Mel recognized that the entirety of the design process involved so many different tools, each of them with a steep learning curve. There was often real friction between the tools, and that kept the barrier to entry really high. So she saw this opportunity to consolidate it into a platform that was web-based, the source of our success, that great insight.

Yeah, something like that.

Yeah, something like that. Yeah.

How do you pick the winners? Yeah, look, I've been very lucky. I joined Atlassian back in 2007 through an acquisition. Atlassian bought my company, and around about that time, 2014, I kind of recognized that I was in a little bit of a rut. I had certainly enjoyed the ride at Atlassian. They'd gone through their own hypergrowth phase, and they were just leading up to IPO. But I really wanted to get back down to just building something.

And through a friend, I met Mel and Cliff, and I instantly fell in love with the business model. I don't think I have great advice on how to pick winners.

Right. So there was a combination of things that were really attractive from the first time I walked in the door. Certainly Mel, Cliff, and Cam are really impressive founders, both with the expansiveness of their ambition, but also they're just really nice people, and that helps a lot. The engineering team back then was, I think, four other engineers, the CTO, and the first engineer that was hired, Dave Hearnden, ex-Google engineer, just a prodigiously talented engineer, very, very smart, very Zen engineer. I would describe him as the engineer's engineer.

And meeting him and chatting with him, I realized this is someone that I could learn from, someone I could partner with. And that, combined with that goodwill in the founders, the ambition in the founders, I thought, yep, I'm going to take a plunge here.

I think it helps create agency. I think that any organization that grows beyond a handful of people, the bystander effect is a real problem, that it's too easy to think, you come across a problem and you think, that's not my problem. But when you own a company, everything's your problem. And so having that kind of high agency when you're attacking problems doesn't mean you're going to solve every problem, but you recognize the problems and you're very engaged and you're happy to cross over the swim lanes a lot.

Certainly, at early-stage companies, you've got to be doing that a lot. You've got to be really a bit of a generalist. And so I think that's a really powerful thought that you really get ingrained when you're kind of on the line, on the hook for everything when you're running your own company.

So at Atlassian, I had worked my way up into, I guess, middle management. I had spent some time there looking after a bunch of teams, and then I realized I really wanted to get back on the tools. So I kind of fought my way back down into engineering and was a principal engineer there for a while, and then jumped across to Canva as an engineer. And I worked at Canva for a good three or four years, just primarily on the tools, just writing code.

As we started to double in size every year in our engineering org, there needed to be some management of that kind of horde of engineers. And because I had that experience, it was very natural for me to kind of step away from the tools a little bit and find myself more in a management role. And I've always tried to keep myself active in the tools. As we've grown, we've continued to double in size. Now we have about 2,300 engineers. It's extremely difficult.

But—

Yeah, try and quarantine some time to play. And certainly the AI tooling helps with my rusty coding skills. But I actually find a lot of intellectual enjoyment out of solving different intellectual problems, like problems of organizational complexity, figuring out how to organize an organization to get a particular problem solved. That's actually quite an interesting challenge.

We have 5,000 employees.

I think it speaks to the ambition of the founders. This broad mission to empower the world to design, it has meant that the product is quite expansive. And as the feature set's expanded, we've had to expand engineering to stand up teams that can own these features and operate them in production.

Yeah, so our origins are predominantly in Sydney, Australia. We have a large office there. In fact, we're building a new one. That's very exciting. We have a hybrid working culture, so people can come into a local hub and work. We set up hubs when there is a large enough number of people in a particular geography. Through COVID, we were still doubling in size in our engineering org every year, and we kind of realized that we can keep that pace and hire people that are just time zone compatible.

So that meant that we spread up and down the eastern seaboard of Australia, across to Perth, across to New Zealand. Through acquisition, we have acquired engineering teams, so we have about 400 engineers right through Europe through our acquisitions.

I will say it's not without challenge. The key is to find ways for teams in kind of incompatible time zones to be as autonomous as possible. Usually, that means just finding the right seams in the product so there's real ownership in these locations. And that's what we've strived to do. There will be the occasional need for a meeting, and when you have to meet between Sydney and, say, Prague, that's not pleasant. Someone's going to get the short end of the stick on that one, right?

An early morning or a late night every now and then is going to be needed. But where possible, we focus on a lot of written technical communication, a lot of async communication. So we just minimize the need for face-to-face contact.

We have leaders, we have geography leaders. They just tend to be kind of general manager types. They're not engineering-specific. All of engineering reports up through me in Sydney.

Canva is an enterprise tool, so it has a full doc suite. So you can use it for sharing and collaborating on docs, presentations, whiteboards, and that's a very effective tool for asynchronous collaboration.

Look, we're certainly alert to the rise in visual AI, but we feel we're actually really well positioned. We can use third-party models when they become available, integrate them into our platform very, very quickly, and provide a really rich, cohesive experience. We can facilitate collaboration. We can let you organize your content. We can provide brand kit controls, all of these tools that perhaps your average AI-centric startup can't. And indeed, we have a very rich API layer that is available for third-party developers, our ecosystem offering.

A lot of niche AI startups are finding us a fantastic distribution channel. So they've got their niche product. They can come and build a rich integration into Canva, and then suddenly they get distribution, they get a lot of users. We've had a lot of success, and that's a win-win for us and for them.

Well, they're literally apps available in an app store that we provide. Oh, the app store.

So we certainly—Cliff likes to say—we've been talking about AI and dabbling in AI long before it was cool. We stood up our own machine learning team many, many years ago, like 2017, I think, was when we first had a serious crack at building an ML team. And that was all about propensity modeling and building recommendation engines. We have a vast library of content that we want to serve to users, and we want to be able to understand their intent and then be able to serve exactly the right content for the right context.

So we have quite sophisticated ML models that help with that. We did acquire Kaleido. Kaleido was actually integrated through our App Store as Remove.bg. And we loved their product. Their product was so popular on the Canva platform. We loved it so much. Then we met the team. We loved them. We acquired them. We've since brought all of their expertise in-house. We've continued to build a lot of in-house AI expertise. We have over 200 machine learning engineers on staff.

We've just started to form our own, or coalesce a lot of that expertise into, more or less, a standalone research organization that is kind of protected somewhat from the product cycle. And we'll continue to build on the great work that both research teams in Canva and inside one of our more recent acquisitions, Leonardo, have been doing, which is more based around foundational model work and deeper research.

Yeah. So we take a hybrid approach there. We certainly have teams that are dedicated to more foundational research. But we also have folks embedded in product teams who are doing research, and they tend to be on shorter product cycles. Their output is usually a prototype which product will look at and make judgments about, and then we'll see if we want to turn that into something that's a production feature. And we'll try to turn those around very, very quickly.

We've invested enormously in putting a platform abstraction over a lot of the third-party AI that we use, whether that's kind of like base-layer infrastructure like Bedrock or SageMaker, or whether it's third-party AI providers like OpenAI. And that allows us to rapidly switch out models and experiment with different models. It allows us to augment models with our own proprietary tech. And it allows us to really iterate very, very quickly when new models come onto the market that do something exciting. We can get them in front of users in really cohesive experiences very, very quickly.

So we were able to, for instance, Canva Code is an interesting feature that we've just launched, just back in April. That's a feature that allows users to build little intelligent, interactive widgets in their designs that went from first idea through to production in about three months. And we're now serving 100 million users and climbing.

Yeah, so Magic Studio is a collection of AI-powered tools, both text and visual. There are text-based tools that allow you to, for instance, modify text to be in your particular voice or in a brand voice, which is really powerful. There's text summarization, text expansion. We've got a whole suite of image editing that's really powerful, whether that's infill or outfill. We've got Magic Grab, which is an amazing feature, which basically allows you to treat a raster image as something that you can decompose.

You can pick objects up and move them around. Magic Erase uses similar technology to be able to remove and then infill in a very smart way. We did launch Canva Sheets in April. That's our take on a spreadsheet product. It is designed to be very, very easy to use, fully integrated into the visual communication experience of Canva. And it will be our kind of data backbone going forward. So when we want to do more data-driven products, we'll be using Canva Sheets as the kind of data source for that.

We see ourselves at the intersection between productivity and creativity. And we think that increasingly in the workplace, visual communication is just coming to the fore. And so we have been rounding out our feature set. We have a Docs product that allows users to create online documents, collaborate on them, but do so in a really visual way so they can embed rich visuals, they can embed graphics very easily, and they can change different doc types within the one design. So you can have a quite text-heavy document on one page, and then on the next page, you can have a whiteboard where you can be doing some collaborative whiteboarding.

You can have sections of a presentation in the same design. And that's an amazingly powerful way to collaborate on a particular project because different contributors to a project need different assets. And normally it's quite hard to organize all those assets. And here they're all just in one design space.

So Dream Lab was our first integration with Leonardo. So Leonardo, we acquired last year. They're an amazing Australian-based AI company, visual AI company. Dream Lab is prompt-based image generation and uses its own foundational model.

So we do have a chat interface, Canva AI, and we are expanding that. At the moment, there are some features within Canva that are powered conversationally, but others that are just more of a traditional software experience.

Yes, certainly we are paying attention to the current excitement around agents. I think there's a bit of a definitional problem at the moment as to what exactly an agent is. I have my own idea around what agents are, but maybe we don't get into the definition. We certainly have behind Canva AI quite sophisticated orchestration that you could call an agentic solution. It's inferring intent at a very abstract level from a user prompt and then planning a course of action and then executing on that action.

Internally, we have agentic solutions deployed, for instance, in our customer support. We're using a lot of agentic solutions there where first-line support, when a query comes in from a user, goes through an agentic flow. And quite often we can handle user requests purely with that agentic flow. But within the product itself, yes, we're definitely looking at that. We're also thinking about a future where access to Canva might be mediated by some other agent. And so we're definitely looking at Model Context Protocol.

We have our own Model Context Protocol that we've stood up just internally, and we're certainly talking to the big vendors about interactions there that are possible.

It's not actually a concern. We see Canva as a destination. If you are doing any kind of visual communication, then there are going to be natural limits to a conversational interface. And people are going to want to be able to collaborate. They're going to want to be able to control for brand. They're going to want to be able to organize their content. There are going to be limits to how you want to interact with a design conversationally. So we think a future that we see is that if you do have your personal chatbot and you want to do some design, you might get a one-shot design there that then you can be transported into a Canva experience where you're actually able to stop talking about the design or asking a machine to do something and actually just play with it as you would normally, with a mouse and picking things up and moving them around.

I think that is the essence of kind of human creativity. And I think that that's not going to go away.

So thank you for saying we have high velocity. I will take that compliment. It certainly feels like breakneck speed at times. The technology org, we're very focused on really thinking hard about the domain model that we are implementing and then building a set of composable components with powerful APIs internally that enables product teams to move very, very quickly because they're sitting on top of a rich set of functionality. It takes real care and diligence to build out that internally consistent set of surfaces and services that back those surfaces, keeping control of the domain model so the domain model doesn't just explode into this kind of combinatorial explosion of complexity.

And so we spend a lot of time thinking about that. We want the service teams to be thinking very carefully about what APIs we provide product teams so that product teams can move very quickly. With AI, it's more of the same. It's thinking very deeply about what's the AI platform layer that we can provide. Product teams can be getting the benefits of AI without necessarily having to go deep on the technology. Having said that, we are very focused on this kind of democratization of knowledge around AI in our technology org.

We think that once upon a time in software teams, you'd have a DBA on the team, but now a DBA is not really a skill anymore because the abstractions above databases are such that you don't really need that deep skill unless you're dealing with very specific circumstances. We like to think that the same is going to happen with AI technologies. And we're seeing it now with the tooling that's out there. It's a real democratization. A lot of engineers who have no formal training in AI are picking up these skills and figuring out how to use these tools and then being able to build AI-first features very, very successfully.

So we want to enable that. We invest a lot in education of our engineers, lifting them up to understand how these LLMs work, how to interact with them, how to effectively build product around them, which is not always intuitive. There are a lot of things that you have to wrap your head around, particularly the non-determinism, which is a tricky thing. I think a lot of software engineers are trained, particularly the more senior engineers, in wanting to write a whole set of unit tests based on a deterministic system.

But when you've got a non-deterministic system, you have to kind of move your mindset to now we're going to test with evals, which are much more probabilistic. So it's a little bit of a mind shift. There's a lot of other shifts you have to make as a software engineer, but we're very much about empowering engineers to understand the technology, firstly to help in our product, but also, and maybe we're going to go in this direction in the conversation, to understand that their jobs have changed now that these AI tools in the coding space are so powerful. Their jobs have essentially changed.

So we really want to enable that learning and that rediscovery and let each engineer have their moment of realization that, oh, wow, I now have a different way of working, and it's a more productive way of working because I have these very powerful tools in the loop.

Firstly, some definitions. So when I wrote that blog post, I was referencing perhaps a very tight definition of vibe coding. This idea of giving into the vibes, it very much suggests that you only focus on the prompts. In effect, the prompt becomes the source of truth. In the same way that when you write source code today and you feed it to a compiler and you don't really worry about the compiler output, vibe coding seemed to suggest that, well, now the prompts are the source code.

And the actual generated source code is something you don't have to worry about. We don't think the tools are there yet. I'm not sure the tools will ever get there, but at the moment they're certainly not there. That's not to say that they aren't powerful. They are extremely powerful, and we have deployed them at scale at Canva. And in my travels talking to senior engineers within Canva, you couldn't pry these tools out of their hands. They are far more productive with these tools.

But we have a very important rule that you need to own the output of the tool. That means you have to understand it as if you'd written everything yourself, because ultimately the generated source is the source of truth, and it's going to go into the repository under your name. It'll go via peer review. We have a strong culture of peer review. And so another human's going to have to read it and understand it. I'm very excited by the productivity lift that we've seen with these tools.

And I think we've got a ways to go.

Yes. Well, we could probably spend an hour talking about how do you measure productivity in engineering teams, but we certainly are seeing, in some metrics that we measure that we consider to be good proxies for productivity, a significant, like a double-digit percentage increase in productivity.

If there's any Canva engineers listening, this is not how your performance is rated. This is the number of PRs merged in a week. We're seeing about 30% more PRs merged from engineers who are using these tools predominantly.

I think this is the real challenge with a peer review culture, is that it's very easy to write a relatively small prompt and end up with volumes and volumes of code. We are seeing some success with AI-assisted code review. I think that is inevitable, that author with AI superpowers will be matched by reviewer with AI superpowers. I think that's an inevitable path that we'll go down at scale. There are anti-patterns that we see. We did have one enterprising engineer who vibe-coded his way to, I think, a 50,000-line pull request and then lobbed it over the fence to a reviewer.

Yeah, good luck. We have a guideline that we really want to see PRs in the order of hundreds of lines of diff, not 50,000 lines, which is not an easy task for anyone to review in any reasonable amount of time. So there's challenges there. But I think, again, if you've got AI on one side in the authoring, then I think you can certainly have AI assisting and guiding a reviewer. Then I think that works at scale as well.

That's a good question. We have slowed down hiring a little bit for a number of reasons. We wanted to just take a pause and understand where the market's going with these AI tools. We are still hiring, but we're not hiring as fast. There's a challenge for our industry in that we do see slightly bipolar results for these tools. In the hands of a senior engineer who can tell good code from bad code, they're very, very powerful.

But for graduate engineers, for junior engineers, they can be quite dangerous because they just don't know what they're looking at when they've generated a bunch of code. I think that's a challenge for the industry. We do have a graduate intake program. We will still be taking grads in at the beginning of the year next year, but we're just taking a pause now. I think the way that I'm thinking about it personally is that engineers are more productive. If you've got a lot of work to do, then why wouldn't you want more productive engineers to throw at that work?

So I think we've got room to grow our engineering org.

I think so. I think there's this kind of—I read somewhere this kind of advice: what do you do if you're graduating? Just focus on critical thinking. But critical thinking is something you can't really teach. It's something that you need to build around a domain of knowledge. And the only way you get a domain of knowledge is to work in that domain. So I think at Canva, we'll be focusing on probably just more careful onboarding, more careful peer review of grads.

We will be more picky. We will be looking for the grads who bring deep first-principles thinking, strong, really strong CS fundamentals, but also show us some of those human qualities. Empathy in engineering is a vastly underrated skill. And it is a skill. It's not a talent. It's something that you can teach engineers.

So empathy, I think it's got this kind of wishy-washy, soft, fluffy feeling to it when you say empathy. But really, it's about getting in someone's head and understanding, when you're having any kind of collaboration with someone, what's their point of view? Why are they saying the things they're saying? Why are they acting in the way that they're acting? In a large engineering organization, it's absolutely essential that we have productive collaboration. And a key to productive collaboration is being able to empathize with your collaborators so that you can very quickly get on the same page and then all be rowing in the same direction, just to mix my metaphors.

So we teach skills internally around this. There's a great improv trick to keep a conversation going, which is just the rhetorical device of saying, "Yes, and," when you're contributing to an argument, so that you're not shutting your mind off to possibility, continuing the conversation, opening your mind to what's been said, but also with the "and" allowing you to add more context. We also educate people about techniques like steelmanning, that is, listening to someone else's argument that may be different to yours and then being able to restate it in the strongest possible terms with genuine intent.

One of two things happens when you do that. You may change your own mind when you've forced yourself to take on board all of their context and then restate their argument in the strongest possible way. That might convince you that their way is actually correct, but at the very least, it will build genuine trust with the person that you're collaborating with. And if they're doing it back to you, then it's a very, very productive way to resolve differences. Technical differences come up all the time.

It's a great way of resolving those technical differences. Related is the principle of charity, just really taking people, understanding that most people are reasonable and want to do the right thing. They just have different contexts and different incentives. So building empathy for their context and their incentives, again, will help you be productive in a team setting.

2,300 engineers.

We have an engineering value: strive for pragmatic excellence. And so we are ruthlessly pragmatic in whether to build versus buy. And that goes across all elements of functionality. I'm a huge believer in, I think it was Jeff Bezos who came out with that famous saying of, don't spend time on undifferentiated heavy lifting. Certainly, we want to leverage best-of-breed models. If they're third-party and they're available via an API, then we will. If they're third-party open-source models, then we can host them ourselves, then we will do that.

But we do provide a platform. As I said, we put a platform abstraction over that so that we can chop and change quite quickly. We are investing heavily in our own model development. Leonardo has given us a great foundation for that, no pun intended. And we have billions of very unique opt-in data points around design creation, design intent, ingredient selection. We're mining to produce real insights into how to improve people's designs, how to help people in their design activities.

Yeah.

Okay.

Yes. Don't quote me. Yes, I think around about 150.

That's correct, yeah.

So Leonardo's got a very successful end-user product in market, and so we're keeping that running independently as well. We primarily acquired Leo for their research capability, though. I mean, their research capability is phenomenal. They've managed to build a world-class research team that's spread all around the world. On the question of foundation models, I don't think that race has been won, certainly. And again, we're radically pragmatic there. Leo have just shipped an amazing set of features that uses Google's Veo 3 model.

It uses the latest Flux models. So even Leo is using third-party and internal models. We do think we are uniquely positioned to be in that foundation model space. So maybe that advice of, kind of like, don't be in the foundation model space is good general advice, but we think that we are in quite a unique position in terms of the data that we have to pursue that particular avenue.

We do. We use Meta's models. We use models from Stable Diffusion. Segment Anything is an open-source model that we use. I know we've tried Llama. So yeah, we have certainly looked at those models.

So we have our own proprietary platform layer that sits on top of tools like Vertex from Google or Bedrock from Amazon. I think certainly Vertex or Bedrock have really impressive inference serving. We don't have a strong preference. We try and maintain a footprint across both to give us flexibility. And we have our own model-serving capabilities internally, which are part of that AI platform that I mentioned.

We use Weights & Biases for our evals, and we have our own eval framework that we've built.

Yeah, it's an interesting question. It's an unsolved problem. If a model gets it right 90% of the time, then 10% of the time it's getting it wrong, right? That's going to be acceptable in some cases and not in others. For some of our AI implementations, we decompose the problem and use much more orchestration that's based on heuristics, with elements that are solved by LLMs. That gives us much more determinism and much more control. So if it's really important, that's the way we're going to solve it.

There'll certainly be AI in the mix, but it's not like, hand the problem to the AI and then hope for the best. For other spaces, as you said, when it's more creative, then perhaps you can do that. Yeah, the hallucination problem is interesting. It's minimized, but it's still there, and I'm not sure it's going to go away.

Absolutely. We think very carefully about prompt injection. We are very careful. We have a world-class security team that has rapidly upskilled on security as it applies to AI. So we're very careful in that regard, very sensitive to being in that enterprise space.

Catering to an enterprise market, it certainly pulls the product teams in different directions. Enterprise customers want sophisticated admin controls, they want sophisticated auth, they want data residency, these kinds of considerations. If you haven't baked them into your product early, they become quite expensive to retrofit. Very early in Canva's architectural journey, we put quite a good abstraction in over our AWS infrastructure. But I do think back now and wonder, oh, we could have just spent a little bit more time really abstracting region-based storage.

It would have been cheap to do then. We have got it now, but it was a massive engineering effort. Back when it was 10 of us and a few services and a few databases, it would have been relatively cheap to kind of build that culture in there, build that kind of tax, if you like, on every product that you have to think about what region shard you're going to store the data in. Having to retrofit it across hundreds of teams, hundreds of services, was a monumental lift.

Technical debt is, I mean, it's a dirty word. It shouldn't be a dirty word. Technical debt is an extremely useful thing when you're a startup. And we had the high-interest credit card of technical debt for a few moments in Canva's history. And I'll tell you about two of them. One was our original editor. We call it E1. It was a JavaScript, kind of jQuery big ball of mud that was kind of hero-coded by a few people.

And it got so big and so unwieldy that it became very, very difficult to add new features without kind of non-deterministic behavior cropping up in it. I mean, it was an opportunity cost. We could have re-engineered that, but we were busy building essential services that were going to power the next generation of features that we were trying to get to market. By the time we were ready to rewrite it, we did have to pay a lot of technical debt down.

We went through a huge re-engineering effort, two years to rebuild this editor without adding really much of any new features. Well, we did get collaborative editing out of that, I should say. But it was, I think, an example where we just ran up the technical debt to get this critical mass of functionality built around the product. And we could see that this thing was groaning under the weight of just basically poorly architected front-end code, but we were willing to take that on.

And then we found product-market fit, we got a revenue stream, and that gave us a lot more runway to then go back and do the big rearchitecture. I think we made the right choice. It was pretty scary, but I think we made the right choice there. And we've got a number of examples where we've done that, where we've kind of really run up technical debt. I think the important thing is to, as an engineering team, recognize it, see it, make intentional decisions around it.

And that goes to our engineering value of striving for pragmatic excellence. It can be a pragmatic choice to be expedient in engineering quality, to take shortcuts to get to market quickly because you just have to. And as long as you are intentional, you're making really good engineering decisions, and then you're keeping the receipts so that you can come back to product and say, well, now we need time to go and reengineer it properly, then I think that can be quite powerful.

Yeah. Wow. Look, everyone at Canva, everyone from product right through to engineering, is a product owner. They really own the product. They care about the product. They think deeply about the product. And so there's a lot of internal dogfooding culture at Canva. When we do ship something, if it's a big new feature, we will always put it through some kind of beta testing with a select group of users. We will have the feature behind a feature flag that allows us, for instance, to just expose it to staff and have staff dogfood it.

We have the advantage that our product is very applicable to our work, so we use it every day. And there is that constant feedback loop between the product teams who are building it and the entire company that's using the features. And we have good pathways of communication that collect that information from that dogfooding and feed it back. Look, it's a tricky balance. We don't always get it right. But I think the key there is just the passion that engineers have for shipping quality product, that they really want to ship something awesome.

So they sweat the detail.

So Mel has a two-step plan for Canva, which is to create the world's most valuable company and then do the most good in the world that we can. And I have to say that really helps me get up in the morning and keep coming into work. I think it's a really noble mission that is something different from a lot of companies who are just focused on commercials. Practically speaking, I think we've got such a long way to go in building out the product vision that is in Mel's head.

And I'm really excited to go on that journey. I think AI is really, really exciting. I think from a ways-of-working point of view, I'm looking forward to a new era of productivity. I don't think software engineering goes away. I think software engineering changes to actually a much more fun job, where a lot of the mundane kind of plumbing of software engineering is handled for you, and you're able to orchestrate software with these agents helping you and become much, much more productive.

So I would expect our productivity as an engineering org to lift significantly still. You'll see that I can't tell you too much about what's coming down the pipe in terms of features, but actually there's an announcement coming out this week, which is pretty exciting. Actually, I probably can tell you about that. We are integrating Veo 3, which is Google's new amazing video generation model, natively into Canva. So that will be exciting to put into the hands of users. We've got a host more AI features that are coming down the pipe around the October timeframe.

And then into next year, there's so much more, but I'm not going to mention any of that because I will get in trouble.

So there is the Canva Foundation. They've given the vast majority of their equity in the company to the foundation, and the foundation supports charitable causes all around the world.

We do have a creators fund. I think it's $200 million, and it's designed to reward creators. We recognize that it's a challenging environment for creators, but we want to see creators recognized as contributors to these AI models. So that's how we're doing it. Wonderful.

My pleasure. Thank you.