
Notion's head of engineering Baylor Kelly discusses the new developer platform, which includes a CLI and Workers for automation and data syncing. A recent San Francisco hackathon with $34,000 in AI credits showed teams building native Notion solutions without external infrastructure, validating the platform's promise for enterprise use cases.
Chapters
Workers is definitely the hot topic and in my opinion, a game changer for the way that the community will interact with Notion and in the work that we do.
Welcome to the Notion State of Mind podcast. I'm your co-host and co-founder of Notion State, Josh Redd, joined by my co-host and co-founder of Notion State, Bryan Takayama, joined by a special guest, our co-guest, co-host guest, and co-worker at Notion State, Baylor Kelly. And we are, we're going to talk a bit of a special episode today. I'm talking about a recent event that went down in San Francisco. So just to set the stage as a listener and a viewer, I feel like I'm actually in the shoes of the viewer because I did not get the chance to go to this event. I only have a severe case of FOMO, and so I'm going to ask all the questions and hopefully I get to the bottom of what went down and give you the full picture. So with all that said, let's kick off the episode. Welcome Baylor Kelly to the podcast.
Hey, thanks for having me. I feel honored because I believe I'm the first guest on the Notion State of Mind podcast. You are. So gotta go first, really gotta set the bar and then everyone else can take it to the next level from here. I'll set a pretty fair baseline. It'll be great.
Thank you.
Thank you for that. Let's, let's, let's just, uh, get this right outta the gate. How many, how many episodes have you, have you listened to so far?
Every single one of 'em. Really? Yeah. Wow. I did listen to the, the most recent one last night. Uh, so I thought I was gonna catch you. I thought I was gonna catch you lacking. My, my driving time is my podcast time.
Nice.
And so it's a, it's a good, uh, resource to listen to. And it's actually been really useful for me cuz we all interact and I hear your perspectives often, but I, I catch things in those podcasts that I don't normally get from you in conversation since Josh is just always throwing in philosophical topics. Uh, I get different POVs from Josh and Bryan on these, uh, random things.
That's just a collection of Joshisms and Bryanisms.
And then, yeah, dude, head, head in the clouds for me, boots on the ground for Bryan. Great combo. I guess, Baylor, I'm sorry, in our intro of titles, I didn't bring up the fact that we are friends IRL. I mean, would you agree?
Yeah, I would say that.
Well, I mean, Bryan, we're friends IRL too. Sorry, really digging myself a hole here.
But also in your intro title, you didn't introduce Baylor at all. I mean, you said co-host, a co-guest, but Baylor, you're our head of engineering. You're like absolute rock star, full stack engineer. Tell us a bit about yourself. And why, like, why are you on this podcast with us today?
Yeah, I appreciate that, Bryan. Thanks for calling that out. Um, uh, yeah, serve as the head of engineering at Notion State. Uh, been on the team for a little over a year now. And yeah, serve in the capacity for all things engineering, uh, figuring out how do we migrate client data from other platforms into Notion, uh, build custom tooling for our clients. Really get us new capabilities from the engineering perspective. Um, but I think overall, you know, I spent a little over half a decade working in the nonprofit sector, building some really cool tools, and now have another great opportunity to do it at Notion State and build kind of some cutting-edge tooling for our ecosystem and serve our clients well so we can continue to do this thing that we're watching happen at Notion State.
For profit.
For profit.
What's that, Bryan?
Good clarification. Capitalism. We are business, baby.
Baylor, I mean, I was kind of joking, but I guess, is there any significant difference that you notice already going from nonprofit work to— we're obviously a business. We have the goal of making profit so that we can grow. But any main differences?
I think in my, in my previous experience, previous role, you know, in some regard, revenue drives everything. Like, you still have to pay the bills. It's just more at the forefront and it's open and clear of, okay, what's our, what's our strategy moving forward to increase revenue so we can continue to keep the doors open and grow, obviously. And getting to play more directly involved, like direct involvement in that at Notion State has been really interesting for me because I enjoy business. I enjoy strategizing in those ways. And so I think, yeah, the openness and clarity that happens at Notion State around revenue, profit, uh, upcoming, uh, potential clients and things of the sort, I really enjoyed. Uh, it's been, I think, a stark difference from previous experience to what's happening at Notion State. And so. I appreciate it.
Nice.
Yeah, I'd be interested in dialing in a little bit more on this. There is the strategic piece. One, you are the head of engineering, so you kind of have your own— we're still building that, uh, but like you definitely have more of a leadership role. But in your other role, I imagine it was like relatively traditional engineer or eng manager, where here we might have 10 different things that you're working on at any given time.
Like, what, what, what has that transition been like? Yeah.
Yeah, there was partly some overlap in my previous role, you know, served in different capacities on specific products, multiple products, uh, working on specific projects, even within those projects and leading them. Um, but it was for the most part, pretty isolated. Still a lot of discovery, the things I enjoy and that you guys have seen that I'm good at. But now at Notion, so yeah, there's, uh, you know, probably 6 to 8 things in flight right now that I'm either estimating, discovering, executing, or managing, uh, other engineering capacity to do. And so I think that's part of the thing that I actually enjoy and has drawn me to Notion State and the work being done here is that I've got a lot of autonomy and you guys have entrusted me with a lot of decision-making and authority to get things done. And it lets me run. In a very fast way because we get to make decisions, figure things out, and move. There's not a bunch of extra layers, bureaucracy, uh, slowdown that happens there. It's, is this a good decision? Let's move forward and figure out how to execute well. And so yeah, it lets me do all the things I enjoy. I still get to write code, build things, uh, but also get to discover, test, and watch us grow as Notion grows as well.
Yeah, there's so much to talk about here, or that we could talk about, especially with an engineer in, in Notion. You know, it's like, I thought Notion was supposed to be a, a no-code tool, but we'll save that for a, for a different discussion, or, or maybe it'll wrap right into this one. Cuz what we want to talk about is, is something that is, is actually surprisingly technical for the, the Notion world. And so what I would like to do is, is kind of talk about this event that I teased, and I didn't even say what it was in the beginning. Uh, the Notion Hackathon. That happened in San Francisco at Notion headquarters, uh, just what, a week ago as of this recording? Yeah. So, uh, we're recording May 20th. I know I'm not supposed to date these episodes, but this is gonna be about a dated event, so might as well. And, um, yeah, let's talk about that. Let's talk about the, uh, the hackathon, what even a hackathon is and why do we need it for Notion work, you know, and, and, uh, maybe this, this hackathon is, is a good, it's a good reason to explain why things are heading that direction.
So.
That's a lot of, that's a lot of disclaimer or pretext. Let's get into it. Maybe I'll pass it over to you, Bryan. What was this? What was this event? What is it in the, in the grand scheme of the Notion world? What was going on?
Yeah, so on May 13th, there was a big Make with Notion launch. It was the launch of their developer platform. We'll dive into the specifics and the components of that a little bit later in this, but essentially what it was, was as opposed to Notion being a complete no-code tool where you could connect via custom integrations or custom scripts before, we now have the ability to get under the hood a bit and have some access to new tooling that makes Notion way more superpowered and way more enabled with your, with your tool stack.
So they launched all these, these new features and they had, they had meetups across the world.
I hosted one in Barcelona and as they were giving the, the keynote and walking through the presentation afterwards, there was just like silence in the room because typically it's like this new, like this new tab block, or you can now generate AI images. And this one was so technical that people didn't really know what to say. In fact, the first thing somebody said when I stood up and asked them what their thoughts were, "I don't know what I just saw, but it sounds really awesome and powerful." And I think that that's generally felt across the broader Notion community. And something that they did to help make it more accessible and define use cases very quickly is they held a hackathon this past weekend to very quickly develop hundreds of use cases built by a bunch of other people.
And that's the event that we went to over this past weekend. Starting Saturday morning at 9:00 AM, we met, we got a demo of the tool, and then basically we worked until presentation started, or pencils down on, on at 12 o'clock on, on the following Sunday.
So that was, that was the event, but I'd love to pass it over, Baylor, to you. Explain what a hackathon is and kind of set the tone for what was the environment.
Yeah. So semi-traditionally, hackathon is a 1, 2, 3-day event, sometimes longer, uh, come together, go heads down on the keyboard and build something. Unique, challenging, cool to win a competition. So there's typically a theme or categories that you can aim for. Notion's hackathon, as being kind of centered around this launch of the new developer platform, had 3 different themes of autonomous sidekick, workflow, like extensive workflow, and then what they dubbed chaos mode. Basically, you know, you see it and you know 'That's insane, why did you even build this?' But that's also awesome. Um, and so the end goal here is to win. It's, you know, there's typically a large prize. Like in our case, there was first place was $34,000. Yeah, $34,000 in tokens or credits from various providers— OpenAI, Anthropic. There's also a raffle for a Mac Mini given away by Minimax. And so yeah, the end goal is, uh, typically it's around some specific tooling or specific platform but it is, yeah, a way to get the community together and rally and build some things that most people don't have the time for in their normal work week and give a, a fun excuse to get together and eat some food and have some drinks and, uh, maybe even a laugh or two. And so the, the hackathon this weekend is really focused on the new developer platform tooling built around the Notion CLI that they launched. Uh, tooling called Workers, and then, uh, in the future, somewhat the, the Agents SDK that'll be coming out, uh, in the coming months.
I'm glad you just said that cuz I wanted to stop there real quick before we went further. For the non-technical people, which could be a lot of Notion users, what did, what did you just say? You said CLI, SDK, and Workers. Maybe just give a brief explanation of what those are.
Yeah. So. I'll start with the Notion CLI. More people are familiar with CLIs nowadays because of Cloud Code, OpenAI Codex, tooling like this that gets people in the, the command line. All that CLI stands for is command line interface. I'm pretty sure that's right. I'm going to get my, uh, engineer card revoked if I don't get that right, but yeah, CLI, command line interface. And so it's tooling at the terminal level, at the command line level to interact with Notion natively. So instead of going to the Notion API, we can go directly through the command line, go to what they're dubbing is like the command is ntn, Notion, and interact with data sources, pages, the whole gambit. And this includes tooling for workers. So you have your CLI, the way to interact with Notion via the terminal, via the command line. You have Notion Workers, new tooling to build out some stuff that we can talk about here in a minute. And then the Agents SDK, not really rolled up in this event, but teased in various ways that it's, it's coming, uh, an easier way to interact with custom agents, prepackaged agents in Notion. Via the command line, via the CLI.
So are you telling me that I can interact with Notion via my terminal instead of using Notion?
Absolutely.
And what can I— what is there— are there things that I can do in the terminal that I cannot do in Notion? Like what, what is the benefit of using the CLI besides, you know, wrapping in workers to the equation?
There are caveats. The goal, it seems to be, is that they would have seemingly full feature parity. Uh, the, the main focus and why they wanted to build a CLI as they describe it and as we interact with it is for agents. They're pivoting and focusing on this future of AI interactions in all of software, but specifically in Notion. Where all of your organization's context and what becomes your orchestration layer here, they are giving your agents a direct way, an easy way, a defined way to interact with Notion without needing the API or even an MCP, both still useful and have their place, but adding a new opportunity to interact directly with Notion via the CLI. So we get a lot of use out of the CLI this weekend at Packathon. I foresee myself using the Notion CLI often as I continue to develop internally and for clients as well.
Is it fair to say that the CLI is kind of a, uh, an e—
more navigable map for the, an agent to be able to interact with and do something, and that's why it makes sense to create your own Notion-based CLI?
Yeah. Yeah, I think so. It, even watching an agent navigate, uh, the tooling is interesting in itself of it calling help flags, help, uh, parameters to see the options available the way that Notion has built the CLI to make it very easy for an agent to, to navigate and see the potential calls it can make is, is awesome. It streamlines a lot of the things that I previously would use the API for or even the MCP for almost native for, for the agent workflows that we're building out right now.
Would you, is this too much of a simplification, but like Notion, the UI, very human friendly. CLI is made to be agent friendly.
Absolutely. Yeah. Yeah. The MCP, the CLI—
I don't see the API as that human-friendly.
Like the CLI is even more human-friendly than the API is.
Yeah. Yeah. CLI, MCP, API all have their place. Bryan and I discussed this over the weekend as well. I think I'll still continue to use all three of them, but the CLI is becoming the default in which my agents will interact with Notion at the baseline and then typically fan out from there and find the best use case for, for the work I'm doing in Notion.
Not to put you on the spot, but when would you directly use the API versus the CLI? Like in what, in what instance?
Yeah, I think migration is a great example. Anytime I'm taking, uh, data or really structured flows, data is the greatest example. Something like data migration where instead of needing to make Notion CLI calls over and over and over again, I can build up my data in a very structured way and systematically call through the API very quickly, you could potentially, you likely would still do it, could still do it through the Notion CLI, but I think it makes more programmatic sense to hit it through the API to have structured HTTP responses to know exactly what you're expecting. And the API is, you know, the CLI is built on the API, interacts with it in a similar fashion. But there's something to be said that the API gets hit and beat up every single day. The CLI is still newer. And so if I'm gonna trust anything right now, I'm gonna continue to trust the API to handle my large-scale systematic access to Notion and making edits like that.
And I mean, correct me if I'm wrong, and this is where I'm just gonna shamelessly say I'm not an engineer, so don't blame me if I don't know the answers here. The CLI, I mean, that is a, that is a machine local kind of thing that you can interact with. Or, or am I wrong there? Like an API, you could set it up to kind of run in the web, in the cloud, right? Like speak to the, the non-technical users. Whereas like, I'm assuming like CLI needs your terminal open. That's a local, that's a local kind of, um, activity that you also should be choosing between when you're, when you're kind of deciding which to use between the two.
Yeah. Yeah. That's a good question. A distinction. You could, in theory, set up a, a server that installs the tooling necessary, the packages necessary to interact with the Notion CLI. CLI, but you're right that the baseline for what's necessary to make an API request on a random server as opposed to installing packages so that it can interact with the Notion CLI, it's, it's different setup, uh, even though it is feasible. But yeah, I think that's a good even way to frame it of the more natural thing to do locally as I'm even just in the terminal is to call the Notion CLI to see what's available, to interact with it one by one, command by command. Or, you know, systematically run code and hit the API.
Okay, awesome. So CLI that they dropped, terminal wrapper around the Notion API makes things easier for agents to interact with, with Notion.
I think the, it feels like that, that was a necessity for what is the, like the hot topic that, that he released. Tell us about Workers.
Yeah, Workers is definitely the hot topic and in my opinion, a game changer for the way that people, engineers specifically, but as a whole, the community will interact with, with Notion and in the work that we do. And so Workers gets broken down into 3 parts. There are syncs, tools, and webhooks. Uh, the big powerhouse here, in my opinion, is the idea of syncs, uh, that you can have a synced worker interacting with external resources, external data sources. And pulling that data into Notion in the way and format that you want it. So biggest example here, you have 1,000 Fireflies transcripts sitting in Fireflies or Loom videos or Slack messages. Historically, you can pull some of that in via custom agents or integrations that are already built out in Notion. But when those connectors don't exist, what do you, what do you do? You have to build custom servers, write custom code, do something a little extra to get that data into Notion and interact with it, or even have it accessible to your custom agents. This new tooling allows you to interact with any data source that has an API. If it's a MySQL server or Firefly's API, whatever it may be, there's an easy way to run code on Notion's infrastructure. To interact with the API and pull that data, sync it into a Notion-native database, uh, that can stay synced and you can interact with it manually in viewing it or tell your custom agents to go pull context as necessary and build out a workflow after that. So Syncs is the, is the big one. Would love to dive into that a little more and then we can follow up and hit tools and webhooks.
I have one more, maybe more like overarching question, and I'm not asking you to answer on behalf of Notion, I know you didn't make these decisions, but as a Notion native, like a Notion maxi, why, why am I now, why am I now being led outside of the Notion environment to my CLI? Like, why wasn't this kind of wrapped into something that felt a little bit more first-class Notion feature? Like, is there something that's just not feasible or just not even part of the Notion language under the hood that made it to where, is it an obvious thing to an engineer?
Great question. Yeah, I think the goal is that the Notion maxis stay the Notion maxis, but that this tooling was less focused on the normal, normal Notion user and more focused on the Notion developer or engineer at a various company where they use Notion. And so this is a pivot in my mind, a refocusing from Notion's perspective on how do we make the platform more appealing to engineers, developers, people that interact with code at all, which is increasingly becoming more and more of us. And so not being baked into the UI isn't saying that this isn't featuring for all users, but it is a focused subset of the users that they're really trying to focus on and pull in because they see this growing future in the AI world where everyone's using Cloud Code and Codex and all this other tooling. To give them a new opportunity to bring in more users and even gain favor, I think, in the engineering community for how engineers can interact with Notion and it can be a useful tool for all of us.
And one thing that I would add to that, and just to push back on not being first class, is for us to get a synced property into Notion today, we were reliant on a Notion engineer to build that synced property. The Jira sync or the Salesforce sync because it's directly interacting with the interface. Whereas today that the ability to now create this sync or create these connections is democratized to anybody that can open up their CLI. So it's actually like expanding your use cases to Notion, uh, by, by inviting engineers into the conversation.
Yeah, I don't want to skip over that point. I think that's really, uh, that's really important to touch on because, you know, on the surface level, you might— I could see where somebody might kind of point the finger at Notion and say you're, you're You're veering from your, your, uh, mission to like make software toolmaking ubiquitous for everybody. You know, they've given people the building blocks and the fundamentals. They call 'em primitives. Actually, what you just pointed out, Bryan, was, was, uh, exactly what they did. They are, they're, they're making things primitive. And the example you gave of like an engineer previously had to make a specific Jira sync or, or whatever sync. We've seen, uh, a few instances in the past where Notion has kind of pre-baked in, you know, some of these features with Opinion, like the sprint kind of feature, and the community just threw a giant fit for good reason. I was one of them because it's like taking the Legos and gluing them together and not letting me actually take it apart. Well, give them the credit where they're due. They're doing the harder work of not just giving you the Jira sync and all the other syncs, but the meta sync, like make your own sync, right? Like the tooling to make the tools, and that's what Notion's all about. So really appreciate that.
Yeah, absolutely. And it's thoughtful and intentional in the way that they did it. They built these tools and have given frameworks and templates so that they are easy to build. Building a sync, building a tool, building webhook, very easy and allows you the opportunity to customize it however you would like, pull whatever data you want into your sync database. Format it, structure it however you want via some custom code. And so I think they've been thoughtful in, in building it out and giving us these, these specific tools to allow us to continue using Notion for the things that, that truly matter.
My last comment here, what I really like about what you said about the CLI being kind of the doorway to some of these subset features or features for a subset of the audiences, that's exactly what it is. You kind of have to walk through that door to, to access it and by walking through the door, you're essentially agreeing that this is now, this is now the world that I'm going to agree to be in. And if it breaks, it's my own fault. You know, whereas when you're interacting in Notion, you kind of have some pre-baked expectations of UI and UX and how the software works. And you're, you know, you kind of, you don't want to see a bunch of bloat happening. So you're kind of being forced in the back door. And if you're going to go in the back door, you got to live by the back door rules.
So.
I think that was actually a good call out there.
And I think even, even before we move on to the other tooling that was provided, it's awesome and also a double-edged sword. The same way that we have all the features available in Notion today, it gives users the ability to build whatever they want, but it doesn't mean users are good at building what they actually need or knowing what they need. And so The developer platform has given a new set of tools for non-technical differing skill levels to build out custom syncs, custom tooling, custom webhooks. And it does open the door for a crazier mess when Notion State shows up to help you.
Job security.
Exactly.
Just, it's just layering on another framework that we need to, to be able to provide a client or provide a user on how to think about this and how to approach it. Because when you don't know, you don't know. Like, you don't know what a pacer is for.
You don't know how it's going to impact the company's API limit at a specific time.
You don't know, like, I want this data as fast as possible. It's not about, do you need it? Maybe you only need it to sync once a day as opposed to every 30 seconds, right? It's like just a new— we need to now expand the knowledge with a framework to help people make these decisions.
Or else, to your point, it's going to be pretty chaotic.
Absolutely.
I would want to I would want to encourage any listeners that like, while this is a, there is like a gate to walk through that, that is technical. Um, don't, don't miss the timing of the release of this developer platform. It's not a coincidence. It's not a mistake. It's not, it's not late to the game. They could have, they could have done this years ago. Right. But the reason why it's so useful now is because they're not just expecting a bunch of traditionally trained engineers to interact with Notion now. Engineering is more accessible to everybody and they fully expect people to now be able to use Claude or Codex or whatever to help them build these tools and not have to have the really deep engineering experience. Obviously, you know, there's, there's going to be some ditches to fall off in, but it's now so much more accessible for everyone. And so that's, I mean, I would, I would just strongly believe that that's why it's opening up now in the AI era. So it's not meant to be. It's not meant to be inaccessible to a non-technical person. I think they assume that non-technical people can now at least understand what they want and communicate it and then have tools help them do the more technical stuff, writing the language that they don't understand to get to that point.
And to that point, and Baylor, tell me if I'm wrong on this, but to that point, the place to start isn't your terminal.
Don't Command+M and start to work, try to like work with it. The place to start is find the Git repo, put that into a Claude chat, and just talk to it about this repo to understand what is possible and how to use it. It is introducing you to a whole new way of thinking and a whole new world of opportunity. But make sure you understand it before you just start trying to do it.
Yeah, they've baked the Notion workers template with Claude files, instructions, very clear guardrails for how to build this tooling. And intentionally so they expect exactly what you guys are talking about. And the number of people I'm seeing post in internal, public, and private channels about building a new tool, they have no experience writing code, but they've built a synced worker for their Strava data or random things like this that they enjoy and want in their Notion workspaces is increasing and awesome. That people can pull whatever they want and build fun little side projects.
Well, I know we're, we're really diving into the depths of this functionality. Do we want to hit on tools and webhooks real quick before we, we jump over to the hackathon?
Let's do it. Quick walkthrough tools, little snippet of custom code that you can run on Notion's infra. So synced workers pulling data from an external source can still modify and construct it how you would like. Tools are a way to run a specific snippet to do nearly whatever you would like. It can be initiated by the user, or you can set up tools to be initiated and called by a custom agent. So the workflow that you used to have of one custom agent doing 30 different tasks where a few of them were really LLM intensive or agent oriented. Can now be split up into 30 different steps where 20 of them can be custom tools with a deterministic output and driven by custom code as opposed to burning Notion credits or credits broadly for AI usage when it didn't really need to be AI. So it's a huge unlock for, for us and our clients to have confidence in the output of some of these steps and to increase efficiency in the way that we view token burn in Notion and, and out of Notion as well.
So just to play that back, we should be able to use Workers with custom agents to provide a more reliable output because it's using deterministic code and it should make it more efficient. So less credit intensive and less costly to run.
Exactly. Those are the two biggest outcomes I see from the Worker tools specifically and how they'll impact us and thereby our clients. And then after that, we've got syncs, we've got tools, and we've got webhooks. Once again, a simple idea, but it's that you can set up a webhook via worker webhooks to take in data from anywhere. If it's a Salesforce event trigger that fires when a new account is created, you fire it to the, the worker webhook that gives you a specific URL to send the data to. It catches that data and does whatever your custom code says. And so it's another new way for you to build out complex systems within your Notion workspace and keep it Notion native. I think that's, that's a big upgrade here is that you don't need an engineering team, an infra team, whoever to spin up custom infrastructure, custom servers to do this build out. You can build it out in Notion itself and not have to worry about the additional privacy and security concerns that come with an external platform. You can spin it up in-house and trust that Notion is handling all the complexity. On their side.
Yeah, I think that's the piece that I'm most excited for.
In this Vibe-coded era, for us to create these custom solutions, we had to stand up our own Vercel environment to deploy this code. Now it's native to the platform, which will make it much more likely that enterprise organizations are willing to build this, these capabilities and functionality into the, into the program, which I think that that's just such a massive unlock for, uh, for IT-intensive organizations.
Yeah.
If you really shed that layer of like the platform being used and you get down to like these platforms are being used to create workflows, you know, if, if, uh, we, we were using, uh, specifically speaking about like enterprise as Notion State, you know, like you just said, Bryan, we could, we could stand up Vercel and Supabase and all of our own, and we're building our own tooling and Bader can speak to how, uh, allergic to that kind of thing, uh, a business would and probably should be, right? But now, you know, let's, let's assume they're not, they're not okay with that. Now we can just not talk about the platform, but talk about the workflow and the logic. And we don't even have to introduce any of that custom, you know, custom made stuff that's Vibe-coded. We're using, you know, the platform Notion, their own infrastructure, their own security. It's, they've already provisioned it. What's the word? Secured? I don't know. Like the formal process, businesses have already gone through the formal process of, you know, calling this app and this platform okay and safe. And so now we actually have a wide open door to help people without introducing, you know, vibe-coded, vibe-coded products that we have to keep up.
Yeah.
Yeah, exactly. I think even in my time at Notion State, the number of clients I've worked with that we've stood up custom servers for or a similar idea where there's always a step of a security audit from an IT team or security team that says, okay, well, You're standing up a custom server. I need all, you know, compliance checks on these things. Whereas now it's, we've already audited and said Notion is compliant for holding all of our organization's data. We're continuing to keep that hosted within Notion infrastructure.
Exciting times. It's such neat and such cool functionality that is being brought into the platform. I know we're, we're kind of running out up on, on the, the time that we have allotted. Is there anything else that we should cover on this one? I know we didn't talk about the agent SDK, but I also acknowledge that.
It's not even released yet, so maybe it's an episode in the future.
Should we dive over to the, the hackathon?
Let's do it.
All right, cool.
Well, Baylor, tell us a bit about what, what we did, how we approached it, and like why we, uh, and why we did it, what we did.
Our aim with the hackathon was to build something useful for Notion State, was to use and get to know the tooling as it was formally launched or is formally in beta now. But ultimately we wanted to build something that had value for us and our team. And so that's exactly what we did. We figured out how to optimize one of the most repetitive workflows that our team experiences internally. Bryan, you can talk more to that in a second, but we wanted to use every part of, of this launch. We used syncs, tools, webhooks. We integrated with external data sources. We integrated with external Notion workspaces. To bring data back into our own home workspace. And we wanted to run the full gambit to see if this developer platform really had what we needed to continue growing and building out custom workflows for our clients. And I think it delivered in nearly every way we wanted. We used every, every part of it and got to see that this is really adding amazing featuring to what we can do internally and externally for our clients.
Yeah, I don't think in hindsight, I don't know that going with let's use every single aspect and component of, of the available solution was a winning solution. And I mean, I can say with certainty it wasn't because we didn't win. But I think, uh, from the mindset of like getting a breadth of understanding for you, for me, and for Ava, I left going in somewhat ignorant and I feel quite confident coming out of it because like you were saying, we synced with external software and we feel confident we can do that with transcription software, messaging software, your CRM, basically any other data source now because we have confidence in how that works. The really neat one was syncing with other workspaces. It's always been such a wall from one Notion workspace to the other.
The amount of copying and pasting required, and then the paste doesn't work if there's an image, uh, the duplicate doesn't work if there's too many blocks, uh, is, is, it was so painful that typically a lot of our data and information is siloed in these, these workspaces and it just stays there. And now like we were able to really test and bring that all together and it was such a cool, cool thing for us to learn. And to your point, like the, the possibilities coming out of this are honestly a whole new way of working if we're able to, to really figure it out.
Yeah. I think the fact that Ava was able to lead a session for our team and explain Workers is a testament to what happened this weekend of a comprehensive understanding of the possibilities that come out of the new developer platform. Even if the only purpose is talking about it internally and being able to flag those things for clients or prospective clients. Huge, huge unlock for our team.
Yeah, I'm not trying to, um, retroactively backpedal here or copium or whatever you want to call it, but it was pretty obvious even from the beginning of talking about going to this event, which I unfortunately couldn't go to, that the primary objective was not necessarily winning. Spoken from the loser's platform, right? Uh, was not winning, but no, it really was like, let's learn, let's learn these tools deeply. Because they're going to be important and we want to learn them not just for ourselves, but for our clients. And so I think that was, that was pretty obvious. Even, you know, from the, what you built and the strategy of like trying to use everything to do something enterprise and useful is a testament to that. And so, you know, we're walking away the real winners. We don't need 34,000 credits from OpenAI.
Yeah. Yeah. It was, it was really insightful watching some of the winning presentations because yeah, we were in a whole different ballpark than what people were building. They're both fun. Uh, first place was Dunder Mifflin Infinity. It's a custom UI built on Notion databases that was a simulation for The Office, like, show, uh, with scripts and animations, custom sprites. It was, it was amazing. But compare that to our Notion-native workflow tool. That uses every part of the platform, it's— we're talking different leagues here. And so it was almost comical that we were competing in the same hackathon because very different intents. Theirs is awesome. Mine changes our company's life every single day, and I'm all about that.
What were the other ones that you remember?
Some other fun ones were a Lord of the Rings themed battle simulator, custom. Most of these have custom UIs, custom front ends, just built on Notion as the backend. And so Lord of the Rings, there was one called Snoopy AI that was a little more Notion focused, but automating callback system for small businesses, some really cool use cases. Things that I, we didn't even consider when building for this hackathon. It was always, how do we, how do we drive value for our team and our clients? And so it was funny being in this room with, you know, a ton of hackers building some amazing things, so creative. And we're like, how do we keep this Notion native so that we can really be Notion maxis? And we're like, oh, we're in the wrong house right now.
The important thing about that was like the idea of workers and the creation of them. Is to keep people in Notion. Like, like we wanted, like the purpose of this is to bring your data here so you don't have to app switch. And everybody that won literally created another app for you to leave Notion to get to.
So we'd like to file an appeal is what we're saying.
No, no appeals.
No appeals.
Okay. We'll go to the next one though. Yeah. We'll probably still build something that's workflow, workflow related though.
Yeah. It was, it was almost comical our first round judging. When we're showcasing our Notion native tool where we're, we're all so stoked that it's Notion native. And I think they were underwhelmed that it was Notion. And so it was just, it's funny coming from the Notion maxi side of like, this is what we do, this is what we love to these, uh, the first round judges. I don't think Notion employees, they're, you know, employees at various different companies in, uh, the Valley. And so it was just funny seeing this different perspective on, on Notion that we don't always interact with. But it was, it was enjoyable.
Amazing. Well, as we're wrapping up, what was your, uh, what was your number one highlight from the weekend?
My number one highlight? Learning more of the Bryanisms, the Ava-isms, hearing my own callouts of that. Apparently every time someone enters the room, I go, what's up? What's up, guys? Uh, yeah, I think getting an opportunity to interface with different people from the community, outside the community, and even the, the internal Notion engineering team. You can talk to some of these engineers that built the developer platform and hear more of what's on the roadmap and what's coming. Gets me really excited for continuing to, to build on Notion and interact with their internal teams to hopefully make Notion this full platform that anyone can use and will use for their whole organization.
Absolutely love that. My favorite moment was the workshop that we did the Friday before where we just sat in a conference room for 4 hours and it was like 80 degrees in that conference room, but we just banged out this insane diagram where we put our brains on the board. It was just cool and fun for us to like think deeply like that in person because in a globally distributed company, you don't get that chance very often.
Yeah, even just seeing the output from this, uh, I even Slacked Bryan today. Like we should, we really need to do like a quarterly or a monthly Notion State hackathon. I love that we have an async remote work culture and we're always going to like stand on that, but there's nothing like putting people in the same room, whether it's virtual or real, uh, for an extended amount of time with a problem to solve and just seeing what happens. I, I'm just all about that. So, uh, I wonder if we can make that happen.
We absolutely should. And I know, Josh, you've mentioned a few times the FOMO. If it was any other day, we know that you would have been there.
You were just being a good father, celebrating your daughter's second birthday. And honestly, we would have been upset had you come because I would have been going against your principles and first principles on like family first. So we respect you for not being there and we wouldn't have expected you for being there.
That's right. That's right.
Appreciate that. Yep. Had a good time at a 2-year-old's birthday party. I say that funnily enough, but it was really fun. Good time hanging with family and yeah, appreciate that. Something that we want to take seriously even at Notion State. Am I shamelessly kind of like talking us up a little bit in case you're interested in working for us? Yes. We have a very async remote culture. We care about life and we want to you know, not just talk about it, but be about it. So yeah, anyways, that's where I spent my time, uh, at my, my 2-year-old daughter's birthday party and, uh, had a good time there.
Yeah.
Well, it's, it's been fun on mine. Thanks for having me. I'm honored to be the first guest on the Notion State of Mind podcast. Is it weird if I listen to this podcast afterwards or I gotta keep my, my 5 for 5 record here?
Yeah.
I mean, just, just have fun listening to your own voice. I don't know if you've ever experienced that, but it is a, it is a hill to climb to get used to it.
Yeah.
All right.
Well, that wraps it up for the, this episode of the Notion State of Mind podcast. Uh, we hope that you found something valuable, whether you were technical or non-technical. We appreciate you tuning in. Thanks to, to Baylor for, for showing up and, uh, even going to San Francisco and, and, uh, participating in the hackathon. To Bryan and Ava for going as well. And, uh, we hope that you found value out of this podcast episode from the leading Notion consultancy.
See ya.
More from Bryan

Bolt-On or Built-In // AI-native services, scaling, and the people who make it work









