DejaVue

Welcome to the second episode of DejaVue - and the first one with a guest! Michael and Alex are joined by Harlan Wilton, an open-source developer from Sydney, Australia who is not only into backpacking and Nuxt.js but also builds amazing tools and applications. Harlan is discussing with Alex and Michael how he built his SaaS Request Indexing in less than a week with Nuxt, which stack he used exactly, what it does and shares tips on how to stay focused and make sure your app actually ships.

The best? The SaaS is open-source!
Tune in for an interesting conversation around using Vue.js and Nuxt.js in the wild.

Post Podcast Update from Harlan

After the recording, Harlan took a break from working on Request Indexing due to other commitments. But there is also a good news - Request Indexing got the first paid monthly users now netting $60 per month. Harlan is also working on a big pivot on it, which will be announced soon. Stay tuned!

Chapters
  • (00:00) - Intro
  • (01:00) - Open-source and backpacking
  • (02:22) - The idea for an open-source SaaS
  • (06:09) - Staying sane while building the app in 64 hours
  • (09:58) - Harlan's Tech Stack to build the SaaS
  • (15:24) - The back-end of Request Indexing
  • (21:32) - Next steps for the SaaS
  • (22:30) - Keeping the scope when building a SaaS
  • (32:37) - Wrapping up


Links and Resources
Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Guest
Harlan Wilton
All things open-source. Helping build Nuxt & UnJS. Mostly Backpacking around.
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Speaker 1:

Everyone. Welcome back. It is Michael Thiessen here, a full time Vue educator, and I'm here with Alex and Arlen.

Speaker 2:

Hey. Yeah. Welcome everybody.

Speaker 3:

Hi.

Speaker 2:

Yes. So, yeah, for everybody not knowing me, Nox team member, as the other guy in the other side of the video or wherever he is, also, yeah, doing a bit of content creation and, a little bit of consultancy with regards to Vue and Nuxt.

Speaker 3:

Yeah. I'll I'll introduce myself since I'm a box in the corner somewhere. Yeah. I'm part of the Nuxt core team. I'm living in Australia.

Speaker 3:

However, I've been traveling for, like, the last 9 months or something. But, yeah, back in Australia at the moment and just hacking away at some random NUCs projects, SAS projects, just whatever interests me in the moment.

Speaker 1:

Yeah. So we wanted to, talk to you specifically about this SaaS hackathon project type thing that you did. But you were, I don't know, living the dream in a way like backpacking and traveling while doing open source. Is that is that correct?

Speaker 3:

Yeah. That's right. I was in a position where, yeah, I was traveling for ages, and I just had a very old, laptop that I still have that is held together with sticky tape. And whenever I have any downtime, it's, it's not good. Whenever I have any downtime, like, you know, in a bus or train somewhere at the hostel and nothing's happening, just whip it out and sort through some issues, work on some projects.

Speaker 3:

Yeah. It was pretty cozy.

Speaker 2:

And you wanna say that you did all of the work on dead laptop. That's how's to get away sticky tape? Did I did I get it right?

Speaker 3:

Yeah. So if anyone is, like, saying, I need a MacBook to, like, I don't know, be a programmer, like, there's things like 4 years, 5 years old. Yeah. Like you can do a lot with a little these days.

Speaker 2:

Amazing. Wow. And not not only that. So you're traveling, you're doing open source, and now you also released an an open source SaaS application. Yeah.

Speaker 2:

Can you can you tell us a little bit more about that? Like, how did that come to your mind, what it is, and why it's an open source SaaS, which is not super common nowadays, but getting a bit more common apparently.

Speaker 3:

Yeah. So, I've spent far too long at this point within the SEO stack. For whatever reason, I think it was because I was working previously as, a contractor. And one of the biggest things for me to do was, hey. We need to drive more traffic to our website.

Speaker 3:

And from a technical standpoint, how can I actually help with that is, okay? I can make the website faster. I can optimize for all these technical SEO details. However, within NUXT 2, that was very painful. So when NUXT 3 came along, I wanted to kind of jump in there and sort this out and make things easier for everyone.

Speaker 3:

So being across this landscape of all these projects going on, I did see, within the last, like, 6 months, there's been heaps of, like, other SAS projects and, one other open source one that popped up around, not gonna say hacking this API from Google, but, basically using it in a way that you're not meant to use it per their documentation. However, everyone else is doing it, and it seems to work. So when I saw, this this script, Google indexing scripts come up on Google, and I think within, like, a week, it had gone from 0 to 5000 stars.

