|
# Master Transcription File |
|
Generated: 2025-06-28 02:51:49 |
|
Total Videos: 17 |
|
Format: simple |
|
================================================================================ |
|
|
|
Video: Add Basic Auth to Bolt.new with Supabase in MINUTES |
|
In this video, I'm going to show you how you can add basic authentication via a superbase to your bolt.new app. Now, if you don't know what superbase is, it's basically a development platform that will let you also host a database along with what are called edge functions. These edge functions are super important for bolt.new because you can use them to connect the things like Stripe, to create a database, to talk to in real time and store the data from your app, to talk to things like OpenAI and Cloud behind the scenes, as well as add authentication using Google Sign-In or Facebook Sign-In. What superbase enables out of the box is an easy integration into some sign-ins such as emails, like an email and password, as well as other platforms that are more wildly known, including things like Google, GitHub, Facebook, Discord, etc. So, using superbase is one of the easiest ways to add email and past authentication, especially if you want to do it in a very short amount of time. Now, if you haven't seen superbase before, it looks something like this when you log in, you'll have a series of different tabs and the one we'll focus on is the Projects tab. So, what you want to do is if you're entering for the first time, you want to click on new project, and once you do that, you'll be able to call this whatever you want. So, we'll call this bolt demo project. Now, if the do here is enter a password, so we'll just put bolt one, two, three, and then we'll close that, we'll create a new project. Now, you can see here my superbase instance is ready and we can tell that by the project status with the green button. Sometimes, this will take anywhere from three to five minutes, depending on your configuration of the database you're setting up, but it should be straightforward and then you can use it out of the box immediately. So, let's try to actually use this in action. So, I'm going to build an app here that allows me to enter my roadmap for building my first web app using vibe coding by dragging on a different set of elements onto the screen to construct it with the ability to sign in via email and password. Now, you're going to want to just ask for the user interface to be designed first, and then it should just basically have a button that you can use to log in, but once you actually click it, it shouldn't be able to do anything yet until we actually enable that into the base itself. All right, so now we have our login page and if we open this up in a new tab, you'll see it looks like this. So, if you go to sign up here and click on here and we say mark, we put mark at gmail.com, and we enter some random password. There's no actual authentication, so it should let us create the account with no real logging of that username, and we should be able to use our app out of the box. But obviously, we want our sign in and log in to be functional. So, we'll do that by going back to Bolt, and then all we have to do is go into the integrations here, select Superbase, and this will let you very easily connect your Superbase database. So, I'm going to go down to one called Bolt Demo. We'll do Connect Project. So, now it's connecting to Superbase, and this will take anywhere from 10 seconds to a couple minutes to fully hook up. But once it's ready, we can now start building functionality into our app using the logins from Superbase. Now, you should get a confirmation that you're now connected to Superbase, and if you want to double check, you should be able to see this Superbase icon right here that when you hover over and click, you'll see the name of the actual database you connected to. So, now we'll go back into Superbase and enable the email authentication. So, now that we're here, if we hover to the left, we can go and click on Authentication, and then we can click on Sign In, and then Providers. And then once we see that, you'll see by default, email is enabled. One thing we want to do is, just to make our lives a little easier while we're testing this app, we'll toggle off the Confirm email. Now, typically, this is when you sign up, you get some form of link in your email. They have to click to enable the account or verify the account. And while this is super important to build in production level apps, if you're building this just to test it out and go back and forth, you can unclick Confirm email, and then that will basically allow you to enter whatever email you want, go through that experience, and then you can come back later to set that up because it is a slightly different process to make sure that you have something called a call back URL that's listening for that confirmation to actually log that that email has been verified. Right here, you can actually dictate how long the password should be, whether there are any specific password requirements. In our case, we'll keep it simple, and we'll just click Save here. And then once we do that, it says Successfully updated settings. And now if we go back into Bolt, I will just dictate our instruction. I'll say we have now connected email authentication to Superbase. So make sure that the front end of this screen is actually logging the emails used to create accounts and log into accounts in our Superbase instance. So in this case, we'll just send that over to make sure that the connection between the front end and the back end, which is Superbase, are making that handshake. And what's a really good practice is actually to audit what's happening in Bolt.new. So you can see here it's created a file for Superbase. It's creating something called Auth Context, which is where it's going to log basically what's happening with that login. Then you have an Auth Form, which is likely just going to connect that login screen to hook it up to a Superbase instance. And it's going to keep going until it's ready to go. All right, so here Bolt confirms that we've made the authentication connection to Superbase. It gives you a summary of the changes. And if you are inclined to just take a look, you can click on code here and you can visibly see we have an Auth Form, we have Auth Context right here, and a few other files as well. So if we pull this up in another screen and we go into Sign Up and we try this again, I'll just put some email here, mark one, two, three at gmail.com. And we'll say mark one, two, three, create account. Now it does create an account in this case. And if we were to check in Superbase, we should be able to see it logged. So in Superbase, instead of clicking on Sign In Partners, we want to click on this users tab. And if this actually logged, then when we click on users, we should be able to see an ID, my email, and then a created that date and a last sign on date by default. So we know this is working. So if we go back to the app and we click Sign Out, we should be able to go sign in with those credentials. So mark one, two, three at gmail.com. All right. And then mark one, two, three, sign in. And there we go. You now have a email and password sign in enabled and authenticated. And yes, you can add on confirming your email as another layer of security and change the password requirements. But this is all you need to get started and enable basic authentication in your app. |
|
|
|
Video: Add Stripe to your bolt.new app |
|
A gestor bod y fas po Unelag G1 roedd roedd y Rael Acaron Scum yn Bloss incorporates mewn gweit. Wel i'r buwabil acти am nodi'r unor�ithó at yw fe allarw wrth na'r gwybod digon. Ond gwyboddd â opardakop o сот diaf lime gyfer ameff fifthtadesau o' un cysroedd. O'n cael eich ar y framsadau GymraBrower cyfan waseau a f design fellyír am myற ei carfodd cyn Estartrwyl. Mae yn gallain o gywariau yn pifatredd gwneud i Corneddfae Boyr. O eich helpodaeth ganeth gymerr. Fern<|cy|> ac o gynydd ymneud ym gyflullahis o hwnna ved bewerriidydd cylwyna sa eio prejudiceio牛 sy hiding o f�ont rel fognol Diddiol hefyd. S it NPC yn sylwy i achor. P teethixih reconciliationio rhosesioم o eich golch chiol. corraynaeth ar bod datgodetiot ecマers決 yn ei befaithaeth西au Alw dewyn itos o paprysiai'r sef y krאun esos o fy lid lwy cy br arrowfter. Mae'n lew loft sefyddonwrn fel diam sefydd newisaithnosti. Twine ynu. Fel dwi dw�ch yn dDEfa wedi ei fоль recognise. Mae'r ddehti neu hynw hagu f natureb i hos i'r righuriau. Mae amsernaethill yn ag Mickоже, unrhymd a dyf像. Mae'n c nodi'n gwaith chi o gylieddu porau. eingesbych yn ad Islands, a rofbwnod en f Jew trwyl pr sydd ymrydiob Platform rofbwnwmyr cyn gyfer Ysggt Diels until a'n idald bu Bus Child Pac первag llem.500- proverbio.髙 hyn. I chattergo problwn, rhag-blod y prgymannolwa ein rheolol rhag-blue. Diolch,an bro Wrestling, angen y gy resiliaeth fetnil,io hij化 chwa angen 2, mi cyynsedru. Y bobl yn yr un ac? Wais seráimwch obyd yn y ung, og mae'r draf yter llwyheu utiliser ceis na oafd oafdai fail. Slal, mae'i phrrolau pwholl y gydol gote Kinder of Duty deweiroareň. Llelidd, dysgeiferstir i'r psfuHelp di wedi 40 myself o Idy ein gall o èr feastu yno. I'ot paddaint gofnיל da newhr y tuš. Diskiad a. Twi就f y suherda fistatio fefdaint gofnil Burning itch tho, yw unrhyw gael'n seaig subscribe yw.'rementwjfa'r dwi'r ryflah ond ddugau a gydphidio darreg i'r pr Waidai amser, dim llaeth ridden yr! Maenodliad, ydw cael ry ry m científico Caif SHRIPо'r 100e. X pouvez ryd i d advisegu i gwaith ito rhisi'r dya'r i ddellawyd fwyddyn yn mewn i am siwn i gerdo'r failoc i telefon hon, si ryd ito bywna, ôl iawn y dysguain unrhyw i, ryd i byw Sympiol, wedi'r gallu ryd. Roedd interactiveir ac pioneudon y cementaniaeth biting yn dyna beth ffawhel. gan epigui yng Nghymru a ddieddol. Nghymarych. Da ddag fweitol mewn dyngyddINU. |
|
|
|
Video: Adding user authentication to your bolt.new app |
|
Whenever I'm building an app, I usually start with the most distinct feature first, like creating a note in a notes app or displaying a chart in a data analysis tool. But as soon as this works, it's time to take care of the fundamental part of every application. And that's Handling Users, also called Outentication and Authorization. So let me show you how to add the ability to create user accounts in your bolt-up and ensure that each user has access only to their own data using a service called Firebase. If you don't know what Firebase is, I've covered it in the previous tutorial where we've added a database to a habit tracking app. While not required, I highly recommend you to watch it at some point. We'll continue using this app as an example, but this process will be the same for any other project, assuming you have already configured it to use Firebase. Let's go to the Firebase dashboard and click Outentication. After your first visit, it will also be available in the Project Shortcut Mini in the sidebar. Right now we have a clean slate. So let's set up a signing method. In your app, you might want to have several ways of authenticating users. So here, Firebase lists a dozen of different signing providers. But let's take the most universal email password method and let's click Enable and Save. Now, if we go to the User Step, we can manually register a user, which might be useful if you're making an app only for yourself, and don't need a sign-up functionality, but we'll have a proper registration form instead. Before we switch to Bolt, we'll clear the current database content. It's not absolutely necessary, but adding users into a wrap will change the data structure. After all, each habit will be tracked for a specific user. So it's easier to populate the values from scratch than to manually fix the missing user data later. We need to manually type each collection name to delete it. And let's go back to Bolt. So what we want is to be able to sign up with email and password and log in. I also want users to have a name they can define for themselves. So we can display that somewhere in the UI instead of an email. Bolt updates the app now. The off controller provides the user information to the UI. Then we get the authentication-related components. And finally, an update to the habit-storing logic to include which user a given habit belongs to. And it looks like now we can log in. Of course, we don't have an account yet, so let's register first. And we have no habits because we've cleared the database earlier. But we can already find our newly registered user in the Firebase dashboard under authentication. Let's go back and add a habit again. Mark it as complete and see how it looks in the database. As you can see, there's now a user ID in the habit progress and for the habit. This is crucial for the database to return only the data for a given user. Let's make sure the app actually requests only that piece of data. For that, I'll quickly register another user. And yes, Tomic1 doesn't see Tomic's data. But if I log in back as just Tomic, my work-up habit is still there. I want to add two more user-related features to the app and then there's one super important security issue that we have to take care of. So first, now that we have the concept of user profiles, we want to give our users a way to personalize them. Let's add a profile page, leading from the user name in the header, to change the name and password. And Bolt creates the component with the form that has this common pattern of provide the old password and the new password twice. Speaking of typical practices, usually when you create an account, you receive a welcome message in your email. And most of them, you need to actually confirm that email address. Right now, when I check the email I registered with, no such thing has happened. So let's add email verification. We got a new component, probably with the verification text being displayed in the app. And our previous components get a small update as well. Nice, it shows up in the app. Because we've just implemented this feature, I already know no email was sent yet, re-send it. Let's check our inbox and look at that. We have a pretty decent looking verification email here. It's even personalized. This email is actually being sent by Firebase. And if you want to change the content of the message, you can do it in your dashboard. Let's visit authentication again and go to templates. Here we have several predefined transaction emails. And you can see the source of what just landed in my inbox. Okay, time to verify the email. And when I go back to the app, my user is verified. Now, if you remember before I said there's one super important security issue that we have to take care of. What our app is doing right now is asking the database for certain pieces of data that happen to belong to a currently logged in user. But there is no mechanism that would prevent someone from asking for, say, all the data in the database, or even from modifying or deleting it. This is where security rules come in. They're defined on the Firebase site and specify which user can create, read, update, or delete which resource. When we initially connected this app to the database in the last tutorial, we've allowed full access because we didn't have users yet. We need to change that. So now that we have the authentication, how should we update the Firestore Access Rules to make the app secure? Bolt has created a file for us and explained what steps we should take in the dashboard. Let's copy the rules, go to Firebase, Firestore database, and rules. Remove the previous rules and replace them with the ones we've just copied. You can, of course, check the logic of what's changed. For instance, a habit can't be read or modified if the user hasn't verified the email or if they're not the habit's owner. Just in case, let's check if we haven't logged our user out from the data, which we haven't. All right, now we have an app with a database and a proper handling of user accounts. So this was useful and you've learned some new things. Don't forget to let me know in the comments what other topics you'd like me to cover next. I'm already working on the super-based videos and plan to do one on striped payments as well. So see you next time! |
|
|
|
Video: Better prompts in bolt: supercharge any prompt instantly! |
|
Enhancing a prompt might be the easiest way to improve the quality of your project from the get go. Higher quality prompt will make it look better and even add some useful features you might have missed in your initial idea. Here's an example. Today I'm building a habit tracking app and at this point this is kind of all I know about it, so let's see what Bolt can make me from this prompt. So this is basically what I've asked for. It works. Looks quite okay but I think we can do better. Let's start again but this time after I write my original prompt I'll use the enhanced prompt button. Let's see what we got. So we can already see this is a more refined set of requirements. It includes a strict feature, local storage persistence and clean responsive UI. These are things that are all expected from the app like ours but they were missing from the initial prompt. We can now edit the prompt or actually enhance it even more. This gets us a really elaborate specification with things like form validation, additional screens and routing. Let Bolt generate this app. I can already see this would be a much better developed app. There are multiple specialized components being created and sure enough our app has now dedicated pages. Let's add some data really quick. Okay this is a much better starting point. So remember the prompt quality makes a world of difference to the end results. And you can ask Bolt to assist you with that with a single click. |
|
|
|
Video: Beyond the Chat: AI-Assisted Coding Evolved |
|
Hey, everyone. Welcome to our workshop today. My name is Kate, and I'm part of the marketing team here at StackBlitz. This is our first webinar discussing this content, and I'm super excited. We have Eric and Dom with us today, and we're going to dive into Web Containers and AI. For those of you who haven't used Crowdcast before, the chat is on the right-hand side. There's also a separate Q&A section for your questions, so feel free to throw them in there, and we'll answer them throughout the presentation. This session will be recorded and sent to everyone who has registered, so don't worry; we'll get the recording to you after the event. With that, Eric and Dom, welcome to the stage. Hello, everyone. Hope you're doing well. Let's get some good vibes going in the chat. How's everyone's day going? While you're doing that, I'll share some of your favorites. Just a quick introduction: I'm Eric, the co-founder and CEO of StackBlitz. I'm joined by Dom, who is the lead engineer of Web Container and Bolt. Our servers are experiencing crazy growth day over day, so we're lucky to have Dom here to learn about how Bolt is built and how we can all build with Web Containers and AI. I'm really excited to have you here for this workshop. Today, we want to cover three main things. First, we'll talk about why we built Bolt.new and why we're excited about it. Second, we'll discuss how Frontier AI models have changed the game for code generation and coding AI apps. There's a huge new opportunity for experiences that you can build now, and it pairs extremely well with our Web Container API, which is what Bolt is built with. The merger of AI and Web Container is just unbelievable, and we want to talk about what's going on in the AI world. The folks at Anthropic have made some content for us that we'll share with you either during the talk or afterward. Finally, we'll dig into the Bolt.new code base on GitHub. We'll sit with Dom and walk through how this thing works. I'm stoked for this because my biggest contributions to Bolt are not the code, so I'll be learning as much as you all are. This is our opportunity to sit with the lead developer and understand deeply how this code base works and explore it together. This workshop is not a step-by-step tutorial; it's an architectural workshop. We want to convey the things we've learned building Bolt and integrating with AI models to enable you to take that knowledge and build amazing stuff. In the chat, I'm seeing some good vibes. Folks are playing with the Bolt.new API. Maybe not all good vibes, as it sounds like Bolt may have failed for someone. Just FYI, it's in beta, and we are bug-fixing 24/7, especially with the amount of traffic we're getting. Folks say Bolt is beautiful, and we appreciate the kind words. With that, Dom, what do you say? How about we get started here? I think that sounds good. I'm ready. Cool. We're going to keep this very conversational. I want to encourage everyone, as we're chatting, to feel free to put questions into the chat or the Q&A section. We'll be keeping an eye on that, and Kate will be flagging stuff for us to answer. This is your opportunity to sit with folks who have spent a lot of time building this type of AI code gen product and Bolt specifically. We'd love to answer any questions you have, so please feel free to throw them in the chat. Whenever other products launch, I always wish there was an opportunity to sit down with the people building them and get the inside scoop. This is part of the reason we made the core components of Bolt open source. We think it's super cool and want to see more of this stuff out there. So, to kick that off, Dom, let's talk about the origins of Bolt. I'm curious to hear your point of view on the origin of the Bolt story because I've got my own version. Maybe I'll do a revision on yours after I hear it, but I'm curious to hear your take on how this thing came to be. That's interesting. I think it actually comes a long way because the main thing that makes Bolt shine is actually Web Container, which allows us to run full-stack applications in the browser without using any cloud compute. That makes Bolt unique because we have the local compute. We came a very long way already because we created Web Container. When did we launch this again? Was it 2021? Yeah, so in 2021, we announced Web Containers. It's a node.js runtime for the browser, and you can run your full-stack applications in the browser. We worked really hard on that technology. With the trend of AI, which has a huge impact on everybody's daily life, AI is integrated almost everywhere and is so helpful. People are starting to realize how useful it can be, not only to get started on new projects but also to augment ourselves as developers and make us better. We decided to combine Web Container with AI, which can be phenomenal. It's an unseen user experience to some degree, and that's the origin of Bolt. Well, I think Arno posted a message a couple of minutes ago that nails why Web Container is such a good fit for AI workloads. AI is very good at writing code, but code by itself is not super useful without executing it to see if it works. Now you're talking about how to execute that code in a fast and secure way, which is a huge problem. But it's a problem we solved with Web Container. If you've ever used any other online IDE, they have to spin up a VM for you in the cloud. Any code you're writing is put on that VM, and there's latency to send it over the internet to the VM, execute it, and send it back. If there's something malicious in that code, you better hope your VMs are secure. Otherwise, people will mine Bitcoin on your servers. It's a nightmare. With Web Container, we're able to run all the compute within the browser sandbox itself securely on your device. When you boot a Web Container on this webpage, when I hit refresh, it boots a Web Container. There's an operating system with node.js, npm, etc. The same with Bolt; when you load a Bolt project, it's booting up a micro operating system in milliseconds within the browser sandbox. Even if malicious code is put in it, it can't break out to the rest of the machine. Security has always been a first and foremost consideration for us. StackBlitz.com has like three million developers a month that use it, securing tens or hundreds of millions of developer environments that are getting spun up is a nightmare of a challenge, especially if you want low latency and a low price point. We've spent half a decade on Web Container at this point, and it took us multiple years to get an alpha out the door. This is deep technology that's really hard to build. As the AI wave hit, we were very interested in the idea. Earlier this year, we built a prototype called Bolt with the same product idea, but the models at that time weren't good enough to output code reliably. So we shelved that project. Then back in May or June, we got an early peek at some of the stuff Anthropic was up to with Claude 3.5, which is maybe a natural segue into the second thing we're talking about today: Web Containers plus AI. In the past couple of months, there's been a complete upending of AI models in the frontier AI model research labs. Anthropic specifically has done some incredible work making AI models that are very good at writing code. Claude 3.5 is the first of these models that has really come out. This is why a lot of coding tools in the past couple of months have exploded, like Cursor and now Bolt. What's going on here is the models under the hood have improved, making these sorts of products a lot more viable than they would have been before. It doesn't matter how good you can execute code; it doesn't matter how good Web Container is or a VM or your local machine. If the AI is punching out code that's garbage, it's not going to run. It's a waste of your time. But that's not true anymore. The code coming out is good. For those of you trying Bolt.new, you know what we're talking about, and the stuff is only getting better. That's the big tectonic shift where we saw that we pulled Bolt.new off the shelf and said, "Okay, we're going to build this." I remember Dom built the prototype within a couple of weeks. I remember when I used that, Alex, our chief of staff, who's not an engineer at our company, got his hands on the two-week-old version of it and spent six hours building a website for his Airbnb listings. That's when we realized there's something interesting here. There's a huge potential, especially because costs are decreasing, and performance and quality of these models are increasing. While at the same time, these LLMs become more affordable, it makes even more sense to hop on that wave and try to build a great product using that. 100%. As far as the future of Bolt, maybe Dom, you can give some hints or sneak peeks at where we're going with this thing generally speaking. Sure. We're working really, really hard. I think there's already a whole bunch of things. Eric, I don't know whether it was mentioned already, but Bolt.new, at least the core of it, is open source. You can find it on GitHub. We're going to take a look at the code base and explore it a bit together. But essentially, that's just the core. It really shows how you can build AI agents using the Web Container API, and that's just a beautiful magic combination here. We're going to take a look at that. But then on production, if you noticed, if you checked out the code and ran it yourself, you'll notice there's a whole bunch of features that aren't necessarily part of the core because it just serves as a baseboard example. But yeah, there's so much stuff that we're working on really hard, trying to decrease latency, trying to get the model to spit out code even faster to improve the overall performance. We're working on optimizing token usage. We're trying to improve performance and latency. We're listening to feedback very closely, so feedback from everyone in the community and everyone that uses Bolt is super important to us. Versioning and rollbacks are something that will definitely come, and we're trying to improve the whole error handling. At the end of the day, in my opinion, that's also what makes Bolt unique because if an error happens, a lot of people, or even myself sometimes, are like, "Okay, what do I do?" I open up Google, Google the error, and try to find out what I have to do to fix it. But Bolt can automatically fix it for you, and we're trying to extend those capabilities to terminal errors and all of that stuff. There's a whole bunch of new features coming to everyone, so it's very exciting. There are a couple of questions here already. Do you have a feature request page? One of the questions is. Yeah, I think our GitHub repo is probably the best place for that. Feel free to file an issue. That would be the best way to do a feature request. I don't know if you have a tag in GitHub yet, but if not, someone from the staff can use discussions for that. Discussions will be good. You can upvote very easily. Start a discussion on the GitHub repo. I'll post the repo here. Dom already did. Thank you, Dom. Another question we got is, "Is it realistic that we will also be able to run Python-based frameworks inside Web Containers in the near future?" Maybe not near, but it depends on your definition of near. Dom, do you want to take this one? Python frameworks, yeah, near. I mean, I think Eric hit the nail on the head. I think that's like Python. So what I will say is that Web Container does have Python support. We announced that at Vcon last year since we introduced Waze support for Web Containers. Well, Python is basically powered by Waze. So we do have Python support. It's beta experimental. But if you just stick to vanilla Python apps, you can pretty much do that even in Web Container. You can run Python from the terminal and just have it spit out Python. When it comes to frameworks, that is a different story. I think that will definitely be a little bit down the road, not in the near future. So I think that's probably where we are. We'll have more to share. Right now, we are drowning in the current demand of just Node.js-based stuff and stabilizing this. By the way, we are hiring. Maybe a relevant callout. We've had a lot of folks come in. Let me get our careers page here. If you're interested in working on Web Container stuff, this would be a fantastic time to come and take a look at opportunities at StackBlitz. There is a lot of cool stuff going on. I wish I could actually talk about it, but we'd love to chat. So take a look at our careers page. We are fully remote. We are not doing return to office. I'm personally, and I've got a kid, I don't have to fight. Yeah, get on a boat and come to see our folks. We can't afford a plane, so you've got to set sail. But check out our careers page. I totally forgot the question that was asked. Apologies on the side. Oh, right. We were talking about Python. There's a very tangible path here. As Bolt stabilizes in the Node ecosystem, we've already got some initial work on some of these other ones. There's going to be more that comes there. I think it's really just a question of timing at this point. But yeah, we're expanding the team. We talked about it. I saw another question. Okay, so maybe you can. What are the questions? Some have come up here. Yes, so there's actually one I really want to read here. Is your long-term vision for Bolt/AI programming to eventually remove the need for the developer to write any code at all? No. The point of AI, at least in our view, is not to replace developers. AI allows you to turn one keystroke you would have to type manually normally, but it turns out the output of that is a thousand keystrokes. That's the value that AI brings. It's just as important as ever that someone who is a smart engineer is sitting at the keyboard typing commands, instructing how the software is built. We see this as entirely augmenting developers. By having a higher abstraction layer, it allows people who wouldn't classify themselves as engineers to be able to build real applications. We've already seen this happen with Bolt today. People have posted on Twitter, etc. There's a sales guy who made a site for his daughter with Bolt. If you think about the progression of things like image editing, before Photoshop, it was way more complicated. There was a very small number of people who could produce really crazy images. When Photoshop came out, suddenly there was an entire new larger audience of folks who could do that. That's the double-edged, two sides of the coin that are both great here. Engineers are going to get even further and more effective and be able to go way more complicated, way bigger, way more sophisticated things. People who are not day-to-day engineers are going to leverage these tools to build stuff they never would have been able to do in the first place. We see this as purely good things and not replacing people. It's just accelerating the heck out of what people can do. Awesome. A couple more questions. I'm just going to keep firing away here. What are the frameworks supported by Bolt currently? We have pretty broad support of the Node.js ecosystem. You name a Node.js framework, it almost certainly runs in Web Containers. Anything that's V-powered like SvelteKit, SolidStart, Remix, etc. Custom V-config, Webpack, the Webpack ecosystem works. Next.js works. If you go to StackBlitz.com, any of the project starters you see there, those all work. There's a heck of a lot of them. Very broad support in the Node.js ecosystem. Excellent. There was a question. Let me find it. Sorry. I would love for you to give a small example/explanation of what the "access external APIs" feature in Bolt's pro pricing refers to. Can we currently access externally hosted APIs from inside the Web Container already? Is there a way to make Bolt aware of APIs we'd like to use? I think I do have the CORS proxy turned on in Bolt. It depends on your subscription, right? The CORS proxy is not enabled for everyone. Eric, what Eric is saying is for Web Container, because it runs entirely in the browser, we're limited by CORS. Browsers can't make any requests to any backend service, which is why for Web Container, we shipped a feature called the CORS proxy. It's enabled for Web Container, but it's tied to your subscription plan. You can enable it or not. Got it. I think right now, and this is actually a good point of feedback for us, I'm not sure if in StackBlitz.com, if you have the paid subscription similar to Bolt, you can access APIs that normally you couldn't access from a browser. For example, if you want to ping the Anthropic API, they do not allow you to do that from a browser. CORS will disable it, but in StackBlitz, we allow you to do that. I need to double-check. I don't know if we rolled out our CORS proxy on the Bolt side, but if we haven't, that's in the queue to ship. You can try out the CORS proxy on StackBlitz now, and we'll be rolling that out to Bolt shortly. Excellent. This one, I'm a solopreneur, and I need to access GitHub from Bolt. What type of subscription should I choose? Today, we just announced you can open public repos, like small to medium-sized public repos in Bolt. It's actually the coolest thing ever. Let me pull up a quick demo here. This is just the beginning. We've got a lot more plans for Git and things like committing to Git and stuff like that. Let me pull up... I'll just do it lightly. Hang on one second while I do this. All right. If you are looking at a repo, you should see my screen. If you're looking at a repo, this is cool. It's a doc site powered by Astro. You can create your own doc sites. If you're looking at a repo, even in a subfolder of a repo, you can open it in Bolt by just adding bolt.new in front of the URL and hit enter. It'll go ahead and just suck that in, pull it in, boot it up, and let's give it a second to start. I can actually start prompting this thing and start making my own doc sites. I can say, "Make this a doc site for bolt.new, a new service from StackBlitz for coding with AI." It'll go ahead and start figuring out what to do here. It's going to update the content, etc. It's super cool. You can open a repo, prompt it with questions about the code base, "Hey, does this thing work?" It's awesome because when you're starting a project like this, there's always stuff you have to update, like the title, getting rid of all the default placeholder content, and blah blah blah. It's nice. It punches out some examples of how this thing's laid out. If you're starting a blog or a doc site, or if you want to open a repo of your learning framework, it's super nice to crack it open in Bolt, ask it some questions, and see it do its thing. Let's see. Oh no, there's an error. Let's see if it can figure out what to do with it. Anyways, you get the idea. That's how you open stuff in Bolt. We'll see if this thing fixes. There we go. Boom. Now we've got... Look at that. Bolt.new docs. So pretty. This stuff isn't in the training data. This is just off-the-cuff, hallucinated into existence. Anyways, all right. What other questions do we have? Let's see. One was, "How much coffee do you drink, Eric?" That was a question. Not enough. Not enough. Always more to be enjoyed. Is there going to be a Mac native IDE with Bolt? I don't know. I mean, I won't say no. I think browsers are cool, though. I'd like to just be able to crack this open. The browser is sick. I think it's pretty magic. We'll see. The future is long. I did just see a question about downloading code. We're going to probably add a button here in Bolt. Just so you're aware, you can open it in StackBlitz, any project. There's a little download button here that you can download. It downloads it to your zip file. You can also just push directly to a Git repo, too. Can I put an in from? Not from Bolt, but you can do that in StackBlitz. You can get integrations, keep editing, etc. But we've got lots of Git plans for Bolt. We have a technical question here. When importing an existing GitHub repo, how does Bolt currently handle building the relevant knowledge of the repo contents? Since you said it works for small to medium repos, is the entire repo content passed in as context, or do you have a vector DB/reg implementation in the background to only add relevant files to the context for questioning? We currently pull in pretty much all the files. We strip out binaries and stuff, and there are a couple of hidden files that are not passed into the context window, but essentially it's the entire repository. We've got some stuff. We're going to be able to open the stuff for even bigger repos pretty soon. We actually landed some stuff today that will allow us to increase the limit here. You'll be able to pull in pretty large-size repos and work on them with full context. Cool. Maybe I want to dig into the technical stuff for those who want to walk through the Bolt code base. Kate, are there any other questions in the Q&A that we should hit now, or maybe we can save some for later? Yeah, let's save them for later. You can put your question in there. We'll hit them at the end. Amazing. All right, Dom. Show us the code. Show us the secret sauce that's public and open source already on GitHub. Sounds good. Let's go. Okay, so this is the part I've been personally crazy excited about because I want to understand how the heck this thing was built and how it works. Dom, maybe just give us a zero to 60 of how the sausage is made, how the sausage is made and cooked and prepared, and tell us about that German sauerkraut you threw on this thing too. I actually love sauerkraut. Yeah, anyways. I would imagine, you know, right, right, makes sense. So I think the most fundamental thing about any of these AI products is the system prompt. I guess that's where it all starts because the system prompt is kind of like the instructions you give to the LLM, which are not what you're sending it, right? It's not your request. You're saying, "Build me a blog," and you somehow need to give the model some kind of instructions on how to behave. It's almost like a rule book of some kind. So the system prompt is where all the quality comes from and where you define all the behavior. And so for Bolt, I suppose we could start there if we really just want to talk about the sauce here and how that's made. We have a file called prompts. Let me close this terminal. So I think first off, this is a pretty long system prompt, and we worked on this for a while. We've been adjusting it very frequently, trying to get it to behave exactly how we want. This is the most fundamental piece to build any of these AI products. I'm just going to scroll through. We went through a couple of iterations with Bolt. I think there are multiple different approaches you can take because these LLMs have something called function calls or some call it tool use. You can either build a fully autonomous agent that can call these tools, like reading files, making them capable of reading files, writing files, and all of that stuff. But that involves multiple round trips from model to client, which is kind of slow. Fun fact is that's how Bolt started. We used tool calls in the beginning, but then quickly realized that it's pretty slow. It's a jarring user experience, and we just have to make this a lot faster. That's when we got inspired by existing AI tools such as Claude Artifacts, which comes to mind. We created our own system prompt to get the LLM to create artifacts, except that we define artifacts in a slightly different way. An artifact, you can think of an artifact, and that's the heart of Bolt. When you go to the chat and ask something, and you see this little box in the chat message in the assistant response, that is what we call an artifact. The little thing, you probably all know. Wait, let me just show you. If I say, "Build me a snake game," and I hit enter, right, I should start the app. Okay. All right, let's try it again. Oh, we have it. Make me a space invader. Let me click on that example. You can see the AI is responding in a streaming fashion. Everything is being streamed to the client. You can see this box, right? That's what we call an artifact. An artifact is comprised of different actions, and those actions will be executed in the container, in Web Container. You can see we have, or at least today, we have a few, but the most important actions are file actions and shell actions. You can already see. Wait, audio is not working. Am I reading something? I think it's a lot of questions. Okay, so you can always stop me if you have any questions, but this is an artifact. We get the model to basically create this artifact. We give it instructions, and then we pass in as context. Today on production, we pass in the whole, we basically start off not entirely on a white piece of paper, but we start with the template so that the model doesn't have to recreate everything from scratch. We just give it a couple of files, which it will likely need, and then we start modifying existing files. Anyways, this is an artifact. It's creating a package.json, the action contains full file content, it has a shell action to execute stuff here. We don't show the output here because that's just the core of Bolt production. It's slightly different. Essentially, that's the most fundamental piece. Does that make sense? Are there any questions? Yeah, why don't we pause there? This might be a little bit of a mind-bender, what we're looking at here. It's not code; it's human language. That's the hard thing about these prompts. It's kind of different than looking at code. If this, then that. Prompting is an art form. By the way, I just want to point out something really cool. Dom is telling you exactly how we're doing this in our products. No one else is talking about how they're building AI apps right now and sharing this knowledge. It just warms my heart that this is such gold. I wish we had had this information 60-90 days ago as we were building this stuff. Just want to flag that this is cool stuff, and I'm happy you're all here to be hearing it because there aren't many other places you can go to get this info at this point. Over to you. Yeah, I don't actually know where to continue. Let me think. Well, you've got a couple of questions. Yeah, so what I want to say is, again, I think the prompt engineering is so critical, not only for the performance of the model and the quality but also because it's the rulebook, the playbook in American football that describes exactly what kind of plays you have. If this, then that, but it's not code, it's just natural language. I really recommend everyone to take a look at prompt engineering and try to look at the prompt, which is fully open source. Just have a look at it and try to study it a little bit. If there are any questions, I'm more than happy to answer them. But yeah, I basically just gave you an overview of the core of it. Totally. Some questions from the chat: Can it be adapted to using your own internal tools and run it locally? This prompt. I think the answer is yes, totally. You can piece together the various parts of the prompt relevant to what you're trying to do. There's one: When do you think the checkpoints and chat history feature will be available so we can request changes to certain parts of the code? Yeah, checkpoints and chat history, we are targeting next week. We've been scrambling to get the token reloading stuff landed this week, and we're landing the token optimizations. We're hoping next week is when we'll have those two things. Is the system prompt just a single string? Do the tags mean anything in the system prompt? That's a good question. Yes, it's just text. You would just pass it. The way these APIs work, just for everyone in this workshop, is pretty much stateless. You're always passing it an array or a list of messages, and that list of messages contains everything: your request, the system prompt, everything, except that every message has a certain role. It can be of type user, system, or assistant. Assistant is when the model is actually giving us back a response. These tags are also covered in prompt engineering on the Anthropic docs. It doesn't have to be this way; it doesn't have to be in an XML format. It can be pretty conversational if you want, but a lot of testing and iterations on the system prompt showed us that what we have actually works really well. Dom, you should unshare your screen for just one second because there's a question here about it. With such a huge system prompt, would the token pricing per request be huge? The answer is no because, in the case of Anthropic, which is the model we're using here, they have their pricing. The way these things work is there's input tokens, which is what you are putting into the LLM, and that's like the system prompt, what the user is telling it to do. Then there's output tokens, which is the code coming back that you're going to put into the file system. Output tokens are the most expensive part of the deal at $15 per million. Input tokens, just regular input, are $3 per million. Now, Anthropic recently rolled out prompt for input, and you can actually, with what would normally be a normal input message, say, "Hey, for an extra 75 cents, you can cache it," and any reads in the future from that are priced at 30 cents per million, which is a huge drop. Anytime you send future messages, all the stuff that was sent previously that was cached is 30 cents per million. This is extremely useful for your system prompt, extremely useful. You have a very large system prompt, and that is not going to be billed at the $3 per million; it's billed always at 30 cents per million, except for the initial write, but you spend 75 cents extra to get it cached. You're talking about over a 10x difference here on price. You want to make sure you're passing the system prompt and any other things in the conversation. Hopefully, that answers that question. Let's see what other questions we have. Yeah, and I think on the caching, one thing I want to mention is that it's pretty cool. It is a cache across all users because that cache is tied to an organization. We have the StackBlitz organization, a StackBlitz account for Anthropic, and the cache is bound to the organization, which means if we cache the system prompt once, it's cached for every user. Every user that goes to Bolt.new and sends a message will result in a cache read. Currently, our production system prompt has 8,000 tokens, and that is quite a lot. We're getting some questions on whether caching is limited. I'm not aware of limitations on the cache. I think there was a minimum size of what you can cache, but I'd have to look it up. I'm not aware of other limitations. Cool. Dom, I'll let you reshare your screen here. Are there any other questions? I'm interested in also caching for my code base. I imagine it's like maybe the code going... You can cache the file system, but the file system is going to change as you edit it. This is what we're working on, smarter stabs at doing caching of the file system with updates, etc. Yeah, you have pretty fine-grained control over how many safe points and caching you create. You can cache on certain messages, but if they change, it will result in another cache. You should use it when you actually know that something will not change very frequently. The cache write is more expensive at the end of the day. What is the system prompt? Maybe walk us through this a little bit more. This is the prompt. What are the important parts of this prompt? I think at the beginning, what's important is for Web Container specifically because we operate in a Web Container, which has some limitations because it's a sandbox. For instance, it has limited Python support, so we're giving it a couple of system constraints. Currently, you can't run any C++ compiler, for instance. We also say that we want to prefer V for instance instead of implementing. There's a whole bunch of constraints that we have here. We give it the available shell commands. We have some section on code formatting, which isn't very important here. We tell it which elements are allowed when it generates any responses. We have a disk spec, which is the new unified diff format that people are familiar with if you do Git diff, for instance, for anything that involves this. The secret sauce is the artifact info. Here we describe exactly what an artifact is and what it's comprised of. For example, you can see it's shell commands to include dependencies to install using a package manager. We say it's npm, although you can use any Web Container support: npm, yarn, pnpm. We defaulted to npm for this one here. Files to create and their contents, folders to create if necessary. It won't create any folders, but technically, because it has the ability to run any shell commands, which I want to mention again because Web Containers run entirely in your browser, which is a security sandbox. I just want to mention that again. It's entirely secure. It's not like this thing operates on your local machine, and you're giving it full control over your terminal. It cannot break anything because it cannot escape that sandbox. It's designed in a very secure way, with different domains and whatever have you, to rule out any security concerns. We're fine giving it full control over a terminal. It cannot break anything; it cannot ruin anything other than maybe breaking your application. But then you're one click away from a reload, and everything is fine again. I think that's very important to emphasize here with Web Containers. Another important aspect is the artifact instructions. That's where all the instructions can be found for a single artifact. That includes, for instance, we definitely want it to think holistically, look at all the files that exist, etc. We tell it what the current working directory is. We give it more instructions. I think we don't have to go through every bullet point here, but essentially, we're just describing what an artifact is, what shell actions are, what file actions are, what exactly you can do, and how you behave in certain cases. The order of actions is important, so we have instructions on that. We try to have it execute an npm install as soon as possible, and so on and so forth. I think that's pretty much an artifact. Another very important thing to point out is as part of the system prompt, you can highly regulate the quality of the output by giving it a lot of examples. I think examples are what underpins all of this because you can describe what an artifact is, and you can describe, "Yeah, I got a shell action, I got a file action, I got x, y, and z, I got all of these things," but then what does that actually mean? How does that look if a user comes in and says, "Can you help me create a JavaScript function to calculate a factorial of a number?" That's quite cool. What does that mean in terms of the assistant response? That's part of this example. We tell it very specifically, "If this is the user query, then this is what we expect you to generate," or the LLM in that case. I'm kind of humanizing it, but it has some text, and then this is what an artifact is. It has an ID, it has a title, which we've seen on the page is rendered here. The ID is invisible, but then it's comprised of multiple actions. Once all of that is transferred over to the client, then we're just parsing that. That's another central piece of Bolt because it has a streaming parser that takes all of that as it comes in from the server, and it tries to make sense of it. It tries to parse it as it's coming in and execute these actions in the container, in Web Container. These are all the examples, and we have a couple of them here. I would say the more examples you give it, generally, the better. It's also pretty important because since you cannot really... We're using Sonnet 3.5, and you cannot fine-tune the model at this point. It's not possible, but what's possible is to give the model a whole bunch of examples. That is one way, and you can cache them. You can even put them... Well, it's part of the system prompt, so it is cached. But the more examples you give them, accurate examples, examples that are really correct, because if you have mistakes there, then the model... I mean, you cannot expect to give it wrong examples and then have it spit out correct code. I think that's the last piece of the system prompt. One random question that was posted above: people are asking about when they open a project in StackBlitz from Bolt and then connect to a Git repo. The Bolt project can no longer connect to that StackBlitz project to push the repo. That's currently correct. We're going to be closing the loop on that, but right now, you can't currently have a connected StackBlitz and Bolt project that's also connected to a repo. We have them detached, but that's coming shortly. Cool. All right. Maybe walk us through the basics of how to boot a Web Container and how these commands are getting put in, how the file system is being updated when we're getting stuff back from the AI. I think that's the final missing piece here of how the whole thing is made. I was actually going to go next there because that's the natural next step. Now that we're adding them, we're entering them in the UI, and once they're closed, these actions, we run them. Running them depends on what type of action it is. If I click on run, then we could see... Yeah, I take some action callback, and we get the action, and then there's something that we call the actions run. It calls run on the actions run. Here's kind of why we can ignore all of that, update action, and then execute action. It grabs the action ID. Let's go here real quick. This is where I think the most important thing is. We kind of switch over the type of this action. Is it a shell action? Then we know we have to execute it in a terminal, or we have to spawn a new process. If it's a file action, well, then we run that file action. Let's take a look at the file action because I think that's the easiest. All we have to do in order to run that, because the Web Container is something that stays live, right? Once I call... Let me go back to Web Container index here. Once I call Web Container boot, and you can find that in the docs, right? You just call it once. What you get back is a promise because it's asynchronous, so you have to wait for it to boot. The return value of that is the Web Container instance. If I go here and say Web Container.dump, you can already see that's the public API, which you can also find in our docs. There's an FS. If I say FS, I have a couple of options. I can create directories, read files, read directories, rename, etc. I can spawn new processes, which is just a child process, essentially, right? Like Node.js child process, or I can tear it down. Coming back to our action, in the case of a file action, all we do, and I hope all of this kind of makes sense now that it falls into place here, but for a file action, all we have to do is make sure that all the right directories exist in that path, and then we simply call writeFile. That's how files get updated in Web Container. Every time there's a file action, all we do is make sure that all the right directories exist in that path, and we simply call writeFile. For those that might be familiar with... Is Web Container just kind of like this very unusual JavaScript library thing? Typically, when you look at it, it installs for npm to use the browser. It's got some sort of DOM binding. There's kind of a standard shape to these things. What's weird about Web Container is you kind of think about it as an operating system. It's an API to an operating system that you're spawning within the browser. The very direct analogy is if you've ever built an Electron app, Electron is Chromium plus Node.js. You can use Node.js APIs for writing to the file system, spawning shell commands, etc. Obviously, Chromium is what you get in the normal browser. By combining these two things, you get this very powerful surface to create very sophisticated types of applications. You can really think of the Web Container API as almost a polyfill for the delta of what Electron is versus the regular web. Now you get an operation that's sandboxed in the browser with full FS access, etc. Think of it as the Node.js API in your browser. That's, in a nutshell, a good frame of reference for how to think about it. Very true. Going back to the shell action, since we only have these two types, the shell action is really, in this particular case, what we do is we call spawn. Here's actually the cool thing. Spawn can be... You can run anything. JSH is actually our internal shell. We call it JSH, similar to ZSH or Bash. JSH is mimicking ZSH, kind of. That's our internal shell. Essentially, what we do is we have a flag to just execute a single command. We basically spawn a shell, and in that shell, we run the command that was part of that bold action. If you remember, the bold action would be something like this: bold action, bold action type shell, and then, for instance, node index.js next. That would be the content here, and we simply pass that into the shell. It's being executed in the shell. It is a shell because you can interact with it. It takes standard input and all of that stuff, so it behaves like a normal shell as if I just opened up a terminal here. I have a full terminal in which we run that. Yeah, like that. That's kind of it. Then we just wait for it. In Bolt, these actions are all executed sequentially because they can depend on each other, so we can't just run everything randomly in parallel. I think that's just going to cause more issues. I think that's kind of the heart of it, if that makes sense, and how stuff is being updated in Web Container and how we run these commands. One question is, how full-featured is JSH compared to ZSH? We have most of the commands you look for. We don't have full, like for loops and all of that stuff, so most basic commands should be there in JSH. If not, go ahead and file it on our Web Container repo because we're constantly adding to it. For Web Container, we had to really build our own micro-operating system to make it fast. When you pull in, there's a lot of things out there. Someone's asking, is Web Container open source? The answer is no, but the stuff it's built on is, and there's tons of open-source stuff out there. You can take an entire Docker image and compile it to WASM and run it in the browser. The problem is that pulling in an entire Linux distro plus all this other stuff really bloats it and slows down the speed. We had to design our own kernel, our own shell, etc., to be extremely lean and small, really for the purposes of what people are using StackBlitz for. This is not a general-purpose operating system. This is a developer-oriented environment. That's just to give you an idea. There's tons of stuff out there that you can use that, in some cases, is more powerful than what a Web Container could do. The trade-off is the speed, the latency, the CPU, and memory usage of what you're trying to do. That's just a high-level overview of what the other things out there are that can do what you're looking at here. Any other questions? Really cool idea, and this is actually something we thought about. Is there anything planned like validation circles for code responses that you take the response for something that's TypeScript, put it through TSC or TSC in the background, and then only accept what the LLM is getting back once it passes that 100%? We're definitely interested in this. It's an active line of research for us. The trick with this stuff is it's very easy to end up in infinite loops where the end users... We're already having problems with this where we're doing token reloads for folks because they hit something that's just burning through their token because the LLM, for whatever reason, is not able to solve it. Once you introduce that sort of thing, it's got to be darn good, and it's got to be interruptible. Otherwise, tokens will be burned, money will be lost, and people will be sad, understandably. The way that we've approached it is we really want the human to be in the loop every step and, at the minimum, just clicking the fix it button until it's freaking fixed. It at least prevents a wild loop of money drain happening. 100%. There's a story about the shirt, by the way, everyone. If we have time, I'll tell you about it because I'll make a special offer to anyone that's on this webinar too for suffering me launching. Before we get to that, I hope you'll pop this. One thing to mention about Web Containers is because we're talking about how it's all in the browser, there actually is a meaningful server-side aspect to this. When you run npm install, that is not going to the npm registry directly. We actually designed Web Containers so that the file system of Web Containers is designed to be able to pull in very large amounts of data extremely quickly. That's important because when you're installing stuff from npm, you can be installing hundreds of megabytes of data. Doing that in a browser, there have been previous science projects in the past, and it takes like 10 times longer than your local machine. We had to design a file system that works in the browser that could pull in massive amounts, ideally 5-10 times faster than it can do on local. That actually requires us to have server proxies that we're running. When you install packages, it's not going to npm; it's going to our servers, which are pulling down those packages, converting them into a format that can be sent down and immediately sucked in insanely quickly, and also removing a lot of stuff in these packages to reduce the file size to make it smaller payloads, faster downloads. We're doing, I think, on order 10 to 100 terabytes a month of data transfer on this stuff for our npm infrastructure. We do this for Git repos as well. We do this for CORS proxy. There's actually a networking aspect of this. You have to have servers to do that. A lot of these things are CORS protected, so you want to connect them; they would not work. There's a server-side aspect, and that's why for open-source projects, we let it be free. We want to be able to build stuff that's cool, make it open source. If you want to use this for a product, we've got a paid plan that gives you basically unlimited access to that infrastructure. We charge on a per invocation of Web Container effectively. It's pretty reasonable. I think for 200 bucks a month, you get 100,000 API sessions per month. That's 100,000 Web Containers. I'll tell you, go to the AWS price calculator, put in the cost of even the smallest EC2 box you can find, multiply by 100,000 for an average duration of five minutes or something. That number is not... Heck yeah. Yes, Bolt merch store coming. Definitely coming. Any other questions on the Bolt side of things, etc.? We have a couple of questions. I think we have about 15 minutes left in our scheduled program here. Maybe we ask a couple of questions, and then Eric can close us out with T-shirt story time. Awesome. Will you add any other deploy options to different providers? Definitely. That's something we're definitely looking into. We're already in talks with a couple of different usual suspects you could imagine. That's definitely coming. This one's kind of public. There are some tweets that went back and forth, but I think there's probably a pretty cool integration with Supabase we're going to do coming into the product where, just in Bolt, you'll be able to get off with Supabase, spin up DBs, run the migrations for you. It's a Bolt on you. Go and add this row, go do that. It's going to do it for you. There's a lot more coming to the deploy-to-production part that's not even just hosting. That's also database and auth and dot to dot. Excellent. There's been a number of questions about chat prompt saving and being able to save previous chats. Do you want to address that as a whole? 100%. I think I linked the tweet earlier. I'll link it again. That is one of our P0s here landing next week as our target: chat persistence and checkpoints of the file systems so you can roll back to a previous point in the chat. 100%. We cringed when we launched Bolt because there are a couple of major things we're like, "I wish we were able to get this in for the release." This is probably one of the biggest ones, actually, probably the number one one. This is coming. I personally want it, so we're all on the same page here. This has got to land as fast as possible. Shout out to the team. We've been pushing crazy hard, crazy, crazy hard. I know I personally was at my desk for 21 hours a day for three or four days straight to the launch. After, people are online almost 24 hours a day. It is wild. We have not expected the amount of growth we're seeing, so we appreciate the patience because every day we're waking up and seeing a heck of a lot more people than the day before. That's kind of been the story for the past six days, which we're flattered and kind of floored. Awesome. I don't know if we have time to get to everyone's questions, but I'm going to throw everyone's Twitter handles in the chat here. Feel free to ping us any questions you have. Eric, do you want to close with any remarks here? Yeah, so the T-shirt thing, I think that's the last thing. I wasn't actually planning to talk about this, so I'm getting kind of a demo pulled up here. Actually, let me set this. Yes, so Bolt that are out of credits, we are landing token reloading today. Today, mark my words. I'm going to eat my shoe if I go back to our Slack channel and I'm like, "We hit a bug. I can't land today," but I'm committing this thing's landing by the end of the day. I will personally be grinding to get the token reloading. You're going to be able to, when you hit the bottom tokens, you can do a one-time payment. We are going to also be priced the same as a subscription: ten bucks for ten million. You can buy in any increment of time. We are also going to be rolling out higher subscription plans where right now we have nine dollars a month or ten bucks or whatever for ten million. We're going to also have higher options. I believe we finalized the pricing at 29, 49, 99, which will, at each jump, you actually get more tokens. There's a discount on them, so if you're using a lot of tokens and you're loving this, you can go and go to one of those. If you don't, that's fine. You'll still be able to have one time. If you're like, "Oh, I only need ten million tokens for this month or something," whatever. The subscription stuff is going to be landing. We're pushing it out by the end of the week. It might be early next week just because we've got a mental health day for the company on Friday, much needed. Anyway, so it might slip into Monday. What I will say, and this is off the cuff, I had no plan to show you all this, but I think it's cool, and I think it'll kind of tie in. So the shirt, this is something like a couple of years ago I had the idea for this thing, and then earlier this year we announced this. As a company and developer company, we'll go to conferences or when people sign up for our team's plan or whatever have you, we want to send them a T-shirt, right? That's kind of cool. Let's not just like a look. So this T-shirt is not like any ordinary T-shirt, and that is because everything that you see here is actually valid JavaScript code. This is real valid JavaScript, and you kind of see it's hard for me. I've got a desk here, but every single line here is actually real valid JavaScript code. So I'm going to share my screen to kind of show you what I mean here in one sec and pull this up. Okay, so you should see this is what is on my T-shirt. So you can zoom in. You can see, hopefully, the individual lines of code here. Every single line is valid because, again, this is the JavaScript. Every return statement, you can't have a return statement in the middle of the i and the f in an if statement. So all every line is valid. What's cool, so what does this code do? Okay, very cool, it's valid. What's it do? Well, this is actually self-rendering. This is the first ever self-rendering T-shirt. You can copy and paste this code into any JavaScript console. So all the code is here. I was going to hit enter, and it actually, the code of the shirt itself, of this image, is the code used to render the image. This is what's called a quine in programming. So as you're walking around with the shirt on, you're actually running a program on your chest, which is kind of cool. So anyways, so here's the thing. I believe we have a shop where you can technically buy these. Someone actually bought one the other day. We were like, it wasn't kind of intentional. When we rolled out our subscription plans later this week or early next, if you buy one of the higher tier ones, send me an email at [email protected], and we'll give you a link to get one of these shirts sent to you if you think this stuff's cool. So hey, so that's the story of the shirt mystery solved. Okay, funny enough, like I said, I came with the idea for the shirt a couple of years ago. No LLM actually, this was all me. I had the idea on a flight to a vacation. It was like a five-hour flight, and the nice thing is your StackBlitz, because it runs in your browser, works without internet. Nothing else better to do. I had an itch to scratch with this, and I manually got every single line. I also did try putting this through the latest LLMs. They couldn't do it. They couldn't do it. So circling back to the question of, is AI going to replace us as programmers? The answer is definitely no, because if you're making quines that go on a T-shirt, we're still going to be in business for that. But yes, I literally wrote this by hand. My wife got a picture of me just after five hours of grinding on this thing, and I just look like I'm destroyed. It was like when you change one thing in it, it would break all the other lines. It was just kind of this Jenga game of getting every line to... But there's not said fun stuff. So yeah, if you start one of the higher tier subscription plans, shoot me an email. I think Kate just put it down there. I will send you one of these T-shirts for free as a part of that. So there's just want to throw that out there. Looks like we're almost at time. Are there any last questions you have for Dom or I here? We appreciate you coming, by the way. This has been a lot of fun. Hopefully, it was helpful. Hopefully, it was good. I think we'll probably do more of these as we're rolling out stuff for Bolt and talk about how we built it and what's coming next. But Kate, how are we looking on Q&A? Q&A, let's see. Actually, we do have a couple more. I think we have some time for a few more. Can I integrate Bolt into my app as a micro frontend? Probably. You'll need to, like, not out of the box, like the open-source code base, but you could certainly strip out the parts you need and compile it. I think this one was when you were doing your demo, Dom. How does it know when to execute a terminal command? Because it's a bold action of type shell. Essentially, the model will decide when to do that, given all the examples in the system prompt. It kind of has a good sense of when to run certain shell commands because we have instructions for that. I'm wondering if there will be a feature to include my own component library or internal packages to be used. Definitely. If your stuff isn't on npm right now, like public npm, current Bolt cannot do that. However, StackBlitz itself, your core ad products, has the ability to connect to private registries, etc., on team's plans, and Bolt will be getting that capability as well. This is going to be coming in a future update here, hopefully sooner rather than later. Again, we're just keeping the lights on right now, just staying above water and not drowning, and that's kind of the current priority. I imagine over the coming couple of weeks here, we're going to get to a good spot, a lot of bugs fixed, a lot of reliability improved. If you look at the StackBlitz IDE feature set, connecting to private npm registries, connecting to private repos, committing to private repos, forking repos, sharing stuff with your teammates, all that stuff, we've got it. We built it. It's all right around control. It's coming to Bolt, and you saw the first of that, and that's actually why we're going to be able to ship a lot of stuff really quickly here, just at breakneck speed, because we've had this stuff in prod, a lot of the stuff, for years. So bringing it into Bolt, there are new challenges, but it's not like net new work, right, that we have to do. We can leverage a lot of our existing technology, our existing scaling profiles, these things, and security models of them, and then apply them over and forth. So things are going to be improving quickly and rapidly from here. Is there an example in the repo or docs of how to add your own actions? An example of in the system prompt, I think there's a section on types of actions. So you could potentially just add another block which describes a new type of action. You can just add it there, and then it would need to be handled somewhere in the parser or kind of like the actions runner, and then you can execute whatever you want when it would generate those actions. Again, important is just that you provide enough examples so that it actually knows what these actions are for. Amazing. Okay, I think that brings us to time. I just want to remind everyone that we will be sending out the recording of this as well, so everyone will get the link for the recording. Awesome. The last thing, someone posted in the chat they created a Dom vs. Eric game using Bolt. This warms my heart. Let me do a little final screen share. I don't know what this game does. Hopefully, this is appropriate for work. If not, I'm so sorry. What about this user-generated content? We take no responsibility for this content on our platform nor this live stream, but let's go. Okay, new battle of which... Oh, there's, I think, the image, but we have the game. Look at this. Take a co... Oh, good noise. How have you heard that? I just, like, you know, I love it. That's amazing. That's so cool. I like... Wow. Go. Thank you. I'm going to be playing this all day. Let's go. Love it. Thank you. Okay, thank you all for attending. We really appreciate it. We just hit time. As always, if you want to contact us, I am at EricSimons40 on Twitter. I'll go ahead and post my handle here. Feel free to tweet me, DM me, etc. I'll go ahead and post Dom's as well before he's at LD. But feel free to grab us. And again, this was recorded, so if you want to come back to it and relive the awesomeness that was this hour and a half, it'll be here forever. Good stuff. All right. Thank you, everyone. Really appreciate it. Have a great rest of your day. Can't wait to see what you build. Make sure to share it on Twitter. |
|
|
|
Video: Building with Bolt: Advanced Tips from Community Mentors |
|
All right, hi everyone. It seems like we're live. How's everyone doing? We are live with our second episode. Some of you might have seen us in the first, which was a Zoom call, but now we're live on Bolt's live streams. We're on YouTube, Twitch, X, LinkedIn—we're everywhere. This is really exciting. If you haven't seen this before, my name's Petro, and this is Emil. Let me mute my YouTube because it's coordinating there. We'll be looking at your comments from all these different social platforms. If you haven't already heard about it, Bolt is doing the largest hackathon ever. We have over 118,000 people signed up and over a million dollars in prizes. There's so much at stake, and there's never been a better time to get into this because we have so many resources available to you: mentors, advice, and people like Emil who are just helping nonstop on the live streams. If you haven't already, check out the Discord live stream for Bolt because you're going to get so much information there. To introduce myself a bit more, I'm Petro. I'm a vibe coder. I spent thousands of dollars and months working with developers. Once vibe coding came out, I gave it a shot and realized you can do so much. With a $20 membership, you can build something in a day. I've been doing hackathons since then, which has been so much fun. I recently did an AWS MCP hackathon where I got first for a link-up, second for NADN, and fifth for a mini-max. I've completely transformed my life by diving into this, and I am a mentor for this Bolt hackathon. My friend Emil has been a huge help to the Bolt community, going live and helping people left and right, answering questions live. That's one of the reasons we're going to showcase him today. He's such a great person, a senior automation engineer, who's here to help us out. Based on our first stream, we're going to go deeper into the PRD. Now, Emil, take us away and walk us through what a PRD is. Good day, thank you for having me. It's a great pleasure. Today we're going to jump into PRD, product requirements documentation, in an advanced form. We're going to understand how to implement bigger projects and how to keep track of those projects. We have a special product we're rebuilding today, and I think it's time we share a screen here. Perfect, perfect. We're going to do this for fun. As we all know, a to-do app is one of our first apps we're supposed to build in any course, like a 100-day Python course or a React course. They'll make you build a to-do app. But today, we're going to attempt to start a super luxury to-do app with a few features. I've created this PRD that has a lot of detail. This is not a simple to-do app; this is a deep dive to-do app with extra features, communications, and bug-tracking functions. It's a very detailed PRD. You'll see that we are diving into the extended detail of what the PRD can look like and having a design system. In our previous session, we covered what the PRD is and how we create it. Today, we're going to take a created PRD and go to bolt.new, and then we're going to put that PRD in. What makes today special is that we are going through a few additional steps of managing this PRD. We're going to start with our first prompt and go through this step by step, and we will share this as well in the chat. The first step is to write a PRD to a folder called docs, PRD.md. We'll take this PRD, write it, and dump it into a folder for us. That's important so we can bring it out of the chat context and always refer to it later. Very, very important. Secondly, we are going to write an itemized project plan and phases to docs/project_plan.md, which stands for markdown file. We'll focus only on the landing page for phase one. For this exercise, we are only going to build the landing page now. If things go well, we'll see a landing page. But that's not actually what I want to show you guys tonight. Tonight, I want to show you how to structure your project in such a way that it's more robust and will hit the target on the first attempt. This is not a one-shot attempt. This is about turning your idea into a PRD and seeing it come to fruition with this trace. The third step is to create the docs/memory.md file and use it as a previous, current, and next task manager as a memory bank. Essentially, this is your RAM. The focus here is to allow the stepping through the itemized tasks to happen in a short-term memory fashion. Essentially, what we are doing is telling Bolt to go and split up our PRD, which isn't necessarily a project plan. Our PRD is a product requirements documentation, not necessarily the detailed plan of action items. We can even write the detailed itemized project plan in phases with action items. With the memory, we're going to be looping through all of those action items and only working on the previous, current, and next task in the memory bank. This allows Bolt to focus on what is busy right now and what the next steps are. Often with bigger projects, you'll find that element coders lose track or context. Next, with this current task management, we're going to be dumping and logging all the changes of each task to a changelog in the semantic format. That's a standardized format for changelog management. This will allow us to see what has been done, top-down in the project. This format also fits to plug into any of your other changelog flows you might have, or it will be a way for you to actually turn that around and create a changelog on your website. When you do that, you can go and read this afterwards and then ask Bolt to create a changelog page on your website. All of your changes are already there. If you're in the Bolt and Public space, this is a great way to take those changes and display them. You can continuously update your changelog page with the changes that your project is generating. That's a nice little hack for the Bolt and Public crew. Then, something that is often skipped when people come to a Bolt interface and a chat interface is that they tap out and want to create a to-do app. That's not any detail at all. We need to explicitly give detail. If there's one hot take about this lesson tonight, it's do not hold back on detail. You'll often find that the frustrations in executing a PRD are exactly the areas you did not detail enough. This is where we are going to go in detail. Ask it to go and create a backend file with all the backend operations. In the areas that your PRD might not have specified those backend operations, it will actually think about these backend operations. Petrus, maybe mute your keyboard there. Thank you. We are going to force Bolt to think about what all those backend operations are. Despite us having a backend section here and a technical stack section, this technical stack section that we've detailed and added a schema might not be sufficient. We have an actual backend architecture structure, but there might be nuances here that are not detailed enough. By forcing it to actually think about backend operations and to dump those thoughts into a backend file, you help it iterate over the backend operations. That helps a lot, especially into the future. When you get to building the backend out, you actually have a complete backend documentation for how to hook that all up. Next up is schemas, which, depending on the backend operations and the file, usually are not necessarily part of the backend operations. But we're going to write the schemas now in a separate file. Again, it comes down to focus and thoughts. We're going to focus on the schemas and dump all the schemas into a file. Schemas are your database tables and columns, all of the different types of tables, what structure, what relationships they have, and what data types the columns have. All of that together will give you a view of your data architecture structure. That's very, very important. How many tables do you need, and what kind of tables do you need? The schemas file will dig into all of your tables and columns and explain what your backend structure is. Of course, you can review all of these files and make changes as you wish. That's not a problem at all. The next step is that we are writing all API documentation to an API documentation file. This will create endpoints, and we can even specify it back to specifics like the wall, go around the moment with these kinds of things. We're going to say write API documentation with endpoint details and functions. What is behind those functions on the endpoints to API documentation? This is also quite important because at the end of your project, or when you get to the point of wanting to rig up your project, this API documentation might not have been covered in your PRD. Again, we're forcing the thought processes to go through API documentation and to dump all of that into a file. Then, one very, very nifty hack, and don't tell anybody I told you so, but actually, you shouldn't. This little line here is absolute magic. We are going to write any enhancements, improvements, and items out of scope of the original PRD to docs/enhancements.md. What this does is it dumps all of the over-engineering thoughts into a file. Essentially, a lot of times, a PRD might have elements that are missing or lacking, or it sees that there's some AI integration, which this app has. In the process of reading the PRD, it will automatically add more features and over-engineer. Some call it over-engineering, some call it hallucinating, but the reality is that if you don't specify it, there will be assumptions made. When a highly intelligent model with a lot of billions of parameters makes an assumption, you can bet that assumption will definitely be an over-engineering element. This writes any enhancements, improvements, items, or scope. We essentially tell it to go and put all the engineering thoughts in one file and continue with the rest. If you draw a line for all the items that you don't ask for, the nice trick here is if you are looking for additional features or upsells, if it's a client project and you need to go upsell to the client, you can go and get some ideas here. This file is not part of the presentation we will get to, but I found some brilliant ideas dumped there, which weren't part of my PRD. That's a little goldmine here. Absolute goldmine. The next step is to write a detailed marketing plan. I mean, why not? We are already crafting a lot here, and while it's actually understanding the essence of the project and understanding all of the elements required to build this project, we might as well lean into a marketing plan. We're just going to dump that into a marketing plan MD, and we'll get back to that later. Essentially, if you're looking for ideas, this is again a great way to quickly generate a launch plan because it's basically asking to launch our site, and that's just going to be customized for your project itself. This is a bulkier prompt exercise, and I'm going to stop here before we make it more complicated. This is a really good start for a project management system in Bolt. I've started this hackathon not using this. I use this in my day job for a client. I've been using this for months very, very successfully. Halfway through the hackathon, I was like, "Well, what? I'm just trying to do it on Bolt," and it worked. I'm very happy to share these little hacks. The complete list above and then continue with phase one. We are only going to be tackling phase one prompt. The user, when done with phase one, will review. You actually want it to stop and not continue to phase two. We want it to prompt us and say, "Okay, we're done with phase one. What are we going to do to continue to phase two?" Well, we can firstly review it, and when we're done with reviewing, all we have to do is ask it to say, "Continue with phase two." That's it. We are going to do a quick top-down review. We're building a super luxe to-do app. It's got a nice vision statement: "To become the premier task management platform for celebrity assistants and high-profile personal systems, providing unparalleled luxury, security, and collaboration capabilities that match the sophisticated needs of elite clientele." I'd say that's not a boring to-do app. We are now going to blast off this prompt, and we've got all our steps here. One, two, three, four, five, six. Just in case, before you submit the prompt, you want to copy and paste the important parts. I think a lot of people in chat are like, "They're actually talking about this too much. They want to ask. I don't know if you're willing to. I know it's recorded so people can see." I'm very happy to share this. All that's going to be on the screen. People were asking, "How did you get your initial prompt?" We covered this in our first lesson, but in case you're joining us for the first time, Emil's strategy was going on Grock first, giving you an initial prompt, and then from that, enhancing that prompt with Cloud. After you do those two steps, you'll have a very strong layout for what to build. Now, this magic sauce that Emil brought up is what you add at the end of the prompt, just to give some more context for people who are joining us for the first time. Helwing says this is gold, and yes, I 100% agree. This is months and months of Emil's vibe-coding, building, AI tools, knowledge, just summed into a few prompts. This is amazing, Emil. Please continue. This is one-prompt magic at the moment. Basically, we've shared it there. We'll share the multiple shared in the chat. I've waited so we can actually showcase it first before we share it. This is our showcase. We're going to pause it off just now. This is a very generic approach. It's not too customized to the project. You can play around with this a lot more. But the principle here is to understand that there are thought processes that lead to resolution results and outcomes. When you've gone through a thought process, it actually enhances the overall integrity of the idea of the project, the project planning. It is going to quickly, we're going to blossom it off, and then we're going to quickly have a look at that PRD, just how we get here. I'm sure we've got people here that weren't in our previous session. This is the part where we go. Now we're going to go to the file structure and see there's no docs created here at the moment. As soon as it finishes thinking and it's analyzed our very big PRD, it will start taking action, create a docs folder, and put those files in a docs folder. It's first doing a summary analysis overview for us. You can see it automatically created the docs PRD. It's writing the PRD for us and it's going to continue through all of those steps that we asked now. All one, two, three, for all of them. Because we asked to continue with phase one, and we specified that phase one needs to be only for the landing page because we don't want to get stuck now with rigging up a backend for this kind of project. It's definitely a bigger Bolt. If we look at the summary here, and this is something I don't have control over, it's what the summary is. But the core features are a luxury-focused landing page with premium aesthetics, security-first messaging and positioning, team collaboration, highlight sections, premium pricing, positioning, mobile-responsive luxury design, design elements, sophisticated color palette. I don't know where we get sophisticated color palettes. We've got platinum or gold accents, playful display for headlines, inter for body text, subtle animations and micro-interactions, luxury core designs, official gradient backgrounds. That sounds very snazzy. I like it. You can see it's going to be kicking off. We're going to come back to this just now. Let's quickly entertain how we got to this PRD, like a very quick detail here. It was really not such a big undertaking to get a very sophisticated PRD. I'm going to come back and emphasize that the over-engineering could be used to benefit, but you've got to want to steer it in the direction. It's like having a lot of horsepower. You want to steer it in the right direction. We start off with, we want to build a super luxury to-do app that has a team function for celebrity assistants to manage to-dos for them. We will be building using Bolt, new white, and Superbase. We need a landing page, login views, and dashboard. Create a detailed PRD. This is my phase one for creating the backbone for PRD. Now, our product requirements document is a scope which usually goes into the hands of a product owner. The product owner would be the person that interfaces with the client, the project managers, and the dev team. The product owner needs to steer the development of the product on all fronts: design, interactions, support, development, the whole lot. The product owner needs to own the whole product development process. We now have a reasonably okay PRD. I've used ChatGPT for PRDs, and I've used Grock and Cloud. The secret sauce here is to come and create your backbone PRD where it's got the initial key features laid out and enough of it. You know we're going to be using Superbase, and we know we're going to be dealing with a few elements that we have all the most capable of. Then I took this and came to Cloud and simply asked it to enhance this PRD in great detail, including the backend portion and design system. It took this six-step, well, minus the development timeline. It's got the five-step PRD and created a five-page PRD. That is the little secret sauce for going to a PRD that has a lot more detail and a lot more specifics about the product you're building. That's a quick rundown of how we get here. Of course, ideally, you want to spend some time on your PRD, you want to spend some time planning. You want to ideally spend more time on a cup of coffee or PRD because there are a lot of technicalities here that we have over-engineered now because we kind of gave it the creative license when we said enhance it. We didn't specify to what extent, we didn't specify technical limitations. You could play around here and say that, well, we've got these technical constraints. We want to bring it down to MVP state even. You can ask it to say give me the MVP version of this project and only focus on the MVP version. But for this exercise, we wanted to create a PRD that is more detailed and has a decent backend structure that is more than just a simple slide. If we go back to see where we are in the project at the moment, we are going to look at our project plan now. It makes us a little bigger. Now you'll see that we have a day one to two, day three to four. This is the funny thing about LLMs at the moment. They don't know their own capabilities of enhancing project timelines. They still train on humans doing the coding project timelines. This timeline we should be able to actually pull this in prototype mode in a day. But the reality is the technical undertakings can take a little bit longer, and the finishing of the backend can take a bit longer. But what we now have is actual deliverables for the phases. In here we've got a sponsor design already done. There are performance standards, metrics we can use. There's accessibility, which is quite important. If you want to go build a decent app, you have to conform to accessibility standards for people who have problems accessing the internet through normal ways. There are design deliverables, we've got content deliverables, this actual website copy that needs to be created as part of our phase one. It's broken up our PRD into actionable items, which a PRD is great, but a PRD is not a project plan. If you had to add a PRD in the real world to a developer, they would need to break that up into actionable tasks. A PRD is building guidance to creating a product. It's not necessarily an actual project plan and actionable tasks. What we're doing here is creating actionable tasks from the PRD. Great detail, love it. In the memory, we have a memory bank, so current status, previous task completed. You'll see that's already completed these tasks. It's busy with current tasks, so it's currently running on this task. It will see it as today's objective, but I think this will be like the next in the next 30 minutes objective. Then in progress and next task. What's great about this again, the memory bank helps focus on the current task. That's what you want. You don't want it to go astray, you don't want it to go off the beaten track, you want it to go and implement this plan as is. Because you've planned it now, we itemized it, hitting these implementations is a lot more sound, it's a lot more pertinent to being built right. Where we just feed it to PRD, there are some elements there and some specifics that are not uncovered. We're going to go now into the changelog. This is the start of our changelog that has been populated in semantic format, and there's actually a reference to semantic format. It timestamps and does version control as well. As this project continues, it will be logging all the changes for us in a very, very professional manner. Then our backend, all of our backend architecture is documented now. Great stuff, lovely. This was all in the nominee minutes. We've got top-tier information. It was beautiful. The thing is, it might be taking longer to do the initial prompt, but what people need to understand is by setting up these foundations, solidity, having a strong foundation, will not only save you time but also prompts. You're saving on tokens by applying this ahead and having this structure already set up, it gives something for Bolt to work with. Now a lot of people are giving a lot of, there's a lot of shout-outs for you, Emil. I don't know if you saw the chat. We're watching your YouTube and X chat. Eve says go Emil. Possum XTV says shout out Emil. Mad sense like yeah, he's okay, I guess. Then other people are like reps here. We're just seeing a lot of people shouting out. Just want to give a quick shout-out there. Make sure that your voices are heard. Anthony de Clerk says next level. It's absolutely next level. This is a secret source that took months of trial and error and millions and millions and millions of tokens burning to understand what's capable. Just want to recap, we quickly want to jog through these last two. How are you on time for a section here? Yeah, sorry. Oh, was it a question? Are we looking on time on our section on the POD? Let's cover it real quick. I think people are really curious about this portion. We can always circle back to this as well in tomorrow's stream. If you happen to read, we're going to stream also tomorrow. But yeah, let's hop into this. Let's take a look. Okay, and let's just quickly wrap up the actual document site, which is the most important here. We're not showing we're going to build the whole to-do app today live. The goal of this exercise was to step through what these files mean, why they're important, and how you can be using them in your project to help people with more confidence within these tokens. On the schema side, this is very important when we are creating our database tables. What the table name is, every single column, the column data type. Is it available? Is it a number? Is it a timestamp? What kind of data is it? Then we've got here references and relational data points. What's the foreign keys in between these data tables to help them build relations between the tables? This will be read. This is not for human consumption actually. This is for scripting migration files. We'll come back to this when we are building the backend. Then we can reference the schemas and it will build migration files to trigger the schemas. Then API documentation. This is supposed to be more for human reading. If you have to extend this app to developers, you can give them an API documentation pack, which covers all the endpoints, the functions, the data types. This should be standard enough that you can hand it to a developer and they can continue building on top of what you've built here. This is for referencing material, especially if you have a team or you need to hand over some functions to the site. All of the functions of the API endpoints are documented in the API documentation page. Then there's this little enhancements, which is my favorite in all of this. I've got no idea what comes out of the enhancements for every single time. Now, if you're an ideas person, I know I have to warn you that this is dangerous stuff because some of these things you haven't even thought about. We've got so much here. I can't even run through all of this right now. The nice thing is, Emil, we have an episode tomorrow, but hopefully, they bring us back for tomorrow. Hopefully, we can go, actually cover this full scale. If that's something you want, definitely give a shout-out. I can tell all the amazing people in the Bolt staff. But yeah, just so that we cover all the next grounds, we'll definitely cover this. A lot of you guys are asking, we will share the prompts in the video description. The recording of this video will be shared. Don't worry, we'll definitely dive in. If you haven't already, Emil is always going to be live. Oh, not always. We'll be available on the Discord as well. Just for the sake of time, let's transition back to my screen. I'll be covering a quick overview of the database and that. Don't worry, guys. We're definitely going to dive back into some of those amazing things that Emil has covered. Some of the basic things that we just want to go over because our last stream was very basic, oriented around like, oh, how do you create a prompt? How do you enhance a prompt? How do you go over that? I know that there are some beginners here that haven't actually used our platforms or used Bolt and all the above. Definitely check out that when we release it. For now, let's go over some of the database integration. Many of you know this, so we're just going to cover it really quick. On the top right of your website for your Bolt project, you'll be able to connect to Superbase and GitHub. Make sure those are connected. That way, you're able to access your backend actually just for that. Now, there are a lot of sponsors. As you can see in my little image over here, we'll be partnering with. We covered some of the sponsorship packages, but there's so much pricing available for this. Once you connect to Superbase, just to give you an overview of what to understand because a lot of people surprisingly don't understand how Superbase functions. I'm going to just cover this really quick. Superbase is going to be your backend functions for authentication, database, and more. Once we connect it, this connects to cover your table editors, which goes over your information such as for this like a calorie site, being able to process your types of foods and more. SQL Editor will give you a lot more functionality for your database as well as functions within how they work alongside each other. Your database on your Superbase is going to go over the schema visualizers, some of your other tables, and more. Authentication is going to be great because that's how you access your users and you can adjust your policies for that. But don't worry, if this is all like crazy to you, you'll have BoltChat. Of course, 90% of you who are watching do understand, but because this is recorded, we just want to cover that. BoltChat, once it's connected to Superbase, will work with Superbase and actually give you access to that. There's something called storage where you're actually able to upload your own audio files, images, and videos. You just create a new bucket and from that bucket, let's say if I want to make this like audio, make that a public bucket, you're actually able to then drag and drop files into this. Then you'll get an ID that you copy and paste back to your BoltChat, which is super easy to integrate. People are like, "Oh, how do I connect that?" Well, it's super easy. Bolt has made it very easy to work with Superbase to apply those functions. I mentioned functions. Here's edge functions. A lot of people surprisingly don't know this. Of course, we have a mix of advanced people who are like, "This is the palm of my left hand. I already know this." And those who are joining us for the first time, Superbase again, for the backend functions will have something called secrets. This is just part of my API key, so don't worry about that. You're going to be able to work with these sponsors by connecting your API key. Let's say if I go to XAI, I get my API key from there. Then I'm going to put the label for this. This is pretty important, at least for me, is when I label my API key, I normally label the name underscore API underscore key, all caps. That way, when I add the values here, which is all hidden and more, I'm able to then access these API keys without having to put it directly in my BoltChat. This is the safest way, at least in my opinion, for making sure your connections with API keys are covered. Then from here, you just copy and paste the key name and then put it back to your BoltChat. Like, "Oh, we're connected with XAI, please, for this proportion, use this API key." That way, you don't have to share your environment more. Real-time, you don't have to worry as much. There's more for some of the games and some of the other things. Of course, there's other information here. I will mention briefly, say, for example, for your edge functions. Let's say your functions for utilizing API key, a way to debug, let's say your API key is not working. I covered this in the video that we might share, but essentially, you're able to access logs, which would give you the error reasons, "Oh, this API key is not working, and here's why it's not working." Now that we cover a little bit about two things, your project settings will cover some of your URLs and more. For Bolt, it's already integrated, so you don't need to access those URLs or those links, but that's just something for you to be made aware of. Covering GitHub, something that a lot of people don't do, and I definitely recommend it. Of course, this is a lot of you might already know. This is once you connect it to your GitHub on your GitHub itself, you want to be able to save and download the files. The code itself, just make sure, a lot of the way, it's fine as just save this as it is. You can always pull this back, and GitHub is where your code is going to live quick and easily. If a lot of you aren't aware, this is going to be where your code lives, and it's great to keep backups. I definitely recommend it. A lot of people run into issues where their whole project is messed up and they never saved it. Definitely check out the GitHub. Be sure to save there. Now that was just a quick overview of that. Lastly, let me just cover Netlify. You're able to deploy your site by clicking your Bolt sites by clicking deploy, but I would definitely recommend for you to go to the settings of your website and then go to applications where you're then able to connect directly to your Netlify to make sure you're connected to your Netlify, Superbase, and more. It's just a way to make sure that when you deploy, you don't have to claim the URL. It's a very simple neat trick, but Bolt makes it super easy for you to share in regards to your hackathon projects and for projects you're trying to make public. Again, when you deploy it, that would be the links that you share for your dev post, which we'll cover a little later. Now that we're talking about deployment, Emil, would you like to talk about, and this is something Emil definitely wanted to share with you guys. I know some of you guys actually use Cloudflare. Can you talk a bit a little bit about that, please? Yes. When we are hosting from a regional data center, clients and people that are visiting your site in different regions and different continents, that request has to travel intercontinentally. What Cloudflare does, and Cloudflare's history and experience actually come from DNS and content delivery networks. It's very convenient to very quickly add you to Cloudflare. Point the A-record to the Netlify server, which Petro will drop an IP for us in the comments there or put in the description. That's the Netlify proxy server. Add your domain to the Netlify domain management under the project, and you will be good to go. The only part that can take time is to change your name servers to point to Cloudflare. Cloudflare handles your DNS for you. It's free. It's got DDoS protection, it's got automatic SSL deployment, and it will enhance your Netlify deployment. I'm not taking away from the Shaflaya, we are enhancing your Netlify deployment. It's a great place to centralize your domain management on DNS level. When you get to things like integrating MX records for mail and you have to do subdomains, all of that, Cloudflare makes it ridiculously easy. Bonus book, I'm sending with this problem as well myself. When you've got a new project with inbound mail, you want to create a contact at project domain name. You don't necessarily want to go create an inbox for it, or you don't want to go rent inbox space for it. It can't get expensive when you've got multiple things happening at the same time. It's a free service in Cloudflare that does automatic email forwarding. You can go and set up a quick alias contact at project and you can set that to run to your Gmail account or to your other project's account or you can set it to your assistant, it doesn't matter, shared inbox, it doesn't matter. But it's free. You can very quickly receive inbound mail, very, very quickly for free, while you're using Cloudflare to do VDNAs. My motivation for Cloudflare is done. I can have all episodes of Cloudflare. Okay, are we going to come back to... No, you've got next up, Petro. Then we'll bring all this. Oh yes, am I muted? Let's see, it'd be good, you're good. Oh, okay, perfect, perfect. Yeah, oh, I am muted. They say, I can hear you now. Okay, perfect, perfect. We'll be covering a little bit about DevPost and shortly we'll be joined by another Discord mentor, Vera, who'll be helping us shortly. But real quick, a lot of you guys haven't submitted a project for a hackathon. I've seen questions, "Oh, I created a project, what do I do now?" Well, you go to your DevPost. This is going to be the site for our world's largest hackathon.devpost.com. Once you are signed in and created an account for the hackathon, you're actually going to start a project here. Then from there, I just wanted to do a quick rundown of how to submit the project. A lot of you are like, "Oh wait, I have Teams, how do I submit it?" Well, let's start first. You're going to send an invite link to your teams. They're going to accept and they're going to join your team link here. Or you can just share the secret invite link, which is fine. From there, you're actually going to do a project overview. Talk about the name, put an elevator pitch, kind of a quick short, sweet messaging about what your project does. Then you're going to go to your project details, which you'll talk about a lot more about your project. I'm not going to lie. For the AWS MCP hackathon, I had like five minutes to submit before the deadline. So I just used ChatGPT. I'm like, "All right, here's my project quick quick, barely got it in time." We ended up winning. So that was great. You can actually also enter your language models here. What languages, frameworks, APIs did you use? Definitely want to list them out because as you're going to use the sponsors, they want to list it. So they want to make sure they know which sponsors to look out for. Then you can also try it with demo links, project links. So this is an image gallery. Just make sure to take screenshots of your site, super important. As well as a video link. So this is where you're going to record yourself. I recommend using OBS to record yourself. Add a little camera and kind of like talking through. I use the green screen as you can see now to just be over my site and just talk about how my site works, why to use it. Additional info is going to be pretty extensive. Remember, there's going to be a lot more information in the rules and description for the hackathon available. We'll add the URL there. I don't know if you have access to that, but please, if possible, share the rules for the hackathon, which we covered extensively on the Discord. So yeah, again, join the Discord. You'll get all the information they need. So many people available. Insert the URL that's available, the Bolt URL, as well as when you just start creating this, which challenges you're submitting to. Now, of course, your project can submit to various challenges and you can always submit more than one project. But just make sure to list these properly. Then from here, you're also going to add the additional relevant information. What bonus prizes are you submitting to? Of course, go to the rules, check out which ones you're applying for. Make sure that you actually add their API keys as we showcased in the Superbase brief tutorial. But again, if any of this is above your head, check out our Discord. We're going to walk you through the entire process. We're going to leave no one behind. The mentors are amazing. Shout out to the mentors and Vera who'll be joining us shortly. Add organization name, region, because there's been regional pricing as well as some other additional information. Lastly, once you're done with all that, you're going to be able to submit your project. You're going to click the terms and conditions and click submit. Now, of course, after you submit your project, you can always actually make edits and make changes. But that's the simple way of going to submit your hackathon project. Of course, if you haven't already, definitely sign up. Bolt is amazing. This is the best project I've ever seen, the best hackathon. So definitely check out the hackathon webpage as well as the sites. I don't know if we can share those on the chat as well. But definitely, if you're not already, also join the Bolt Discord. Now with that being said, I'll be stopping my screen. Can we actually have Vera? Vera, are you in the stream yard? I'd love to hop you in and actually introduce one of our Discord mentors. Hi, Vera. I think your mic is muted. Hi. Hi, Petro. Hi, everyone. Good evening. Can you hear me? Perfectly. Here's your loud and clear. We can see you. Thank you so much for joining us, Vera. I did a quick intro, but you know, you wanted to just tell us a little bit about yourself. Of course, I'll then ask you some questions along the way. Sure. Thank you so much. I hope you can see me clearly. It's late here. So my name is Vera. I'm a part of the amazing community mentors for this hackathon. I'm actually a product designer as a professional. Yes. But then my experience as a community mentor has been very good. It's been very awesome. I love seeing people being happy in the way you help them out. I love that. Shout out to all the mentors out there. They've been very great and being very, I mean, and please, I would want to say a shout out to you, Petro, and Emil. You guys have really been very awesome, and I really love what you guys are doing. Please keep it up. Thank you. Thank you so much. Yes, our pleasure. Okay. So now that Vera is joining us, of course, there are so many Discord mentors available on our Discord. If you haven't already, check out the link. Vera is one of the amazing people on there. I definitely want to shout them out and actually have them join on the stream. We'll be talking about some of the questions in chat. I know a lot of people have been talking. Vera, if you, I think I might have sent you a link or so, but do you have any idea of what are some common questions or common errors that a lot of people like joining for the first time might not be aware of or something to keep in mind for that? Yeah. So one of the major questions I keep getting from people is the token usage. People tend to complain about how quickly their tokens get used up. We have a guide that tells people how best to go about using that token. For example, there's a guide to that, and I'm sure Petro should share the link to that. But then one major step is for you to use the discourse mode. If you just want to plan your idea or your application, you can just use the discourse mode, and Bolt will help you discuss and fine-tune your idea before you start building it. With that, you can use your tokens effectively. Another thing is about the one-shot. People do get confused because when you give a prompt and people are not sure whether or not when they fix errors within the code, if that counts as one-shot. The rule says that one-shot's condition is the app that you are able to build with one single shot. You are able to fix errors and do stuff within the code. But then if you want to use things like ChatGPT and the rest, you can actually do that. But then you just have to use one prompt. What's about you do beyond that? You need to document your process to the judges. Basically, I think this is the top questions. I'm not sure if I missed out on anything. Thank you, Petro. Yeah. No, that's fantastic. I think a lot of people had some questions about not only how to submit your projects, like how do I work with certain sponsors? If there's any of you above, you need to have access to. I want to stress it again. The Discord community has been amazing. We'll be actually having a Discord mod for our next call as well as some other mentors. Vera is one of the amazing people who signed up for this hackathon. The important thing about this is because mentors are readily available from all over the world, I'll shout out again to Monica and Kate for putting this all together, such a wonderful team and a way for you to not only submit for the hackathon, but if you're joining us for this first time, learning how to submit in general. We're seeing so many people submit from all walks of life, as you mentioned. I'm seeing people in chat as well who also might come from different levels of coding and more. I think that's really important. We're so glad that you and more people have been available for this. Let's go over some questions. I know there were just some various ones here and there. Let's see if we can go over it. I think the biggest question I got from here was that people were wondering if we're not, we can have access to it again. One shout out again. Emil will be sharing the PRD information. This will be in our video description. It's been shared also in our chats, but we can definitely access the share of the prompt, but essentially the first part of the prompt is not that difficult. The framework for doing it is actually you get build a generic prompt. Of course, Bolt has an enhanced button in the prompt itself. You can actually enhance your regular prompts. We're taking a step further. You're going to submit like, "Okay, I want to build a pet site." Go to GROC. Get that initial prompt there for getting the prompt built and then enhancing it using Cloud. Then at the end of that, once you have the enhanced projects, I definitely recommend, and this is something people don't do, they just copy and paste. Look through your prompts. Let's read through what it's asking before. Let's read through what it's building. Let's decide. Of course, when you're starting for the first time, it can be very difficult to understand. But once after a while, you understand the general framework for how to apply that. Definitely, we'll apply the PRD information at the end of all on the video description of this recording as well as more so. Let's go through the questions of saving some of the tokens by working with elements like Cloud before prompting by Bolt. Yeah, shout out to Beverly Pell using a plate pre-plating, especially in the age of AI. It's so important. Being able to provide this extra information will not only give you a better backend for saving tokens, but it'll give your bolts more context window for them to understand whether or not they can be processed more so. Yeah, so we covered some of the super-based things. Let's go through here. Venture run-throughs. Shout out to AJ Marks, great run-through on super-based. Oh, my pleasure. Definitely want to make it quick and easy because I know this is more advanced. So we'll have various topics in regards to that. When is the next hackathon? Well, Shay is asking when is the next hackathon? I know this is something that me and Vera know, but there are so many hackathons available worldwide and now that you're using programs like Bolt, it makes it easier than ever to be able to submit. Because of things, eventually you don't even need a hackathon. I think this like last Saturday, I spent 16 hours just pure building and learning. Just straight. So with tools like this and the course, use the hackathons like this to learn and develop really important to be able to learn your skills and being able to launch sites and more so. Let's see, Patrick Manipu Jr says, submitted a random video from my project during submission. Will that count as spam project or will I submit a valid video before the deadline? Yeah, you can always edit your projects. I don't think they're checking any submissions before then. Definitely edit your projects and definitely check out the rules. Let me see if I can pull that up here in regards to their hackathon requirements. You definitely want to make sure that you go to the rules and make sure that you cover that regard. I'll put it in our chat with other links as well. In regards to the larger file size, this Google Docs is better to just go on our Discord and we'll have mentors help you out in regards to that. I'll search some links to me and Emil's social media. Emil's hopping on shortly, but the rules page is going to be super important. There's so much resources available, especially when it comes to more so. Oh, Vera, we're getting some Anna Perez is saying hi Vera, Pepper says hi Vera. I don't know if you know that there might be other mentors. No, I think probably they're part of the viewers on Discord. Hi, hi everyone. It's nice to meet you guys. Perfect. Mad scent is like I'm the only one who can't hear the discussion. Don't worry. We'll have a recorded video of this later after this is done. This is live on YouTube, on the X. Can we use another way to upload to Netlify? Yes. There are other ways to upload to Netlify apart from the deploy. You can go a little bit more manual, but I definitely recommend if it's your first time, just keep it simple. A lot of people are running into issues by using third-party integrations that aren't easy to do, especially if it's more advanced. So keep it simple. Just use the deploy, you connect to your Netlify. But if you do want to go more advanced, I recommend connecting to our Discord mentors who will just walk you through the step-by-step of how do you get that process going. Of course, you can brainstorm using AI and more so. Kind of like a placeholder container editor. Okay, so Leon Clawed Hopson on YouTube is saying, "Whoa, that's interesting, Petro. So you're saying we can submit a project kind of like a placeholder and continue to edit if necessary." That's been my experience. Of course, I'm not submitting for this particular hackathon, but for my previous hackathons, yes, you can edit your posts on a dev post, but just to be safe, submit a working project. Just in case it doesn't run to errors for some reason, and more so. Oh, this is really an important question. William says, "Can we use cursor?" Great question. We get it all the time. The rules are very strict in terms of what you can or can't do. I don't know if you want to answer this, but I have my placeholder answer, but if you want to, you can, it's up to you. I have something ready. It's not. Yeah, sure. You can answer that, but then the rule is actually very clear in that regard. You need to build mostly on Bolt. You can actually have other applications to help you here and there, but then it should be very clear that the whole application was mostly built on Bolt. So regardless of how you go about it, you have to make sure that the app is mostly built on, which should be evident. Yeah. The important thing also is the rules are very strict in terms of cursor, because I know a lot of people use that. But the thing is you must deploy off-bolts and your build has to be built with Bolt because cursor being a code editor, you only can use other features if it's something that Bolt can do. If something like code editing or building edits, that's something that Bolt can do. So we are not judges. Definitely check out the rules that we shared. Remember, I would say better, safe, and sorry, just use Bolt. If you run into issues, that's somewhere you can ask a mentor by Discord, but definitely we're seeing a lot of that. I made very clear. I think when this hackathon started, definitely check out the rules. Oh, okay, quick. Before we end, we have some quick comments on X as well. Gearest Ken says, "Right out of my 10 million package tokens before realizing I could have used chat." Yes, Bolt has a discussion mode. I don't know if you're aware of this. Save some tokens. It'll still use some tokens, but way less so being able to process and kind of go back and forth within Bolt, being able to chat. Definitely important. Very important. Mike Chase says, "Will you all be posting a cardee from this video?" So we'll use that example. Yes, we'll be sharing the prompt at the end that Emil shared in regards to that, which is going to be very important. But of course, guys, more than importantly in that Vera and I are not Bolt staff. We are mentors. We are not judges either. If you haven't already, the most important thing, it comes to anything in regards to your project. Check out the rules. That is your bread and butter in terms of submitting for this hackathon as well as more. So like I say, better, safe, and sorry. Double-check the rules, ask questions on the Discord. Again, if you haven't, you'll meet wonderful people like Vera who was so graciously joining us today as well as meeting some other people that we'll talk about tomorrow. While we are ending this stream, the last find this, I do want to do a quick shout-out to you, the people submitting into this hackathon. I know this whole month has been very difficult. It's been a lot of ups and downs. A lot of you are learning how to use AI tools for the first time. I know it can be very stressful, but Bolt has done such an amazing job, giving the community together to get you guys access to the best mentors, the best community. There are people like Emil who is available live stream all the time, almost all the time to talk about some of your problems. It's mentors like Vera who's going to be helping you out with some of your questions. Of course, check out the Discord. There's going to be a hashtag questions, hashtag help, or you can ask questions. There's also a big community there. When you're building, the best way to learn is to learn together. I definitely recommend that's why we have series like this available. I do want to shout out, of course, to all the mentors who are watching all the mentors in the Discord, all of the moderators, as well as our staff. Monica and Kate have done such an amazing job putting this all together. Thank you so much. I know Donald's been involved too. If you haven't already, let's get a shout-out to them. If you can just say thanks, Monica. If this has helped you, please say thanks, Monica, and thanks, Kate, in the chat. They brought this all together. Thank you so much for not only setting this up but also getting us the whole procedures for helping everyone succeed in this hackathon. We're so excited for you guys for this hackathon. I know it can be really daunting being able to learn for the first time, but there's never been a better time to submit. Of course, if you haven't already, I think we put the social links for me and Emil. If you want to follow us, we'd love to connect. We want to add more friends. If you learn anything from this call, pop on the Discord. We have so many tools available for you guys to learn. If you haven't already, we'll also be going live tomorrow at the same time. Emil and I will be live. It'll be less technical, more practical advice if you don't know how to grow on your portfolio. How do you get clients? How do I come from this from a really existing developer? How do I use social media to grow our presence? We have exceptional people who've gained clients who've grown thousands of followers on social media. Never a better time to learn than today. We have all the tools available. If you haven't already, give it again. Big shout-out to Monica and Kate for getting this all together. Any last words on your part? You want to just share how has this whole hackathon been for you? Any last words? We have a minute and a half left. Yeah, sure. Thank you so much for everything. I want to reiterate that for those who are not yet on the Discord channel, I would encourage you to join because it's really hot, very well over there. You learn a lot, you try questions, and it's not just about the mentors. You get other fellow builders answering your questions, and it's very, very lively there. Try and join if you haven't joined. I don't know if the link has been shared for those who are not there for them to join. Yes, aside from that, I would like to encourage everybody who is participating in this hackathon to keep pushing. I know it's very stressful and daunting, but then you've come this far. Just try to get to the end. Thank you so much. All right, we have 45 seconds. Emil, take it away. Okay, quickly, share my screen there. I want to show you guys what we built in this session right now. This is a show we're not cheating. Here's the original prompt we had for the document management system, and then it kicked off into our phase one. I want to show you this absolutely stunning landing page that was built while we were talking. Our PRD, ladies and gentlemen. The power of PRD. Doing it right, landing page is ready. We spend a few more minutes rigging up a waitlist and you're good to go. I'm very impressed, very, very impressed that we've managed to crack out a stunning landing page for this intended purpose, and this is a live example. Love it. Thank you, Bolt. Thank you all. Be sure to follow our Discord. Join the Bolt Discord. You'll get to meet people like Vera, add me or Emil on our links, and thank you guys so much. See you guys tomorrow, same time. We'll cover some exceptional topics. Thank you guys for joining. Good stuff. |
|
|
|
Video: Coming soon: bolt.new diffs (increased speed + efficiency) |
|
So, Dom, I'm handing it over to you because we have some exciting updates that are incredible. They're not only preserving tokens but also making the entire Bolt experience incredibly fast. Take it away. Alright, thanks. I don't have such a cool storyline as Sam had. That was pretty funny with Facebook. I don't have such a cool story. So, we've been thinking really deeply about how we can optimize the general performance of Bolt while significantly reducing token usage. I'm excited to share that we've made some breakthroughs in how we handle code generation and modifications. There's more depth to this than I ever anticipated, with many edge cases requiring extensive research. This has taken a while, but we've done our homework to figure out a reliable way to get the model to generate smaller outputs while making everything faster. Essentially, what we've been investigating is how we can get the model to be more efficient. These models and LLMs are particularly good at generating files from top to bottom because that's what they've been trained on. However, for the end user, this is inefficient. It produces a ton of output tokens, which are expensive, and it makes the overall experience slow. If you're asking the model to make a small change, it will generate the whole file from scratch for maybe just a one-line change. We've researched how to improve this and what approaches we can take. I'm going to share my screen and show you what we've been working on. Just to add some depth to the complexity of this, Dom has a background in machine learning prior to joining Stack four or five years ago. Dom has been working with folks on the Anthropic side on what you're about to see because they said our agent stuff is some of the most sophisticated, complex stuff they've seen in production on their models. This is pushing the limits of what you can do with frontier models right now. This is a pretty big deal because the folks making these models didn't have a prior point to guide us. Now, I will say that generating depth is key. We've implemented a diff-based approach. Instead of regenerating full files, the model can make precise changes to single files, changing just a few lines. In our testing, this can reduce token usage by up to 90%, which is huge. Speed and performance improvements can be massive, with differences like 30 seconds versus two or three seconds in certain cases. It's hard to generalize, but I'm going to stop talking and show it to you. On the right, we have Bolt at new, which is the production site. I've switched to the dark theme so we can better tell them apart. On the left is the preview, which contains the diff-based approach. It's not novel, but it took a lot of research to make this reliable. Let's do the same thing on both sides. I'll add, let's not go too crazy, maybe "Build me a snake game." It's going to take a while. Hopefully, this will work fine here. For creating new files, it will generate the files from top to bottom. But we'll see the magic when we ask for changes. At the beginning, it depends on the files that already exist and what you're asking for. There's a bit of latency, maybe a lot of people are using Bolt. We have our snake game here. Just for clarity, the left is the magical new goodness, and the right is what's currently available on Bolt production. Yes, the right is production, and the left is preview. Both versions look good. Now, I'll make a seemingly small change. I'll say, "Make the food blue." It updates the whole game, which is what most LLMs are trained to do. This can take up to 20 seconds. Let's see the difference. Did you see that? It just made that line change, and it's blue. This is massive. On the surface, this seems simple, but we're working with a system far from deterministic. Giving it instructions doesn't always guarantee it will follow them, which is why it takes a lot of work to get this to work reliably. I can ask for more changes, like changing the color again. I'm curious to see this because I haven't tested it side by side myself. Let's say, "Add a wall every five seconds." Here we go. It's changing these lines. This is only the baseline of the diff-based approach. The UX isn't fully polished yet. We'll ship follow-ups with improvements where you can see the diff. Look at this, it's already finished while the other side is still generating all the code. Even though this didn't work perfectly, the point is that sometimes you have to be more specific. If you burn a ton of tokens on something where the AI screwed up, that sucks. This eliminates a ton of tokens that would have been spent on something that didn't work and needed further instructions. Imagine, for every change you ask for, it would regenerate hundreds of lines of code. Now, it's a small change. The diff-based approach demonstrates its power, significantly reducing token usage and making it more precise with fewer unintended changes in unrelated parts of the code. The diff-based approach is like a doctor making precise operations on specific parts of your body. It closes the feedback loop even further. Our mission has always been to get an idea into your fingertips and get responses as fast as possible. This will allow you to get more messages per token and more iterations faster in the same amount of time for fewer tokens. That's huge. However fast you've been building with Bolt, it's going to get a lot faster. We have a preview URL we'd love for you all to test out. This is fresh. If you're going to make a snake game, see if you can get some walls to show up or not on the preview. This is a big change, and we're excited to get it out. We don't want to roll this out into production without thorough testing. We want people who are on the cutting edge to give this a shot and provide feedback. This isn't some other version of Bolt; it's tied into your production Bolt account. When you use the preview URL, you can edit projects you're developing on Bolt. New. If you have important projects, I recommend forking them and making changes in a fork to ensure you don't lose data. This is alpha stuff we're hammering out, and we'd like to land it either this week or early next, assuming we don't find any regressions. We appreciate your help. Maybe we can post the link in the chat for access. I also want to mention that the new diff-based approach helps with the laziness of models. The model sometimes gets lazy and adds comments like "your other code here." From our testing, we see significant improvements in the model being less lazy with the diff-based approach. This should make it more precise. |
|
|
|
Video: Deploying Bolt.new with Netlify in ONE CLICK |
|
In this video, I'm going to show you how easy it is to deploy your Bolt.new app into production with one click. Beyond that, I'll demonstrate how to take the standard URL you get from that deployment and connect your own custom domain to make it look tailored and personalized to you. When it comes to deploying a domain, all you have to do in Bolt.new is use the "Deploy" feature, indicated by a rocket emoji. You click it once, and it will generate what's called a Netlify URL. If you're not familiar with Netlify, it's a cloud service provider that lets you build and deploy serverless backend web applications and dynamic websites. You can host your app on Netlify by default through Bolt.new, and you can buy a domain and connect it with just a few clicks on the same platform. I'll show this process live in action in Bolt. Once we click "Deploy" and get a URL, we'll go to our Netlify account, where you'll see the name Bolt has assigned to this app. You'll be able to click on "Domain Management." Here, you can buy a domain or add a domain you already own outside of the platform. If you purchased a domain previously on GoDaddy or Namecheap, you can import the URL and connect it to your web app. If you choose to buy a domain, you'll see a screen where you can enter an example domain you're looking for, and it will show you all the options. If it's taken, it will tell you, but it will provide alternatives as well. You can then click "Buy" to assign that domain to your app almost instantly. Now, let's put this process into action. I asked Bolt to build an app that allows users to view examples of beautiful designs of websites and mobile apps. It lets them favorite designs they see on screen, which saves on a left-hand panel for future reference. After a bit, we got something where you can scroll through and favorite designs you like, which show up on the left-hand panel. It's functional as a mini prototype. To bring it to production, click on the blue "Deploy" button. This takes 10 to 15 seconds and produces a blue URL hyperlink. You can click it to see your app instantly. We've now assigned the URL brilliantllama.netlify.app. You can share this URL with anyone, and they'll be able to see your app. However, you might not want it to be called "Brilliant Llama." If you're logged into a Netlify account, you can go to Netlify, find your project under "Projects," and click on it. On the left-hand side, you'll find "Domain Management." Click on "Add a Domain." In this case, I'm going to buy a new domain, such as beautifuldesignsapp.ai. It looks available for $90 a year, but you might want something cheaper. You can choose beautifuldesignsapp.org, click "Buy," and proceed with the purchase. You'll have to register the app, and once you click "Register," it will purchase the domain, making it accessible for your app. The domain preparation can take 10 to 15 minutes. Once it's done, this will become the new primary domain, while the former Brilliant Llama URL will still point to the app. This will be the main way you interact with it. |
|
|
|
Video: How Jay built and sold his Bolt app for $3,000 |
|
We are live. Awesome. That usually takes a second. It's ready. Wow. We're going to be busy this week. Welcome, everyone. This is our last live stream until January. So yeah, we started a little early today. But welcome. We have a lot packed, so I will hand it over to Eric. Okay, yeah, excited. This is the second week in a row we've got a person from the core team here. Last week, we had Colin, who created the open-source fork of Bolt. This week, we have a very special guest. I think a lot of you in the community have probably seen this fellow around building some pretty cool stuff, and that is Jay. So Jay, we're super excited to have you here, man. Hell yeah. So, you know, I think maybe just to kick things off, I'm curious. This is actually the first time I've ever chatted with Jay live. I think I'm probably speaking on behalf of most people online with the questions I'm going to ask. I'm curious to hear more about your story and your background. You've been making a lot of content, building out some bolts, and there's the legendary tweet where you made a micro app with Bolt and sold it for three grand. I want to hear about all of that. How did you get into Bolt, and what were you doing before that? What's the story of your life, basically? Yeah, so how this all led to Bolt. I used to work at ClickFunnels, which is essentially a landing page builder. That got me into the world of marketing automation. I worked with a lot of copywriters and people like Tony Robbins, seeing all their funnels. This is kind of marketing geeky stuff, but being able to see that and how it operated under the hood allowed me to see marketing from a different perspective, which was how to use tools like Make, Zapier, and other marketing tools. Around the time ChatGPT came around, about two years ago, I started a company called Best of AI, which is essentially a database of different AI tools. I created content on these tools, and eventually, we grew our TikTok to 100,000 followers and Instagram to 70,000. We communicated with the audience on all these cool AI tools that were coming out. I have a pulse on all these different AI tools, and Bolt is fairly new, but I've had a pulse on AI coding and what it can do. Personally, I'm not a coder. I don't know how to code. I like to change that framework from coder to builder. That's the mindset I have right now. I'm building things. I have a lot of ideas. About a year ago, I heard about Bolt and thought it was cool. When Bolt came around, I decided to try it out because it's visual, and I'm very visual. I can say, "Hey, change this to a different color," or "Make this operate a certain way" without having to know technically how to code. That opens a whole new world for people like me who want to build tools and ideas but don't necessarily have the time or resources to learn how to code. To answer your original question about how I got into it, I have a pulse on it. When I find something really cool that I think is going to change the world, which I think Bolt and tools like Bolt are going to, I like to go deep into it. Although Bolt is very new, I've spent hours building inside Bolt, which allows me to not only familiarize myself with the tool but also create content and learn alongside an audience. That's why I can create tweets, and people see it as novel ideas. I like to push the limit by taking my marketing automation skills and combining them with this new way of creating ideas. Obviously, I made that tweet, and people resonated with it. Now, if you go on YouTube, you see so many videos saying, "Hey, I like using Bolt and Make.com to build an app." That one tweet changed the perspective of so many people like me who want to build tools and apps but don't know how, and Bolt is allowing people like me to do so. Before you were using Bolt, were you doing any software development? To what degree are you writing code in Bolt versus just prompting? Right now, with AI, it's the best teacher. If I don't know something, I'm throwing myself into the deep end. I have messed around with coding, trying to familiarize myself with CSS and HTML. I'm pretty sure everyone has a story like that. Then I went to no-code tools, starting with Bubble, then Webflow, and then Taddle, which really connected the dots for me. Taddle is a front-end builder, and you have to manually create things, but it introduced me to APIs and the front end. I used no-code API builders like Fastgen and Buildship, which are similar to Make. I built an app in Taddle with all these different components I learned, using AI to teach me. I spent a month building this app for a program I was creating, which was a course teaching people how to do AI freelancing. I had a tool to accompany the course. There's going to be a shift where tools become a core component of how people sell things. If you're able to build tools to accompany and add value to what you're selling, that's major. We can get into the app I built and how I sold it, but that's the shift I'm seeing in the marketplace. People selling courses or information can build tools alongside that, which is very high value to the person buying that particular program or service. Jay, something you mentioned that jumped out to me and is relevant for new Bolt users is educating yourself on the tools. You've been in this space for a while, so you've gone through iterations of older tools. Now we have large language models that can help in the education process. Could you talk more about your mindset on learning a new tool and how a new user should approach that? That's a great question. A lot of people ask me this. I believe everyone has a superpower. For me, I'm able to go into something, study it, understand it, and ask questions. A lot of people struggle with asking the right questions. Before LLMs, you had to find someone or a community, but now you can just ask AI the questions you have. It's okay if it's dumb; you're not going to get judged. When I first loaded up Bolt, I wanted to see if it could build a login page, similar to a coding course where they teach you to build a to-do app. I was like, "Let's see if it can build a login." It did, and I was like, "What else can I do?" Going deep and not being afraid to mess up or fail is important. You're always going to be a beginner at first, and with AI, you can accelerate that learning process. Before, it might have taken six months to learn something, but with AI, it can take a week. AI is the best coach. If you use AI and ask it the questions you have, whether it's an error or not knowing how to connect something, you can learn quickly. For example, I didn't know what a skeleton was when it had gray boxes while loading. I asked AI, and it told me. You can learn quickly if you know the questions to ask. Even giving images is helpful. If I see an example of something I want to copy, I take an image and ask, "How do I do this?" or "What's the process to complete this?" Utilizing AI in that way to learn is powerful in the era we're in. I think you're right. To zoom out, not just talking about Bolt or building web apps, this is the end game of making it accessible to learn anything. I appreciate you laying out how you've approached it. A lot of people on our side are developers, so we're deep into how all this stuff works. I relate to what you're saying because I take a similar approach when I'm poking and prodding on stuff that Bolt is spitting out. I haven't written that specific framework or component library. It's important to dig in and get a general understanding of high-level concepts to best instruct. It's important. It's like any tool. If you tried to use Photoshop without ever having done a tutorial, you wouldn't get far. I know because that's how I tried to learn Photoshop, and it was terrible. Back 15 years ago, I learned to use it. I'm curious to hear the story of the micro app you built and sold. Walk us through that because I want to hear it from your perspective. What was the thing you built, and how did you find a buyer for it? Zero to 60, how did you do it? A lot of people are interested in doing similar things. To hone in on one of the points you made, you guys are all developers, and I'm coming in saying, "Hey, I use AI to build stuff." I think there are a lot of components to AI and building things that, as a newbie or someone just beginning, you'll probably struggle with. That's why I don't believe AI agents will completely take over software development because there are so many components, like hosting, API routes, and more. There's just so much. I have a friend teaching me a lot of this stuff, even though I know it. It's about connecting the dots. If you're able to build these micro apps, which is how I'm defining it, I'm not building software with many components. I'm building micro apps that do one specific thing really well. The reason I was able to sell this app is that I had a background in building marketing automations. One of the automations I built for myself was for my social media, creating AI avatars. I automated that process, so I never had to be on camera again because filming content takes a lot of time. I used Zapier, Airtable, and Pigeon API to automate that process. I showed this particular thing to someone at a mastermind, and they were like, "Hey, that's super cool. Let's stay in touch." I stayed in touch, and they asked if I could build an app that does a specific thing. They wanted to take an Instagram or TikTok URL, transcribe it, and rewrite the video in a new style. Very simple in theory. I thought maybe I could do it in Airtable with complex automations. That's when I saw Bolt and thought, "If I can do this inside Bolt, that would be sick." Originally, I wanted to use Fastgen, a no-code API builder, but I couldn't get it to work. Maybe it was because they were downsizing. So I thought, "What if I use Make and a webhook to make this API call to a service called Fast Favorite API, which allows you to download videos?" It worked, and I was like, "Holy crap, this is really cool." From there, I continued building and asking it step-by-step questions. Eventually, I got it to work. I can show you a V1 of the app too. Totally built in Bolt, and I got it to make the API work. I showed the guy, "Hey, I built this in three days. Is this what you were looking for?" He said, "Yeah, this is super sick." I said, "This is going to cost 3K." A lot of people in the original tweet were like, "Dude, you could charge more for that. Why did you charge 3K?" The thought process behind the 3K number is, one, it's an easy sell. I'm not necessarily looking for the maximum dollar amount because the idea is very novel. Prior to this, no one had done what I did, and that makes for good content and a good story. It's a real story. Because it's a novel idea, it allows me to be positioned as someone thinking ahead, which is why I'm on this live stream. It's not always about the maximum dollar amount. Sometimes it's about the easy sell. Once you have that easy sell, you can replicate it. Now I know I did it once, I can do it multiple times, and I'm going to. That's the story behind it. I can show you the app. We'd love to see it. Also, what you're pointing out, for anyone thinking of starting a business, especially if you're selling a product or services, it's always a good strategy to sell it once and give your first customer a really good price that's just an obvious yes. Once you sell one time, you have the confidence and a referenceable customer to go and sell more things to more folks. That was a really smart idea on your behalf. I mean, 3K in three days, I don't know how much money other people are making, but I'd take that deal. That's a solid amount of money for the time you invested. At that point, you can also upsell. You can say, "Hey, there's a management fee involved," or "I will add X amount of features." At that point, they might want to add more things. He was already asking me to add more stuff, which is fine. If he wants to do that, I can charge more or not. Either way, it's important to get that first sale to boost confidence and validate that there's something here. Let me show you this, and hopefully, the demo works. We have a demo later that hopefully will also work. We're in the same nervousness camp as you. To be fair, I did offload this into that client's account, so I haven't really touched this, but you can kind of see it. I'm going to share my entire screen here. You might have to pull it up. Oh, yeah. Look at that. There you go. This is basically the app using ChatCine. I know you guys recommend not to, but at the time, I liked the UI, and it worked out pretty well for me. I can't complain. Before you guys had the Superbase integration, I had to ask Bolt to create the SQL queries, and it created that for us. Somewhere in here, it has the migrations for it. It literally created the SQL query so that I would be able to save the data I was entering here. Eventually, I also added AutoSave. What's cool about this app is I just told Bolt, "Hey, can you add AutoSave functionality?" and it did it. This is the app. Again, this is one use case. It's not a software; it's a micro app that will accompany this client's service. They'll be able to utilize the service and say, "Hey, client, you can use this to do whatever you want, and it's included in the thing I'm selling," which is a distinct difference from building a SaaS. I'm building a software micro app that could turn into software eventually, but it starts off as one thing. The one thing is entering a TikTok or Instagram URL here, clicking Continue, and then you can either input some information here or use templates. This is the specific prompt, and this is the style, meaning who I'm trying to talk to. After that, it's just pressing Generate Script. It's calling the webhook inside Make.com and pushing back the data into here once the 200 requests come through. Again, I'm not a developer in the traditional sense, but I knew what I wanted the outcome to be. That's important: understanding the outcomes and figuring out what needs to happen for that outcome to be successful. If you take it chunk by chunk, you'll be able to figure that out. Adding these little things like changing the title every five seconds so the user knows something is happening. Talking to it and figuring out what you want done is the most important thing. You can do UI in Figma. For one of the apps I'm building right now, I built all the pages in Figma, which makes it easier to understand and conceptualize what you need to do. You can feed it screenshots too. Here we go, we got the result here. These are the versions of the script they can now copy. If they want to generate a new version, they can do that, and it'll rerun it. This auto-saves, so if I go to all rewrites, it should auto-save. Wow. This is crazy, man. Bolt is sick. What can I say? This is masterful. This is incredibly useful. For the backend portion, you mentioned using a tool called Make. Can you walk me through that? What external services are you using here? Bolt is the front end, and Make is the backend. When I press the button to generate the script, it's calling this webhook. It routes based on whether it's TikTok or Instagram, based on the URL. When you enter the URL, Bolt sends the data into Make, telling it whether it's TikTok or Instagram. It runs the calls. Once Anthropic Cloud makes the script, it sends the text back into Bolt. This is revolutionary because you can build these ideas quickly. If you wanted to take this to the next level, you might want to use Next.js API routes or whatever else. For a quick V1 MVP, you can use something like Make or Zapier. It's about building these V1s. Most SaaS starts with one feature, one thing it does, and you iterate based on customer feedback. Bolt allows you to take it step by step, figure out the core thing, and start with the micro app. See if there's validation for users, then expand upon it in Bolt or self-host or whatever you want to do. I go into Figma and map out what this will look like. This was an app I built, not in Bolt, but the premise is the same. You want to build out the pages and figure out what a V1 would look like and how quickly you can get that V1 out. I use something called Stratus UI, which is a UI kit that helps me quickly create these pages. I don't even know what these are called, but you get what I'm saying: the page required for the app, the UI. You could also use something like Excalidraw, which is something a friend of mine uses. It's about building out the V1s of the pages before going to Figma. I found that if you give it a screenshot of something like this and say, "Hey, Bolt, I want it to look like this," it'll do a pretty good job because you have that screenshot versus just saying, "Build a navigation on the left side." You can say, "Build a navigation that resembles this UI with this many units," and it'll do it. I've found that adding images is very helpful for Bolt to understand the context required to build that app. It's really about what you want to build. Can I build a UI quickly in Figma or Excalidraw, then hop into Bolt and build out the V1? I want to preface that I'm not a master bolter, but I spend a lot of hours on apps, especially when I'm interested in something. I go deep, which they say you need 100 hours to be masterful at something. If you spend eight hours a day for two months, you'll be pretty good at something. People are building amazing things. Today, I saw a 3D editor being built, which is insane. Pushing the limits of what this tool can do is going to transform a lot of people's lives because many people have ideas but don't know how to get them out. Bolt is allowing people like me to get those ideas out quickly. Kudos to you guys and the team. Back at you, Jay. You are absolutely in the top users of Bolt. You probably use Bolt better than our core team. It's nuts what you've done. There are a couple of comments in the chat I want to pull up. The approach you're talking about, chunking out the work, is important. A common failure mode is asking Bolt to do a whole bunch of different things. It's like telling a human to do multiple tasks at once; it'll do 10% of each. Jay, I'm curious, how much time do you spend planning, like Figma time and thinking through stuff, versus actually typing in Bolt? To be honest, for the YouTube tutorials, I'll just type. For the YouTube tutorials, the only thing I script is the intro and outro. Everything in between, I have no idea what's going to happen, which is kind of living life on the edge, but I enjoy it because I can really push to see what this app is capable of. If I'm taking it seriously, like the app I eventually showed, that had a whole UI that took two weeks to build. I was very critical and specific about what happens when you click this button and that button, which helps with building inside Bolt or any other AI tool. It just depends on the project. For the tool I showed, the Ajax Copilot, my buddy took a lot of time to think about it. He's a software developer by trade, B2B enterprise, so it's a whole different level. For him, it's critical to spend time not only pre-planning but thinking critically about every aspect of the app, from the front end to the back end, security, and everything in between. I'm learning a lot from him as well. My friend Head is an awesome guy. If it's just playing around, I won't pre-plan much. But if I'm taking the time to develop an app I want to push, then yeah. One thing I didn't mention earlier is I had a software company. I kind of gave the reins to someone else to operate from a development standpoint. I never really told this story anywhere, so you guys are getting the juicy details. I had a software company called Cart Fuel. I didn't know how to code. I got it off the ground by hiring people from Upwork and had developers I trusted. They did pretty well, but they only took the app so far. I needed it to go further. We had about 2K MRR, and there was a lot of potential for scalability as long as I got the app to have a better infrastructure. That was about two or three years ago. This year, 2024, I brought on some technical co-founders. Unfortunately, things didn't go as planned. They saw the company one way, and I saw it another way. They felt I wasn't putting enough effort and time into the application. Essentially, they deleted all the code and the backups, so I was kind of screwed. I had the V1 of the app, but I had 2K MRR, and people were using it. It sucked. The reason I'm telling this story is that Bolt and tools like Bolt allow people to take control of their ideas. For me, that's really important, to have ownership of those tools. Because AI is a great teacher and I can learn quickly, I have more power to control the destiny of the things I think are going to be big. Just a quick side note because I think it's important to know that Bolt is allowing people to have that ownership. I'm sorry to hear that happened, man. Sadly, it's a common thing that can happen. It's a really good point because that's primarily the reason I learned to code. If you're building products and businesses from the ground up, it's a huge advantage to be able to directly contribute and understand all the different layers of how it works. The problem is it's a weird relationship if you're relying on other people to do critical things. As the CEO of Stack, the approach I've taken, and I think a lot of startup founders do, is to become a domain expert in many different things as the company grows. At the beginning, it might be development, design, and product, then marketing and sales. But the problem is if you don't do that and just hire someone, how do you even hire someone to do a function you don't understand? How do you find the best people and connect the dots effectively? It doesn't mean you have to be the best, but it's about getting dangerously good at it. Then you can bring on great people and have productive conversations about how to better architect the app or close a deal. It's amazing to hear that Bolt has been able to augment your ability to do that. Totally has, 100%. Another comment I wanted to pull up here. Mauricio said something that came to my mind while you were talking. It makes a ton of sense. For different folks running businesses, the micro app you sold, the person you sold to presumably has a business use case for why they need that tool. It's kind of like from seeing the tweet, I thought it was super cool that you did that. But understanding the problem you're solving and why this person bought it blows my mind. There are probably millions of these things out there. It's more about ownership. It's about saying, "I own this tool, and I'm going to give it to you as part of my service," versus saying, "Go to this website, sign up, and pay them the money." You've already paid me the money, so I'm going to give you this tool as a value add. That's the key difference. You could find tools that do this, potentially. In our database, we have 13,000 AI tools, and not all of them are good, but I'm sure there's one that does something similar. For him, it's about ownership and saying, "This is mine. I'm going to give you this as a value add to the thing you already bought." Wow, that's so interesting. Just to make sure I understand, he's running a business or service, and this is part of the value prop of what he's providing to his customers. Correct. That's crazy. I mean, it makes sense, though. People don't get it. On the tweet, so many people were saying, "This doesn't even make sense. You're lying." It's a whole different thought process. Business owners see it as, "I can own this and build it out if I want to give it as a value add, which makes it easier for my customers to say yes to me, which makes it easier for me to acquire customers." There's so much you can do with micro apps that doesn't coincide with how everyday people think about why someone would buy a $3,000 app. It's an entirely new market, I think. This is the first time in history where you could do this and build very bespoke software in a way that's incredibly prolific. The cost to build something like you made, the development cost would be more than what you sold it for. Exactly. Neil Patel just released something about the ROI of initiatives in marketing. The number one thing on that list, on a number-to-number basis, is tools. If you look at Neil Patel's business, he owns all these SEO tools, and he uses them to acquire customers and sell services. It's the highest ROI. That is so interesting to me. I have so many ideas that I will bring to market, and you guys will see them. But like you said, this is a whole different shift in how you're able to build. I spent $20 on Bolt to build this app that made me 3K. From my perspective, that's a high ROI. For his perspective, he sees it as a value add. It works out. We've got some more comments coming in here. Some confirmation. Jay, what you're saying makes sense. If you think you're crazy, you're not. Although you have the hard-earned cash in hand. By the way, when you posted that, we saw people saying, "You're lying." I know, it's hilarious. You came with the receipt. I mean, here's the best I can do for you. Jay, listen, here's my crypto wallet. If you prove it, that he's trying to brand a Bitcoin, then I'll believe you. You know what's so crazy? This is not necessarily about Bolt, but I had someone send me 2K of crypto to go to Portugal. Craziest story ever. I have the receipts. This guy's a crypto millionaire, and he was like, "There's a Bitcoin event. Who wants to go?" One guy was like, "I would love to go, but I can't." I was like, "I'll go." He literally sent me 2K and made an NFT of the African flight. He's like, "Don't scam me. Just go to Portugal." Wait, you mean an NFT of your flight itinerary? I swear to you. I can pull up Discord right now and show you. Craziest thing ever happened to me. My family thought I was getting abducted. I took a flight from Newark, New Jersey, to Portugal and spent the week out there. You went. You took the... Oh my god. Okay. I'd be concerned if I was your family. What happened? I'm just saying someone can send you money, and it could be crypto. Anyway, that's unbelievable. Crazy story, I know. Again, people are going to call me a liar here, but what do you do? Unreal. Unreal. You should tell some of these stories while you build a Bolt. I am going to do a 25-hour video. I'm making it public so I can hold my feet to the fire and do it. It's going to be a 25-hour video showing you from scratch and seeing how far we can take it. It should be pretty sick. I don't know when I'm going to do it, but yes, I can tell stories during that for sure. I love it. I love it. 25 hours consecutive? I don't know how I'm going to do it yet. I might have to wear a diaper if I do 25 hours straight. I might split it up, to be honest with you. I would hope. I mean, we'll sponsor you with some Red Bull. Please. I would love that. You asked, do you do user research to find target users typically? I can only speak to how I did it. I had a software before, and what I did for that is I went to the HubSpot Marketplace, found an app, and thought, "I have the same problem." There was only one other app on the Marketplace at the time on HubSpot, so I thought, "Let's build it." That's how it started. I looked at the negative reviews of that product. This is something people do in e-commerce all the time. They look at negative reviews and think, "How can I make this better?" I did that. Then I looked at all the reviews of this product, found the images of each person who left a review, reverse image searched, found their LinkedIn, found their email, and emailed them. I said, "Hey, I know you use this product. I'm building a competitor that has XYZ features that are better than what you built." I got like a hundred people signing up before I even built the product. That was the... I built a waitlist essentially. Not everyone converted, but that's five customers you didn't have prior who are testing your app, validating if the idea is good, and potentially giving you money to continue building. That's one way to do it: looking at negative reviews to see if there's anything you can build that's better than what's out there. You can also use a tool called Gum Research, which is a great tool that you can search for all the negative things happening for a product or industry. You can take that information and use it to build products. For the second bit, I'm curious if you have thoughts on this, Jay. The strategy I've always taken for investors, especially if you're an introvert, is if you have great numbers, it doesn't matter. You don't need insane salesmanship. Not that you shouldn't work on it, but go build something awesome that people love and are paying money for. Any smart investor is going to look at the numbers and be like, "I'm in." One of my business partners sold his company on another venture that fizzled out, but he sold his company for like 400 million or something. He was invested. He went the investing route and built another AI app called ATHLEE. AI. He got an investor from Amazon. I asked him, "How do you get investors?" He said, "One, it's about stories. It's the story you can tell." That can be from your numbers or future pacing on what the app will do. A lot of it comes from what you said: investors care about one thing, how quickly they can get their money back. If you didn't plan out the idea enough and don't have a clear vision or story of how that's going to happen, you're not going to find investors. You have to have a good story on how they can make their money back. If you have the numbers that represent that story, it's just going to be easy. It's just a matter of finding the right investors. Not every investor is a good investor for what you're building. That's excellent advice. It's kind of an interesting thing where when you go and raise money, what you said about finding the right investors is so true. Even if you have great numbers, some people just won't see the vision because they're coming from different walks of life. That's fine. Don't get discouraged if you're raising money and people are saying no. That's literally just part of the process. I think what you said about telling a great story is important. Having actual proof in the pudding to back it up just adds credibility. It's really hard to pitch a dream without backing it up. Most of the time, you can go and build something, prove traction, and prove revenue, even in a small way. It's a good proof of work function. If it's true that there's a business opportunity, surely we can build even a fraction of what we want to build and prove it's commercially viable. Time is the most valuable thing anyone's got. If you're going to spend years working on that thing, before you lock into that, at least prove to yourself that this is it. Honestly, with tools like Bolt, there's going to be a world where you don't necessarily need investors. All you need is an audience. I would also say to build an audience, whether that's on TikTok, Instagram, YouTube, Twitter, or X. Building that audience is critical. A lot of companies right now, from a marketing perspective, there's a shift happening where companies are going media first. They have newsletters or podcasts. That's why they're sponsoring all these podcasts and newsletters. Why? Because they know they can get in front of an audience virtually for nothing. If you have an audience that you own, whether that's an email list or YouTube, TikTok, whatever, it's going to be easier to say, "Hey, I have this product. I'm looking for beta testers. Ten people, can you try this out?" Maybe those ten people really like what you're building, and that gives you the validation to keep going. You don't need an investor. The ability to fail fast and test fast is critical. As these tools get better, you have to have an audience. I so agree. We need to have another session where we just talk about how to start businesses because a lot of questions in the chat are about that. Whether to raise money or not, etc. If you'd be up for it, I think it would be fun to do another session where we just talk about this all day. I would love to come back on. Same, man. I'm having fun. This is sick. A lot of people in our company Slack and in the chat here are saying Jay is amazing. I cannot agree more. Your knowledge across everything we've talked about here is incredible. I've enjoyed chatting with you. I'd love to chat even longer. I also want to mention Jay's got a YouTube channel, and I highly recommend following it. Can you maybe get the link up on the screen here too? Appreciate it. I appreciate all the help you've been giving to the community and sharing your knowledge here and on your YouTube channel. It's incredibly high-quality stuff. Yes, there's the link. You can go subscribe, follow, and like Jay's videos. Thank you. We'll have more content coming soon. I just moved to a new place, but we'll have one or two videos a week coming very soon. Amazing. Hell yeah. Cool. Any other questions from the Stack? By the way, before we show a new integration and some community shoutouts before we drop here. No more questions, but just want to add a plus one that we should definitely have you back on. That actually gave me an idea. We've got our user spotlights. I like you got the mug. Hey, is that the "Bolt is my co-founder" one? I wish I could. My camera's over there, but yeah, that is the "Bolt is my co-founder." Let's go. I'm eagerly awaiting that. That's my favorite one, Mauricio, put together. Maybe we even have another series focused on the business of using tools like Bolt and building a business around that. It could be interesting to have little entrepreneur chats. Just an idea I had from this, but I think it makes sense. People that come in, there's a book called "Making Your Users Badass" or something like that. I can't remember. It's a great book. The key takeaway is that folks who use your product, it's not about buying a DSLR just because they're buying a DSLR. They're doing it because they want to take photos. The question is how can you tune your products and experiences to help them accomplish what they're trying to do? With Bolt, we see an incredible number of entrepreneurs using this and people trying to build businesses. I think it would be sick to get some live streams going on that. Hell yeah. |
|
|
|
Video: How To Submit Your Hackathon Build |
|
Hi, this is Michelle from DevPost. I'm going to show you how to submit your project to the world's largest hackathon presented by Bolt. As a quick reminder, the deadline is June 30th, 2025, at 5 p.m. Eastern Time. The submission form will close right at 5 p.m., so be sure to save your project well before that. All right, let's dive in. Once you get onto the hackathon homepage on DevPost at worldslargesthackathon.devpost.com, you'll either have to register or log in. I hope you already are. Then you'll have options to start a new project or edit your existing project. I'll go ahead and create a new one. By doing that, I'll be directed to the project overview, but I can always backtrack and add team members by sending an email to their address or copying this link and sending it to them directly. On the project overview page, you'll want to add the name of your project and a tagline, just a one-liner description. It'll show up on the project gallery like this. Speaking of the project gallery, we also want to make sure it looks appealing, so add a thumbnail. Next up is the project details tab, where you'll share your story, a link, and a few other things that will show up publicly. The first thing is the project story and the built project, which will be all in markdown. You can add images, hyperlinks, and other formatting. In this description, definitely tell the judges how you built it, what you built it with, challenges you ran into, and anything showing proof of your project here. You'll also want to mention if you're going for any of the sponsor challenges or any of the bonus challenges. For more information on all the challenges, there's some information in the resources. There are eight challenges here with different sponsors. There's also a huge prize list, including bonus prizes where you can find the one-shot competition. Next are the "Built With" tags. I'm going to say bolt.new. My tryout link will be public on the project gallery. If you have a public project that you want people to start using, add it here. Next up is the video demo link. Your demo video should be around three minutes, recorded and uploaded to YouTube, and set to public so that the judges can easily view it. The video should showcase how your project works. Next is the additional info. This information will not show up on your project in the project gallery to the public. It's mostly for the judges, the review team, or to collect information for the managers at the end. The first thing is the public project link. It might be duplicated from the first one, but this is the one that the judges should definitely be using. Confirm that your project has the "Built with Bolt.new" badge. This is more of a reminder, but you definitely want to make sure your project, whatever you're linking here, has a bolt.new badge. Then we have the bolt.new project URL. This is the URL that shows up on Bolt when you're building your project. For my project that I built, I just grab the link here and put that in. It's unique to this project, and Bolt can check out the usage there. Next is checking if you're submitting a brand new project. When did you first start creating your project? When did you start building or coding it? This hackathon started on 05-03-25, so any date after that will work. Next up are the challenges you're submitting into. There are eight options here to match up with our eight challenges for the sponsors. If you did any of these, make sure you select them. The next question is providing proof towards the selected challenge. If you select five different challenges here, you've got to prove it here. Next up are the bonus prizes. There are a lot more here than what you can select on the submission form. Most of these are going to be selected by the judges. You don't have to opt in to being the most beautiful UI; the judges will choose that for you during their judging. Everyone's going to be reviewed for those. The next question is asking if you're a team, individual, or organization. This matters more for admin purposes. By myself, I'm an individual. Region: I'm in Canada, so North America. Country: If you have team members, definitely select if you have team members in different countries. These last two don't go to the judges but would be helpful for the admins of this competition. The last step is checking off the terms and then checking out your project. Please make sure your video is playable on DevPost and ensure all the formats still look good. All right, feel free to keep editing your project until the deadline, which is again June 30th, 5 p.m. Eastern Time. It locks in at that point. Best of luck, and have fun! |
|
|
|
Video: How to add a database to your bolt.new app |
|
Bolt is great at building the user interface and logic of your app. But how should you store your app's data? Today, we're going to learn how to integrate Bolt with a free database using a service called Firebase. First of all, if you're not a web developer, you might be wondering, why do we even have to care about the database? Apps built with Bolt can store things somehow, and there's a deploy button that puts my app on the server. Isn't that enough? Well, not exactly. Think of it this way: you often see a tool that you can use as a website, an iPhone, and an Android app at the same time. To make this possible, all these apps need to have access to the same data. That's why a real-life database is usually treated a bit separately from these other pieces. Oftentimes, it's even placed on a different server than our website. So let's get back to our project. This is the app that I've built in the last video: a habit tracker with a dashboard, the habits to tick off on a given day, the ability to add a new one, and finally, a calendar showing my progress. Right now, when I refresh the page, my data still shows up, so it looks like the app is persisting it somehow. But it might be a little bit deceptive. Let me explain. Let's open Chrome Developer Tools to see what's going on. Here in the Application tab, we can go into local storage and find our data right here. To prove it, let's remove these entries and refresh the app. And now our data is gone. Local storage is useful for many things, but it's worth knowing its limitation. It's, well, local. It stores the data in your browser, which means that if you open the same Bolt app on a different laptop, you won't have access to that data. Even if you open it on your original laptop but on a different browser, and even if you're logged into Bolt, you also won't have access to the original data. Instead, let's connect our app to a proper database. For this, I've picked Firebase because it's popular and also offers a lot of interesting features we might explore in future videos. Let me know if there are other solutions I should cover in the future. A cool thing about Firebase is that they have a pretty generous free offering. So if you're just ramping up and initially your app won't have a crazy amount of activity per month, you should fit within the limit with no cost whatsoever. I'll just click "Start Now" and get to the Firebase dashboard. If this is your first time using Firebase, you need to log into a Google account as well. From here, let's create a new project and give it a name. To make this simple, we'll skip the analytics for now and click "Continue." In a couple of seconds, the project is ready, and we can click "Continue" again. Let's pick the No Cost Plan. Here's our project overview. A Firebase project can include multiple databases and other services. From this page, you can add and configure these additional services, create the databases, manage security, and so on. In our case, we'll use this page to get the connection details and create a database. The connection details will tell our application how to reach Firebase. Because we're building a web app, we can get this information by choosing the web option here. Let's pick a descriptive name that will represent our app. Now Firebase provides us with the instructions on how to prepare the code. If you're coding your project by hand, you would have to follow these instructions to the letter, but Bolt only needs the actual config values. So let's just copy that part. We'll use it in a second, but now we should do one more thing: create the actual database. Let's pick Cloud Firestore and click "Create Database." We can leave the default name and location and click "Next." Here's the very important part: setting up the access rules. For the purpose of this video, let's set it to test mode, which will allow anyone to access the data for the next 30 days. Thanks to this, we won't have to deal with authentication and authorization, and we can jump straight into using the database. But we'll need to adjust it eventually, so this will be a topic for the next video. For now, let's click "Create." In a few seconds, we have a fresh, empty database. It's time to move back to Bolt and use it. I'll ask Bolt to store the data in Firestore and give it my Firebase config that I copied a minute ago. Bolt now updates the dependencies to add the Firebase library. It sets up a file with our Firebase configuration and creates the functions for reading and writing to the database. It also updates our habit app components to use these functions. Let's try it and add a new habit. After the app starts, I'll add a workout, and we have a problem. It shows some invalid argument error. Without digging into that, let's see if Bolt can solve it. OK, from what it tells us, it looked like our app was generating an ID for the habit while Firebase expects to create it itself. So that was fixed. Let's try once more. Again, invalid argument. But this might be a different argument, so fix it again, please. Yeah, indeed, this time Firebase wasn't happy about the value we're sending when the description of the habit is empty, and now Bolt modified that logic. So third time's a charm, and success! OK, we validated the habit. Now we can look for that in the Firebase dashboard. Note that when the first set of data, what Firebase calls a collection, is added, it might not update automatically on this page, so you might have to refresh it. Here's our workout entry. Let's try this one more time, add another habit. This time, it automatically updates and shows us a second item in the habits collection. We can even modify it here and see that change reflected in our app. There's one last adjustment that I think we should make here before we wrap up. This is how we start the connection configuration. This information, especially the API key, shouldn't be exposed to anyone, and it's best to make sure it's not even a part of the codebase. That's why it's a good practice to keep this value in a special .env file. If in the future we want to store this project on GitHub, we'll set this file as ignored. In the case of Bolt right now, this specific file is already automatically being removed for anyone viewing your project other than you as the project owner. Now let's add some more data. Oh, and actually, let's double-check that it's not being stored in the local storage anymore, which it's not. Instead, it's nicely persisted in Firebase. Time to deploy it. After the deployment, it's still connecting to the same database, so everything works as it should. I hope this was useful and you've learned a thing or two. Stay tuned for the next one. We'll add authorization, user accounts, logging in and out, and all that necessary stuff. Let me know in the comments what topics you'd like me to cover next. |
|
|
|
Video: Introducing Codeflow - StackBlitz Keynote @ ViteConf 2022 |
|
Hey there, I'm Eric Simons. I'm the co-founder and CEO of StackBlitz. For those of you who might not have heard of StackBlitz before, it's a web-based IDE that allows you to run full-stack JavaScript toolchains entirely inside your browser tab. We've been able to do this because we invented a technology called Web Container, which we launched at Google I/O last year. Web Container is an instant-booting, WebAssembly-based micro-operating system that runs inside your browser tab, making the experience fast and almost magical. We built this because our mission at StackBlitz is to make web development instant. We wanted to solve the problem of having to switch to your local environment when you want to start prototyping a new idea, try out a library, or even do bug reproductions. It takes a lot of time and is painful to set these environments up. StackBlitz has turned this into an instant, one-click process inside your browser. Over the past couple of years, StackBlitz has become popular for lightweight use cases. In the open-source world, it's used for bug reproductions and interactive documentation. It's also been adopted by some of the world's largest companies for rapid prototyping. We realized there's still one place where context switching is rampant: writing production code in local environments. Tools like Vite have made feature development fast, but when urgent bugs need fixing or pull requests need reviewing, the process is cumbersome. We thought it would be great if we could bring the instant booting experience to production workflow use cases. Ideally, we would just clone your exact local environment instantly. This means taking the entire power of your local environment and making it boot instantly, even faster than your local machine. This is a huge challenge because we don't want to lose what's great about local environments: no latency, offline capability, and no per-minute costs. To achieve this, we need to run everything inside your browser tab using your CPU and memory. It has to be better and faster with less latency than your local host. This means running VS Code with all extensions, Node.js, package managers, Git CLI, and an operating system, all in a few megabytes to load in seconds. Cloning and installing dependencies must be substantially faster, like 10 times faster. When we started working on this three years ago, we didn't know if it was possible. It seemed like an engineering dream, but it turned out to be an engineering marvel. It changes your development workflow profoundly, allowing seamless switching between creating and reviewing pull requests and closing issues, keeping you in your flow state. Today, our team is excited to announce StackBlitz CodeFlow. It's a seamless one-click integration with GitHub that gives you instant environments on every pull request. You can create pull requests, close out issues, and run reproductions without context switching in your local environment. It works like a dream. To demonstrate, I'll show you a real task I'm working on for VConf. I need to add a CodeFlow-themed ticket on the VConf.org website. Normally, I'd have to stash my changes and do a whole dance, but now I can just go to the GitHub repo and click the "Start a new PR" button. It creates an instant copy of my local environment inside the browser tab, with the same theme and extensions, already cloned and with dependencies installed. This is a full-stack application running real backend code. Let me break down what happens: it starts a new operating system, clones the repo, installs dependencies, boots Node.js, and runs your DevServer inside your browser tab with VS Code. It's hard to believe this runs in the browser, but it does, even offline. Let's get to work. I need to add the CodeFlow ticket. I'll open it in a new window for true wide development. I need the CodeFlow logo, which I have, and I'll drag it into the project's folder. Then, I'll edit the conference file to add a CodeFlow branding theme. Once done, I'll open a pull request, make a branch called "codeflow-ticket," commit, and push it. I'll assign it to Tomac and create the pull request. Tomac, working on a CSS issue, gets a review request. He uses CodeFlow to review the PR without stashing his work. The environment is launched with his theme, and he can see the project live. He verifies the new icon and comments on the color. Then, he approves and merges the PR. I get a notification that the PR is merged. Tomac left a nice comment about the color. You can see how seamless this experience is. You might wonder how much you can do in this workflow. Let me show you: I'll pull up my local VS Code side by side with CodeFlow. VS Code pioneered intelligence and language services, and we have that running in StackBlitz too. You can hover, right-click, and go to definitions. We also have the Git sidebar and CLI. You can type Git commands in the browser. We've built a Git CLI version that runs entirely on Web Containers. The vibrant extensions ecosystem in VS Code is here too. You can switch themes and use key bindings. StackBlitz is literally VS Code, so you can open it in PWA mode for full key bindings. The delta between StackBlitz and your local environment is effectively zero. It's your local environment inside a browser tab, booting instantly. Being in a browser allows us to take the experience further. For example, you can use Chrome DevTools to debug your backend live. Run your server, open DevTools, and step through your code. It's an absolute dream for debugging. Maintainers, who have the most bug reports, can benefit greatly. We've worked with the V-Core team to solve this problem. You can open a reproduction link, verify the bug, and click "Fix this issue." It starts a new PR, mounts the repo and reproduction, and allows you to fix the issue securely in one click. CodeFlow is designed for repos you own or maintain, but you can also open any repo you want to contribute to. Use PR. New in front of any GitHub URL to turn it into a live environment. For example, open the Vue core repo with PR. New, and it clones and installs it instantly. You can fork, create a patch branch, commit, and push changes easily. I'm excited to announce that PR. New and StackBlitz CodeFlow are now available in public beta. For open-source usage, it's free. For teams, it can eliminate context switching. Head over to StackBlitz.com/CodeFlow for more information. This has been a monumental effort, and I want to thank our engineering team. We're often the first to find bugs in browser engines because we're pushing their limits. Recently, we found a bug in Apple Silicon causing web apps to run slower, and we're working with browser vendors to fix it. Our goal is to make development instant and seamless, much like Figma did for design. On that note, I'm excited to share that Figma has become a strategic investor in StackBlitz. My co-founder and I have been friends with Dylan for over 10 years, and we're inspired by what he and his team did for design. We're excited to have them join our journey in bringing development to the browser. We are hiring! If you're interested in pushing the limits of browser engines and making development instant, visit StackBlitz.com/careers. We want to hear from you. I hope to see you on StackBlitz.com/CodeFlow. If you're into documentation and education, we have one more thing. I'll hand it over to Sylvia for the final update. Hi everyone, I'm Sylvia Vargas, a developer advocate at StackBlitz. I help open-source teams and companies make their documentation sites beautiful and interactive. StackBlitz is popular for embedding projects on documentation sites, blogs, and courses. Recently, Rich Harris used our Web Container API for the SvelteKit tutorial. Our API is in private alpha, but we're working to release it publicly soon. At StackBlitz, we know how to handle documentation and build amazing educational experiences. However, editing content is frustrating because you have to run a local dev server to see changes. This means cloning the repo and running the server, which is draining. There's a workaround: most documentation pages have an "Edit this page on GitHub" button, but the preview doesn't look like your site. This is frustrating for developers and non-technical folks. Wouldn't it be nice to have a real publishing experience? With CodeFlow and our Web Container API, we built something new. Eric mentioned PR. New, a URL that opens any repo. We can use it here. Replace GitHub.com with PR. New, and you'll see Web Publisher. Web Publisher makes editing beautiful. You see the markdown file on the left and a real dev server on the right. Changes update in real time. After writing changes, click "Propose changes," and Web Publisher commits, forks, and prepares a PR template. You can draft a pull request and contribute to docs. Web Publisher works with any framework: Docusaurus, Next.js, Svelte, etc. Try it yourself at ILoveCodeFlow.com. Make a PR and tell us what you think. I'm excited for you to try it out. Let me know your thoughts on Twitter or Discord. Enjoy, and thank you for listening. |
|
|
|
Video: Prompting and tokens explained in 4 Minutes |
|
Ten years ago, the only way to build software was through using an IDE or a code editor, which could be quite daunting. However, in the modern age of 2025, we build software by having a conversation with a chat box. In this video, we will briefly explain what a token is and how it uses a large language model to predict the next token to help you build your website or application. Let me show you a quick example. If I open up ChatGPT and type "Paris is," it will predict the next thing I want to say. Here is a response: "Paris is a lively, bustling city with centuries of art." That's how it works. We can actually speak to Bolt using natural language, and it will build us an app. If I start building something in Bolt, I might paste a prompt like "Build me a cool site." This prompt is broken down into a number of tokens. You can see I have a balance of 115 million tokens remaining. Every piece of information I input into Bolt, and the code that comes out, consumes tokens. How do we know how many tokens it will consume? We can copy the prompt and use a site called Tokenizer. If I paste the prompt there, it shows a token count of 5. Each token has a numerical value and includes spaces. Let's try something else. Let's expand the prompt by clicking the "Enhance Prompt" button. This gives us a more in-depth prompt. If I paste it, the token count is 213. Each represents a different token, broken down by colors. The more in-depth the prompt, the more tokens it uses, but it saves tokens down the line as you build your app with fewer errors. The LLM will have more information to build your application from. When using Bolt, instead of writing a general prompt, imagine you're speaking to an actual developer. Break it down into tasks, context, constraints, and output. For example, "Build a single-page portfolio site." Context: "I'm a UX designer." Constraints: "Black and white only." Output: "Live preview in the style of Apple and Notion." This gives Bolt more information to start building your application. The more information you provide upfront, the better the output will be. Think through your idea: who you are, what you do, the website's objective, your target audience, and the color scheme. Have a conversation with the text box, and you'll get excellent output. Here we go. We have a clean portfolio for a UX designer, with projects, images, skills, expertise, tools, and technologies, following the prompt we gave. When using tokens, remember to use more upfront to guide the outputs better. Follow the framework of task, context, constraints, and output for better apps and advice. Hope you enjoyed this video, and catch you on the next one! |
|
|
|
Video: Use Supabase in your bolt.new app: a 6min guide |
|
If you want your bold app to be anything more than just a cool demo, you probably need to store your data in a database and have some user accounts. Today I'll show you how to use SuperBase to build a quick and scalable application in just a few steps. I'll also explain what the deal is with the security policies and what you have to pay attention to when setting them up. So let's dig in. First, what is SuperBase? In their own words, it's an open source Firebase alternative that provides an industry standard database, authentication, real-time connection, storage, and other cool features. By the way, if you're interested in integrating Firebase with bold, there are two quick tutorials about it on the channel already, so feel free to watch them afterwards. They do explain some different aspects of database storage and authentication than what we'll focus on here. Today we'll work with this notes app that's not connected to any database yet. So let's add authorization and data storage in SuperBase. If the user is not logged in, they shouldn't see the main app UI. Outflow will be based on a username and password. Also, give me the query for creating the database table. Store-sensitiveconfig in the .nb file. Also, let's ask bold if it needs anything from us. This is a pretty elaborate prompt, but I've crafted it while building a lot of these integrations already, and it helps to take care of several possible bumps, which will ultimately save us a lot of time and tokens. This time bold hasn't actually changed anything in our code yet. Instead, it prepared a query that will need to put into SuperBase to set it up properly. The query consists of three areas that are worth some explanation. The better you understand what's happening here, the easier it would be to modify it to your own needs and figure it out in case something goes wrong. First, it will create a notes table, and at least all the properties that will be stored for every note. Even if you're not working specifically with notes in your app, you can expect to see the ID and user ID here. Next, we secure the rows in our table. Doing anything in the row will be forbidden unless we explicitly allow a certain operation under certain conditions. Such certain operation plus certain condition is called a policy, and that's the really important part. Basically, a database can allow creating what's called inserting in the database world, reading, called selecting, updating and deleting. It is crucial to make sure all these policies are defined. For instance, I often seen that there was only the select policy, and in that case, I'd not bought to make sure the policies for editing, deleting, etc. are there. Okay, with that lecture out of the way, we can proceed. Let's copy the query and go to superbase.com. Here, after we create a free account, you'll have to create an organization, any name works, and then a new project. I'll call it notes app. At this point, superbase prepares the project. When the project is ready, the most important piece of information we'll need to bring back to bold will be done here, but we'll revisit that later. First, let's use that query that we've copied from bold. Go to the SQL editor, paste it, and run it. It looks like it worked, so we can now go to the table editor, and see our notes table in here. One last thing I need to do to make our lives a little simpler is to go to authentication and providers, and turn off the confirm email option. Superbase would need us to set an email server for sending these confirmations, which would go a bit beyond the scope of our task today. Now, let's go back to the superbase dashboard, and scroll down to copy the project URL. Now back to bold. Here's the project URL. Back to superbase, to copy the API key, back to bold. Here's your API key, and these are the two things that bold asked of us here. So it's time for bold to work its magic. It installed the superbase library, put the URL and API key in the .nv file, created some viativity functions to work with the database, the UI components for registering and logging in, and some more code to handle starting the notes. We should be good to go. I'll sign up for a new account, and we have no notes. Let's create one about our bold superbase integration, and nothing happens. Ah, we have an error. Let's see what that is. So there's something about the time or date, and such an error might often happen when we integrate one system with another. Probably the date formats are incompatible. Bold should be able to fix that. Yeah, looks like it knows what's doing, it updated the data definition, and fixed how some of the functions deal with the date. And now our note is showing. Let's add another one, another note, and its contents. So now of course we should check if it really shows in the database. In superbase, I'll visit the table editor, enter the notes table, and see our notes. Let's try editing one from here. I'll just change the title, and back in bold. It actually automatically updated. Nice. So that's all for today. I hope this is useful and you've learned a thing or two. Let me know in the comments what other topics you'd like me to cover next. And join me next time when I cover the heavily requested topic of adding payments to your bold app with Stripe. |
|
|
|
Video: World's Largest Hackathon Builder Pack Trailer |
|
I'm sorry, but it seems there is not enough context or content in the provided transcription to clean up. Could you please provide more text or clarify the request? |
|
|
|
Video: World's Largest Hackathon by Bolt |
|
I'm sorry, it seems that the transcription text is incomplete. Could you please provide the full text that needs editing? |
|
|
|
Video: World’s Largest Hackathon Kickoff: Live with Greg Isenberg & Eric Simons |
|
Eric, I can't believe this is happening. The world's largest hackathon, from May 30th to June 30th, a full month of building. It's going to be insane. You can actually build some real stuff during this event. It's not just a one-day affair. We're giving away over a million dollars in prizes, right? Oh yeah, over a million dollars in cash prizes. I think it's one of the biggest prize pools ever. And that's just the prizes. Every participant is getting hundreds or maybe even thousands of dollars in free things, like a free domain name and a whole bunch of other stuff. The prize pool is huge. The first place winner gets $100,000, second place gets $75,000, third place gets $50,000, all the way down to 10th place, which ranges from $100,000 to $10,000 for the top 10. This is meaningful cash that you can actually win. If you have an idea for an app or a startup, this is basically free seed funding. If you win, it's non-dilutive, no equity. It doesn't get better than that. Can you walk me through some of the categories? Yeah, we have the top 10 based on the general ranking of what the judges felt were the coolest apps. There are also regional highlights for America, APAC, Europe, etc. Outside of that, there are fun categories like the most beautiful UI awards, future unicorn for the app likely to be the next billion-dollar company, most viral project, and inspirational story. It's fun because it's not just about the top-ranked stuff; it's also about the people behind them. My take is, of course, the money is attractive. But I think a lot of us are sitting on the sidelines with this whole AI wave. Sometimes you need a forcing function to actually get your hands dirty and learn. Having a 30-day window, you're going to come out way more sophisticated about using AI to build your ideas, right? Absolutely. You're basically getting paid to learn. The tools you're getting are completely free, whereas normally you'd have to spend hundreds of dollars. Plus, you have experts helping and teaching during the event. If you build something amazing, you have the chance to win these large prizes. It's fun to do something with good vibes and intentions, educating folks on how to use AI to build amazing products and tools. I saw that this might be the world's largest hackathon. Is that true? That's what we're shooting for. It's an officially sanctioned Guinness World Record attempt. The current world record is 50,000 people. We haven't even started yet, and 42,000 people have registered. I think we're going to set a world record here. This is like setting history, and AI enables more people to participate than ever before. I'm excited to see how big it could get. I think this hackathon will change the lives of thousands. People will go through this and have light bulb moments, realizing they can build a business, a SaaS, or a mobile app. Those who take it seriously and treat it like a job will benefit greatly. I encourage people to create a hackathon journal to document what they learn each day. That's a great idea. It's such a unique opportunity to savor and take advantage of every moment. The coolest thing will be how it changes the lives of thousands of people. We've got a documentary on this whole AI gold rush, with the hackathon at the center. We're documenting it and posting about these stories to inspire millions of entrepreneurs to build using AI. If someone wants to get involved, what do they need to know? You don't need a background in software. Just head over to hackathon.dev and sign up. It's free. You'll get access to tools like Bolt and Superbase. We have in-person and virtual events you can attend, learning sessions, and meetups. We also have a Discord set up for real-time chat. It's about getting involved and building cool things. I remember doing a Startup Weekend in 2009, and it was a great experience. The IRL component of this hackathon is interesting because you can meet potential co-founders. It's one thing to build by yourself, but another to connect with others in the same boat. Absolutely. The mark of a great hackathon is the startups or co-founder partnerships that begin there. My greatest hope is that folks not only learn how to use these tools but also meet great people who change the trajectory of their lives. I think it's cool that people like Peter Levels and Jason Calacanis will be reviewing your work. It's usually tough to get a hold of these people, so it's an incredible opportunity. For those on the sidelines thinking about applying, Eric might write you a check for $100,000. There's a million dollars in cash and prizes. Every person gets hundreds of dollars in free tools and credits. By the end of this hackathon, you'll be more sophisticated in this new world with tools like Bolt. You'll be a better product person, designer, and AI generalist. The prizes are a great incentive to do the hard work. That's a great point. It's really about learning how to use these tools and make stuff. You could walk out with an actual business. You'll get judges you follow on X to review your work. You might meet your future co-founder and interesting people in your city. The local meetup aspect makes it worth it. The final cherry on top is the spotlight on so many people and their stories through the docuseries and our live streams. It's about giving visibility to amazing people with great ideas, many for the first time. That's what I'm fired up to see. If people want to sign up, where can they go? To sign up, go to hackathon.dev and click register. It will take you to the DevPost page where you can sign up and get ready to rock and roll. How does someone find a local meetup? On hackathon.dev, there's a link to find your local meetup. You can also go to rvr.to/bolt for a full listing of in-person and online events. You can even host your own event. Who do you think will be the youngest and oldest participants in this hackathon? Youngest? Probably around seven years old. Oldest? Maybe 80. It's open to anyone, and it's going to be a lot of fun. You'll learn a lot, maybe make some money, and get free tools. I'm excited to watch what happens. The more people that play with Bolt and tools like this, the better. Thank you for doing this. Heck yeah, thank you for being a great host of the hackathon, Greg. I'm super excited for the docuseries and to see who wins this thing. It's going to be fun. Absolutely, my man. All right, I'll catch you later. Awesome. |
|
|
|
|
|
================================================================================ |
|
# SUMMARY |
|
Total Videos Found: 17 |
|
Successfully Processed: 17 |
|
Total Word Count: 38,770 |
|
Average Words per Video: 2,280 |