Speaker 2:

Wow.

Speaker 3:

I'm like, oh, okay. People really want this. However, the issue with it is, you have to go and create a Google, Cloud account, and you have to go and create your, IAM permissions and security, credentials, and then add it to your Google Search Console, which is fine for a developer. But, if you don't have a Google Cloud account or you don't wanna mess around for half an hour, Yeah. It'd be nice if there was another way.

Speaker 3:

So, we can just use OAuth to, like, authenticate the user session, and they can get started within, like, a minute. So, yeah, I thought it was, just a fun little problem to solve. And, so this is one side. And the other side is that, there's been, a few indie hackers who have kind of adopted Nuxt, and, they kind of like, hey. Nuxt is so great.

Speaker 3:

Here's my SaaS product I've built with it. One example is, a Pali, which is, social media scheduling. And I think, Headshot Pro, Headshot whatever, by Danny. That one is also Nuxt. Those guys have been amazing in kind of pushing the good word.

Speaker 3:

However, there hasn't really been any open source ones. They've really been kinda telling the NUC story of like, hey. It's pretty easy to get set up, guys. Like, you have everything you need. Just kind of get in there.

Speaker 3:

So I thought I'd I thought I'd tell that story of, yeah, you can make a SaaS. It doesn't take too long. Here's a problem. Yeah.

Speaker 2:

And how long did it take you? Like, that's I think that's a very important point.

Speaker 3:

Yeah. So it took it took in total 64 hours. 64 hours. Cramming, yeah, cramming through a few silly bugs. And I think I actually, opened a bunch of pull requests while I was working on it because, there was a few unstorage APIs I was trying to use that were experimental and, just ran into a few bugs.

Speaker 2:

Crazy.

Speaker 3:

Yeah. This this is the way.

Speaker 1:

One question that I have, which is nontechnical, but the the thing that struck me when you were saying that you you put 64 hours in and this was over, like, 5 days, something like that, like a week.

Speaker 3:

Yeah. Since then I wait.

Speaker 1:

How did you do that without your mind turning to mush? Because I've done some hackathons before and I like, you know, you get super excited and you go all out and by like day 3, I'm like, my brain is just like done and all I can do at that point is, you know, sit on a couch and watch Netflix or something. And like, my brain has has totally given up on me. So so I'm wondering how how you managed to to get through that.

Speaker 3:

Yeah. No. It's it's a great question. I think it's kinda twofold. Firstly, like, I think when some people go into this hackathon mentality, they, like, will put that above every other aspect of their life so they won't be doing their normal routines or habits.

Speaker 3:

So when I, when I was going through it, I was still exercising every day. I was eating healthy, like, meditating daily. Like, there wasn't really too much of a change in my routine minus just, instead of spending a few hours watching YouTube, I was just working. But it also helps that, I didn't have anything social on, and I had no obligations to anyone else. I just had free rein.

Speaker 3:

Yeah. The other side of it is I think if I was doing this every week, it would be quite unsustainable. So I take my my work quite seriously, but then I also take my leisure quite seriously. So Good point. I think yeah.

Speaker 3:

Once once I, like, wrap up this little, next update, like, I'll probably take off a few days of work and just chill out and not really do anything.

Speaker 2:

Yeah.

Speaker 1:

Yeah. That makes sense. Yeah. I think for me, I've noticed that if I don't stick to like this, the same daily routine and like, like you said, exercising and eating right. And, you know, still strength, still trying to sleep properly and and all of that, then it's just like

Speaker 2:

Won't work. Taking those dive. But yeah. That's it for me.

Speaker 3:

It's very hard. Like, I I definitely failed at the sleep aspect, but, at least I could hold on to some, some other of my habits. Yeah. But I I really enjoy the, having kind of, like, a bit of a grind and just getting something out there and being done with it kind of move on in a way.

Speaker 1:

It's like, like a marathon, you know, or it's like you you run a marathon. You're not expecting to run a marathon every week, but it's it's really awesome to be able to push yourself and to say, oh, yeah. I did that. Look at what I'm capable of doing. And so, yeah, it's really neat.

Speaker 2:

Absolutely. Exactly. Now a bit more of a technical question coming to the SaaS. Of course, there will also be linked in the show notes. And also before I ask, what is the name and the URL of your SaaS?

Speaker 2:

I know people will look it up anyway, but just so it's mentioned here.

Speaker 3:

Yep. It's called request indexing.com, which is, the label of the button in Google search console when you wanna tell Google to index your page. It's a bit of a jab at the fact that this even exists because you think Google would be kinda smart enough to just index your pages.

Speaker 2:

So it's let's say it's very descriptive. Like it it couldn't be a better fitting name in scripture wise.

Speaker 3:

Yeah. There might have been some, like, you know, SEO, keyword optimization.

Speaker 2:

Yeah. Okay. But you can always cram that into your, like, meta description and your title anyway.

Speaker 3:

I exactly.

Speaker 2:

Yeah. The the technical question would be, you said, okay, you use Nuxt to build that application in in less than a week in in these, like, super low amount of hours. Could you could you enlighten us a bit more what tax deck you used exactly? Like, I mean, Nox as the base is pretty nice. Like, did you use component library?

Speaker 2:

Did you use some authentication modules? Probably use your own SEO module? So, yeah, bring these on and and tell us all about it.

Speaker 3:

Yeah. Sure. So the most valuable, add on I had there, the UI package I used, Nuxt UI, is just is just such a breeze to use, like, coming from many other UI frameworks. Having one that just kinda integrate so nicely with Nuxt. That sped me up, like, significantly, And it helped a lot that, Sebastian gave me a key for, Nuxt UI Pro, which comes with even more components.

Speaker 3:

So they actually have a SaaS template. It doesn't have a crazy amount of components, but, for, like, building out the landing page, it was really useful. And, yeah, I think that that was definitely the most useful. And the nice part about it as well is everything just kinda looks coherent, and you have a dark mode out of the box. And if if you need to hack it, you can hack it very easily, which, you can't really do as easily with, like, Vuetify.

Speaker 3:

I mean, you definitely can hack it with Vuetify, but, it's, like, maybe 5% less intuitive, I wouldn't I would argue. Besides that, yeah, Nuxt SEO I used, there's not really many pages on the site at the moment. But the og, module og image module is helpful just to get that nice little splash when I shared it on Twitter. And, I used Nuxt, Nuxt AuthUtils for the authentication. This is a library, by Sebastian who kind of built it as an experiment just to, like, test out what APIs we wanna kind of maybe support for the official Nuxt auth module.

Speaker 3:

So I thought it would be a good idea just to kinda play around with it so I could give him some feedback. In retrospect, I think it's, if you're just trying to move fast, it's like missing a couple of things, which kind of slowed me down. But it was still very useful. Like, I only needed Google OAuth. So it's actually quite simple.

Speaker 3:

It's just, you know, send a redirect, handle the redirect when it comes back. In Nitro, we have session storage now. So that makes all of this really simple. Just throw everything into the session, and the user's logged in. And you can persist that session, quite simply just extend the cookie, duration, and you don't really need to worry about anything else.

Speaker 3:

And I think that's about it.

Speaker 2:

Sweet. Yeah.

Speaker 3:

Yeah. I tried to avoid I tried to avoid using any, other APIs really, because I wanted to really showcase what Nuxt itself could do. So I avoided super base purely for that reason.

Speaker 2:

I mean, you you already just mentioned, like, you you technically you said Nuxt UI, which is is based on Tailwind as well. Right? So if you would have even, like, added more time or said, okay, I want it fully handcrafted. You could even roll it on your own, but it's great that Nuxt UI. Nuxt UI Pro gave you a little bit of, a speed up with the components, existing there.

Speaker 2:

And when when it came to authentication, you said you used Nuxt off utils, which is it's a nice choice. And, of of course, I hope you, as you said, you gave some feedback as in what mists to make it even, like, faster, like, more hands on so it can be used. Because especially in in the Nuxt community, you also know that there's this big topic of, oh, when does the Nuxt off module come out? And we always say, like, yeah. We want to provide these lower level building blocks so you can really easily craft in your own, which is also I think what you what you've shown with, with your SaaS.

Speaker 3:

Yeah. I hope we can, make some make some more progress towards that. And I think, yeah, Knoxville's utils is a good stepping stone.

Speaker 1:

One of the things that I noticed when I was, poking around in the code base a little bit was that there's a lot of stuff going on in the backend here. And when I talk with some people, they, they often seem to assume that Nuxt is only really good for front end stuff and you, yeah, you can have a backend, but like, it's only for like really basic stuff. And then really like the best way is to proxy to like some other API solution or whatever else. But that it's really not the case. Like, Nuxt has a whole ton of of stuff you can do with it.

Speaker 1:

And so I noticed you have, like, like you're saying auth, but I noticed there's, like, your persisting analytics with unstorage and, like, doing, you have a a simple crawler that you've implemented with Nuxt and, and a whole bunch of, of these other little, not little, but like more complicated backend things that, that you maybe wouldn't expect Nuxt to be able to do. Do you want to explain more about some of these things and, and what you found building with those?

Speaker 3:

Yeah, it's a, it's a good question. And I would agree that, Knox does have that, that kind of general thought about it is yeah. Just simple APIs are good. And it does stem from, I think other frameworks providing more of a hands on standardized way of handling common back end logic. So if you're coming from, like, Laravel, you'll have, like, a queue system.

Speaker 3:

You'll have all these documented APIs that you are going to be able to use very simply. So Nuxt itself, since it's running within a server, you can, at least the back end, you can do anything that you could do not within node necessarily. If you know how to use the Nuxt APIs, you can do anything you kinda want. I would say that logic within request indexing is quite simple. Maybe not for those who haven't done a lot of complex stuff in the back end before, but I think there's a lot more interesting things we can do.

Speaker 3:

And, I'm actually exploring them at the moment. So one of the things that I didn't do because I couldn't, just didn't have time for it, is I need to ingest all of this data from Google Search Console. However, my app is potentially gonna be running within a edge runtime or a serverless runtime. So I can't actually rely on, you know, a request that's gonna take a few minutes to run as part of, like, when a user logs in. So that's quite, like, an interesting technical question of, like, okay.

Speaker 3:

How do we how do we ingest this data? Do we have to spin up a different server to handle it? So there is a solution there. Like, there's something called, like, message queuing. And, I'm actually exploring maybe making a aux module for it once it's a bit more stable.

Speaker 3:

But you can do anything on the on the Nuxt server, and I I would like to create more of these standardized APIs to make to make it more exciting and interesting. And I think, Nitro task as well will be a big step forward in, making a lot of this stuff easier as well, which if you don't know, is kind of like a kinda like a scheduler or if you want logic to run when you start the app. For example, running some migrations. So there's lots of work, kind of being done around making that experience more robust and hopefully, yeah, make everyone happy and think differently about the Nuxt back end.

Speaker 2:

Yeah. Like, I think these are really good points as in the comparison with Laravel, for example, as someone also coming from Laravel myself years years ago, like, also with, I don't know, Nest. Js, for example, we feel like these are more, like, streamlined when you say, okay, you can do things. There are tons of examples. There are tons of packages already there.

Speaker 2:

And I have the feeling with Nitro relaxes mostly, like, let's say, cookbook with examples saying, oh, hey. This is how you can do it. Or as you said, these, like, more streamlined, packages or helpers just or even even Nitro modules saying, okay. Yeah. If you need a scheduler or like a queue here, just drop that in, use it, and you're good to go.

Speaker 2:

Because functionality like functionality wise, most of these things work already. It's just a matter of how and if you wanna build them yourself or not.

Speaker 3:

Yeah. Exactly. Yeah. And not everyone has the time or capabilities to build it themselves. So I I think it's quite understandable that they reach for these, other APIs.

Speaker 2:

Definitely. But I

Speaker 3:

think other frameworks. So

Speaker 2:

Especially especially in our end, and there's there's quite a bit to do to improve the, let's say, the smoothness in the developer experience just saying, hey. Okay. We can we can provide these things, without running into problem into, like, okay. We have to provide a so general solution that it works for everything again, and then it will take ages to develop. Like, we had the issue with the general auth module again, as I mentioned before.

Speaker 2:

But, yeah, that's I think that's always difficult to balance, but, they're good points. And I think the verdict in the end is that, like, Nuxt and also Nitro are very powerful, can run anywhere, and can do lots of things as you've shown as you're exploring. I'm I'm really curious what will come out there. So definitely keep us in the loop there. And, you probably post a a tweet or have a call it an access as soon as there's something new or just a module will be there out of the blue.

Speaker 2:

So that's awesome.

Speaker 3:

Yeah. I think it'll be it'll be fun to explore.

Speaker 2:

I I really hope so. Yeah. And now that your SaaS is out for for a little bit at least, I I probably yeah. Like you've seen, you've lot a lot of feedback, lots of people using it. Did you did you, if you wanna share that, of course, made any any income, any revenue with with the SaaS so far?

Speaker 3:

Yep. So no money has been made, which I'm not entirely surprised about. I think the the onboarding and the the general use of it is still a bit clunky. So I'll probably spend, like, one more week on it. I'm just cleaning everything up and improving, like, the the flow of this.

Speaker 3:

But I'll probably leave it on autopilot and see what happens. I don't necessarily need to make any money on it as it was just a like a fun little open source project to build. But that would be cool.

Speaker 2:

Absolutely.

Speaker 3:

It's just like a

Speaker 2:

Yeah.

Speaker 3:

It's just like a Stripe, what they call it, payment link at the moment. So I didn't bother building, like, a full on Stripe integration because I thought, you know, if if someone actually wants to pay money for this, if they if they're trying to solve the problem, then they're fine to use a payment link. And I think this is actually, something, you know, important to keep in mind if you're building your own SaaS is, like, you know, not to not to overengineer it, not to build things that you may not need when the idea isn't actually validated yet. And, like, will people pay for this? I don't know.

Speaker 3:

Like, if that's answered and people will pay for it, then I'll spend more time on it.

Speaker 1:

Yep. Yeah. That's a really good point about keeping the scope down. So that's something that's always hard to do. And I I've been trying to get better at this myself, like every, every week, every day trying to think, okay, am I letting the scope on this project just like blow out of proportion?

Speaker 1:

Like what can I rein in? What do I actually need to do? What's not important. So I'd be interested to know, were there things that you plan to do, but you decided not to do? And I guess just in general, how did you think about scoping this down so that you could actually ship something by the end of your 64 hour long week?

Speaker 3:

Yeah. So it it was it was definitely something continuously running through my mind of, like, balancing, like, oh, what can this do? Because I need to make it exciting first. I don't have time to do everything. Let's cut everything back.

Speaker 3:

So I think what helped was really knowing who I was building for. I was building for developers on Twitter who are probably gonna click on it and be like, oh, this is interesting. Maybe I'll sign up and just click around for a bit and then never use it again. That's that's my market. Because that's that was my who I'm gonna announce it to.

Speaker 3:

If I'm gonna post it in other channels, maybe I'll do more work to make the experience slightly better. So one thing that I did cut back on was, originally, I was just gonna let you sign in with your own key so you wouldn't need to go through, my OAuth. I wouldn't have any of your data. So from a privacy point of view, like, amazing because I don't see anything that you're doing. However, the people that actually really care about that, very minuscule probably.

Speaker 3:

So it's it ends up being, like, okay. What am I spending this time on? Who is it for? And while it may look cool and people are like, oh, that's so cool. It's so private.

Speaker 3:

At the end of the day, like, if no one's actually using it, what's the point? And the other one is, yeah, this this ingesting of data, which is a very important feature because Google Search Console will delete your data after, what was it, 16 months. So that's actually quite an annoying problem as well to solve, and I just didn't have the time for it. And, yeah, I don't think people signing up it it's not necessarily a super urgent problem to solve because the data is getting deleted by the day anyway. So if it's, like, a week late, it doesn't really matter.

Speaker 2:

Yeah. Very interesting. I think also, like, good lessons learned as in, like, know your audience, figure out what what they want, or if you say, hey. Okay. Maybe I later on, I will rethink about other audiences and then cater them what they need.

Speaker 2:

And as you said, cut down features that might seem nice from, like, a a developer perspective, but for the end user, it might not be as important as for for the person implementing, let's say. So, yeah, very very good points there.

Speaker 3:

Yeah. How how do you guys generally feel about, like, cutting back on scope? Do you have any, like, methodologies you use or anything you try and remind yourself?

Speaker 1:

I don't know if I have, like, a specific methodology. I I often think about what is important. Like what I think it's important to come back to the end goal that you have in mind. Like you were saying, what is what is the audience here? What am I actually trying to achieve?

Speaker 1:

I find that when I get into the weeds on a, on a project, it's really easy to be like, oh, this button, man, I should have this cool animation to it or the padding isn't that great. But you really need to like step back and be like, okay, is this making this project better? Or should I, you know, fix this auth bug that's preventing people from logging into the thing in the first place. And then it's it's funny because I've been trying to to more now just sort of leave things and say, okay, that's good enough. I want to work on it more.

Speaker 1:

But maybe, maybe I'll come back to it in the future. And then a week later, 2 weeks later, I forget that I even had that desire because, because I've like moved on and now my brain is like ultra focused on like this other weirdly specific thing. And the thing that I was fixated on before, it turns out to not actually be that big of a problem. And, you know, with just with with time, I just forget about these things. And so it's like, don't put all of these tiny little bugs in your backlog because you're gonna forget about them anyway.

Speaker 1:

And the big things keep coming up again and again. I don't use a backlog. I just rely on my brain for the most part, but yeah, that's my, I guess that's my general approach. And I

Speaker 2:

guess also if that, that, like, button style would, like, annoy you, you will come across it again and be, like, the second or the third time, like, okay. Now I really wanna do it because now it it pokes my eyes every now and then. Either you will see it again or it is not that important. Yeah.

Speaker 1:

Well, and there's sometimes things that I wanna do for fun, like, oh, maybe I can add like a nice little drop shadow and an animation and like, I'll take 15 minutes to fiddle with that because it's fun for me and then I'll move on to something more, more valuable, more productive.

Speaker 3:

But I

Speaker 2:

think it's also important, like, especially when working on own stuff, it's always like a nice balance between, okay, you wanna get things done, but you also wanna have, like, some eye catcher or just, like, some some fun things when you play around in a way. But when I think, like I don't know. I I I I've never been someone saying, okay. I want to have everything, like, super polished pixel perfect, which also leads me to a point where I'm like, okay. Functionality is done.

Speaker 2:

Things work, but it's ugly, let's say. And then getting the last 20% for me is always like I'm, like, I'm by no means a designer. Like, I I see if something looks okay or good, but if something looks bad and it's like, okay. What's the problem? It it takes a little bit.

Speaker 2:

So I think that's where where I I just said, like, okay. Let's just ship it. It will work for people. And if if people actually use it, then I will improve in the design. Or somebody else is saying, okay.

Speaker 2:

If design is a certain, like, part of it, then either get some help or, like, then add add a few hours in there. But, yeah, I really try to focus on make it make it work then make it nicer. And maybe in between also make it fast. So yeah.

Speaker 3:

Yeah. I think that's something I struggle with on requesting the x ing actually is I little too much of a perfectionist on, like, how things look. However, in terms of, like, cutting out features, I'm I'm fine to cut things as long as it, like, looks polished and, like, using it as a nice experience. However, that's probably not necessary. It's just, I don't know.

Speaker 3:

Just something I wanna do. You know? It's like, it makes the project more fun for me. And I think at the end of the day, like, if you're not having fun, like, what's the point?

Speaker 2:

Yeah. Big point for sure. Like motivation.

Speaker 3:

At least for like open source work. Right? Yeah.

Speaker 1:

Yeah. Yeah. 1, it's like the the issue is figuring out what what to polish because you want to have polish when you're finishing up a project and gonna ship it out to people. Because first impressions and and how people use it actually matter. And and so I think you did a really good job with request indexing cause it's, you get to the page and there's all these, like, I like the different cards and things you put on there that have like, it's like mock data, but it's like a live UI that gives you a sense of what you're about to sign into.

Speaker 1:

And I think that polish is is really necessary because you cause it draws it draws you in. When I get there, I'm like, oh, this is what it is and I wanna log in and try it out versus if it was just like simple text, this is what it does. I think that's not as compelling. But yeah, it it's tricky to know what, what parts to polish and what parts shouldn't have that polish. And

Speaker 3:

That's that's the, if you're not a designer, the hack is just to throw your components on the homepage with mock data Works every time.

Speaker 2:

And I mean, it's the it's the most honest you can get your users to show. Right? Like, hey. This is how it look like with some fancy data. So they're not like surprises.

Speaker 2:

Oh, I thought it's different. No. No. And you never have to update that because if you update your component, it's also there.

Speaker 3:

Yeah. It's a good time.

Speaker 2:

Alright. I think let's maybe slowly wrap it up. There would like some some really valuable info here. As as usual, you can follow Harlan, on on twitter/ax. On GitHub, of course, as well, all the links will be down there, and, had definitely have a look into request indexing.

Speaker 2:

Harlan, is there anything that's, that's, you think, like, oh, why how could we miss that? How how did you not ask about that? Or anything like, oh, yeah. This this is important. I wanna share that.

Speaker 3:

I think you guys yeah. You did a great job. From, like, a technical stamp standpoint, the project itself isn't too crazy, in terms of complexity. But, yeah, I plan to grow it, and I'll plan to kinda just post about solving some of these architectural issues. So, if if it interests you in terms of, like, the, creating kind of, like, a message queuing system, yeah, just follow my socials and you'll see some updates on

Speaker 1:

that. Awesome. Thanks for chatting with us. Yeah.

Speaker 2:

Thanks for joining. And

Speaker 3:

Yeah. Thanks so much, guys. It was fun.

Speaker 2:

It was it was so much fun. We'll stay tuned for all the updates, and we'll follow-up on that message, Q module for sure.