All right, cool.
We're back with another team training.
We're working on our team here on the call
and we're going to be walking through
just like a retrospective of a particular project we did.
I'm gonna show you the whole process
of how we framed something,
kind of what the client gave us initially,
how we framed it, breadboarded it,
made a task grid, and then kind of show you the end product.
This is a ongoing project that is still got
maybe 40% left to do,
but we've actually delivered the prototype.
We've delivered the first draft of everything to the client.
And now they're just in the process this week and next
of reviewing and giving feedback and fixing some bugs.
So we have a really good pace on the project.
I think like we framed it really well.
And I just thought it would be good to do a top to bottom,
like kind of look through all those steps
of how a real project took place.
And this was a four week project.
So it's a decent size project,
a little bit bigger than we're normally used to.
So let's jump in.
I may also share with Janata here as well,
who's the lead developer on this project.
And let's go through it.
So I'm gonna share my screen here.
And we had, this will be kind of our little agenda
for today.
This is for one of our clients,
building out a SaaS product for electricians.
And so I'm just gonna walk you through
the actual Figma board.
So you can kind of see how this went down.
Now, this is a client that actually gave us
a 20 or 30 page PDF when we started working with them
on everything they wanted.
They had actually sat down in a document
and built the entire project in a document,
which doesn't normally happen.
So when it came to this kind of project page
is what they were calling it,
they wanted this one page where they could see,
a little bit about the project,
like they have things where they have estimates,
they have rooms, invoices, expenses,
and orders all related to a project.
And they wanna kind of see everything in one place.
And so the last few months,
we've been building out things like an estimate tool.
So they have a whole estimate tool
and you'd go to page with a list of estimates
and all the estimates would be there for all projects.
Then we had a room functionality
and you'd go to the rooms tab
and then there'd be a lot of,
place to edit the rooms.
And so now they kind of wanted to re,
kind of, this is sort of the final step
where they wanted to look at it
from the perspective of a single project,
show me everything that's going on with this one project.
And it's kind of tying the entire app together that way.
So the way that it went down is we had this
and we had some initial little existing structure
of how it works.
So you can see we had tabs for each of these things,
you know, inventory, products, estimates,
and you could go to those tabs
and look at specific table of the content there.
So we made some notes here
and then Gennato went in and built this pretty great
first version of a breadboard.
And so we arrived at our first shaping session
with the client or just with Gennato and myself,
and we opened this and my first comment was,
okay, this is great, like where is the framed document?
And so Gennato, I'm not throwing him under the bus,
he did a phenomenal job.
He's like, oh yeah, I just went right into the breadboard.
So this is, I'm just showing you guys like the real,
real talk of like how this went down.
Cause I would say this is an extremely successful project,
but we still like kind of getting our process dialed in.
And it's pretty exciting cause it feels so clear
to just jump right into it
and to jump into like the breadboarding.
And so we've got all of this down here.
So we kind of put a pause on that
and then him and I spent like a whole session
and we kind of came up with this problem outcome appetite.
And you'll see, I'll delete this just for a second here
to actually read it.
This is sort of how we sketched it out.
And so, this is some of the problems.
There's just one view.
They wanted, they needed one view for all the project data.
Product data is scattered across different areas of the app.
And then they want to basically have modules
so they can show this.
So this was a very, like, I would say give this like a D
or like a maybe a 70, you know, ish score.
70% like, well, maybe not.
Let me say this is more like a three or four out of 10 score
of like finished framed projects.
So we sat, this took probably an hour, hour and a half.
And we knew it was going to be four weeks was the appetite
and things we said we weren't doing as a mobile app
which we had talked about with the client
and then specifically mentioned we weren't doing.
So this is a great thing that keeps coming up.
We tend to talk about a lot of things with the client
and then what's helpful with the not doing.
is to show them what we're doing above in the outcome,
but then go and, if we talked about it,
we typically put it on the not doing list
so they're super clear that we're not doing this thing.
Because sometimes it gets lost,
and we've had conversations about a certain thing,
and it's kind of putting all the bad news up front.
So this tends to be very helpful,
because while we were talking about this,
they also mentioned how they have people in the field,
and they want to have a mobile app,
and we just want to be really clear with,
especially when you're working with clients,
or anyone for that matter,
that they don't have this impression that like,
oh, well, we talked about mobile apps,
and now that's just included.
Because we have to be really, really concrete,
and not have anything vague in here
when we said four weeks.
So in a previous video,
I showed you guys the Claude skill of framing.
So you can go back and watch that other one.
So we took all of this,
and we brought it to the repository,
and went back and forth,
and it asked a lot of different questions,
and this is kind of how we ended up
with a much, much better frame.
So this is actually a screenshot from our dashboard,
so I'm gonna flip back here,
and kind of show you, sorry, the, over here.
So we got much more clear about it,
and we have, the way that it comes out here
is working really nicely in our dashboard here,
so we have a good formatting there,
and then, so we said project management
cannot see what's happening with a project.
All project-related data exists in the app,
but it's organized by the type of data,
rather than by the project.
To understand the status of a single project,
users must go to six different dashboards,
mentally filter each screen,
cross-reference information across tabs of memory,
and repeat this process multiple times a day,
because everything they're doing for their jobs
is related to projects.
Data that should drive decisions
sits unused, budget variances go unnoticed,
tasks slip through the cracks,
teams waste a lot of time hunting instead of managing.
So of course, it's kind of summarizing this,
but this clarity came because there's probably
three or four hours worth of me and Jonato's time
drawing squares and rectangles in this,
and then playing with the code,
and then looking back and forth,
and it had to, we had to build this mental structure
in our brains of how this project
was gonna actually come about.
And this, to me, what it really came down to
was we've been working on this project
for almost a year with them,
and this was sort of the cherry on top.
Like this was actually like,
we sort of repositioned this whole project
as a much bigger deal.
It wasn't like, oh, and here's another project.
We're just gonna make a dashboard for projects.
It actually kind of positioned it in our minds
as like, hey, you have to do this.
This is like, this is the missing piece
that's gonna bring all the other pieces together.
And it really, just from like a,
helping cast a vision for the client as well,
it changed how we presented it to the clients
because we had sort of mentally built this frame
in our minds of how important this project actually was.
And then what was great is when we handed this frame
to the Cloud Skill and we reviewed it against the code,
it asked us lots and lots of questions,
and then we went in a few different iterations
to this, and then we actually sat
and kind of reworded a few things just to be extra clear.
So it's just this, like it comes out
and looks so simple and clear.
And even when I started talking about this project
at the beginning of this video,
like you probably didn't know exactly what it was,
but now when you start to read this finished frame,
it's probably like, oh yeah, no, that's exactly it.
So it feels so much more concrete.
And so here's some of the outcome statements.
We just said, you know, we wanna be able to see
the health of a project quickly, you know,
under 30 seconds, you could glance at a dashboard
and kind of see, are we on track?
Are we over or behind schedule?
Budget status is visible.
Task progress is visible.
Critical information is not hidden.
This was something we talked over and over about
because little things get a life in projects.
I'll go all the way back here.
This little mock-up that the project manager
on the client side designed in Excel to show how it works.
And everything that they wanted was in tabs.
And they kept using this word tabs everywhere.
And they would say, you know,
they mentioned it in their requirements doc,
they had the mock-up with tabs,
and we just built it kind of with a tab idea
in the first initial plan.
We had, you know, estimates and room tab, like, you know,
and then we had, let's see, what other tabs did we have?
You get the idea, inventory, order, tab.
So we just threw this word tab in everywhere,
and it kind of got a life.
And that's kind of scary when you're building out
the frame of a project because we did not.
use the word tabs anywhere.
Because once we got into it, the more we got into it,
we're like, you're going to have something
on the third tab on the fourth row down
that's pretty important, and you're not
going to see it because it's buried three clicks away
to get to that.
And we just assumed.
But it took us four or five hours
of being into just the framing and the shaping
to finally pull that piece out of it.
And you can see here we actually put tabs in our initial frame.
And it's just one word, but it all of a sudden
create this little mental model of, no, they asked for tabs.
Obviously, we have to build tabs.
And so it took us getting into it to really push the,
to get clear on it that, hey, one of the big deals
here is we're trying to make this one page
so you don't miss things.
And if we basically go back to tabs,
ironically, we're kind of back to a similar problem
as before, where we had all these tabs.
We had tabs to get to these different things that
were related to the project.
And we've sort of moved those tabs from a vertical list
to a horizontal list and filtered them by the project.
So it is a very logical.
It's one way to do it.
It's just not the best way to do it.
And so when we really pressed into it,
it was all about this visibility thing
and project health being scannable
and having all the data in kind of one location.
And we used this to present this to the client.
And once they kind of saw it, they got a vision for it.
And we never went back on the tab idea again.
Again, look how long the out-of-bounds list is.
These all got surfaced by the Cloud Skill
after our conversation with it and looking at the code.
We wanted to be really clear about, hey,
this is really just a view to get to other places of the app.
We're not going to have the full experience of building out
an estimate in this little project dashboard thing.
You're going to basically, hey, I want to make a new estimate.
You're going to go to the estimate section
now and reuse existing pages.
So we got really clear so the clients knew
exactly what we were going after.
One of the other things we said, there's
a list of projects that happen.
And I'm actually just going to jump into it here.
So I kind of sneak peek there.
There's a list of projects here where it just
lists out all the projects.
And that is something we just said, hey,
we're going to leave that as is.
The list is still there.
But once you click into the project,
that's when this new view takes over.
So we were able to talk through each of these bullet points.
And this is a bit of an exercise.
We do talk through each of these with the client
to explain that they really understand
what they're not getting.
Because so often, they're going to be like,
oh, but we really wanted notifications in there.
Or we wanted this other thing.
And then potentially, that affects
what we can and can't do.
So this is good to just write it out, be extremely clear.
And there was some discussion about whether they
could upload documents.
I think we did end up allowing them to do this at the end.
And there was one thing in here.
I don't think we actually mentioned it.
But we were pretty clear that we would come up
with this view of the dashboard.
And that would be the view.
It's not customizable.
You can't save things.
That was one thing that came up.
I don't know if we actually wrote it out here specifically.
But it was something we definitely
told them verbally on some calls.
It's totally out of scope.
So we went through that.
And then the way that our system works
is this project gets approved.
And then the frame actually gets locked down
so we can't edit it anymore.
Then Janata built out a whole task grid.
So we had a bunch of different things here.
I know we broke the rule a little bit because we
have a few more than nine.
But this is sort of the different sections.
Each component has its own little list of things to do.
And we had some extra stuff.
We actually had time to go in and make
this customizable drag and drop functionality.
And so the way that the project goes,
if I can kind of go back to my list
here, make sure I don't miss anything.
We went through this initial board.
We framed it.
We then did the here.
This was with the Cloud Skill that happened here.
Then we did the task grid and jumped into it.
And this all happened within maybe a span of a week
to 10 days in January.
And then we were able to kick off and actually start
kind of beginning of February.
And looking at the actual time list here,
you can see that's kind of what happened.
We had a start date of the 3rd of February.
And the first block of hours started
coming in around here.
And there's a bunch of pre-work that got done.
I don't know if we really tracked it to this project
or not.
But that all sort of happened on the other side of this.
So we kind of had sign-off right from the beginning of it.
And you can see we have our little log.
here so you can see it got approved on the third was sort of our first date where he said yes this
is this is confirmed. So we went through the project here we did do a little mock-up in v0
oops in v0 here this was helpful to show the client when they saw this they kind of got the
vision for it this idea of like having sections and I think this says six six version six I think
there was more like 10 or 15 of these versions but once we kind of had the idea for how this
was going to work we had like these little sections that would be laid out in sort of
like a grid or like a what's it called like not a mosaic but like the the um a bento box
a layout these are like popular um we showed this to them and then we could show like how
we could isolate numbers and see like charts and all this stuff they got very excited about it
and this was very useful to submit alongside the frame to get that approval it got them really
excited about the project and then where we landed was I'll jump into this test project here
is something like this and we have all the you know different numbers at the top
we have a number of different sections here and when you go into an estimate for example it pulls
up these little cards and they can kind of get to more detailed information from inside here so
if you go to estimates and they hit new estimate they can fill out a few things and then they get
kicked into the new estimate flow which was already existing in the app and so forth they have an
activity you can see like what things have been done this is like a whole little list of things
this was actually I think out of scope but we once we were in here which is something that
Junauda made and it's super cool because you can see like what happened with the project yesterday
what's happening today a little summary of everything and the clients absolutely love that
seeing each room so like this this project has like a bathroom bathroom two bedroom one bedroom
two and you can click into a room here and see what's going on you know with this hypothetical
little project here so pretty cool and the clients love this and then of course we because we're sort
of like ahead of schedule let me just look at this so we're kind of sitting here on the 19th is
when we're recording this we've really delivered most of the functionality and we still have like
a solid week or two to go so even with that we were able to build out this little cool functionality
where you can hit the edit button and you can actually move these blocks around and then save
your you know your new view for that users of kind of how you want to see a project so that was
that was just an incredible cool feature there that just made it like a even better for them
so we showed it the client here in the timeline we showed them on the 16th I believe or the 17th I
think is the Tuesday demoed it they actually reviewed it for two days and they just sent us
like a whole list of like items that they noticed either were bugs or things that are being presented
as a bug but they're kind of like a small feature we know what those look like and again with the
margin we have two full weeks to go and make this look really great one thing that we've just been
fighting for like because this is a four-week project we 100 have to be done with this thing
on the 20th this means they've gone through like two or three rounds of fixes on it what we don't
want to do is we kind of deliver this first version in the to the client like the last few days they
have a day or two to look at it and then really what happens is we end up with this like massive
list of reactive work in March for this this project and now we're kind of cleaning up March
for stuff that should have happened you know in February and so these are you know that we want
to kind of tighten up and we're doing a lot of things to make sure that this was a very clear
project right up front and I think we cut back a ton of cost with this because we massively simplified
the output here where we just said let's do everything on one screen and we didn't have all
these tabs to worry about and we can have these little modals that pop up it we just kind of made
everything smaller because we didn't have to like design as much for these little modals versus
an entire tab that would take up the entire screen so little little changes but actually
made like a huge difference to the project here so yeah very very cool let me see if I had anything
else yeah we said we delivered and we're just wrapping up the bug fixes here so any questions
comments from the team I'd love to like if you guys have questions Lu Chen or Chris or Janata
if you want to comment on anything you were obviously involved heavily let's like do a
little bit of discussion about this or the process and get from there
Yeah, sure. I just adding my two cents to the conversation. I believe like we have been
discussing this, this idea a lot of having on one side that a preview where we do the
framing, we do the shaping and a lot of this is the human side of the work and basically
to better understand the customer and how to present this in a better way for them.
And I think this process, we are getting better at it each day. But yeah, this is actually
what I'm looking now, Bruce. He has the FigJam open, I think he will share this screen. But
I think we are getting, yeah, exactly this one, like we are getting better each day at
the first part so that the second part becomes the more, I want to use the word like the
more delightful as possible. Because I think working with AI can be very frustrating in
the sense of like, sometimes if you are hitting your head against the wall, like, why don't
you do what I want and stuff like that, we can really easily enter into this mode. But
I think the whole first part really helps in terms of breaking it down for the agentic
workflow. And especially for this project, and I think this project had one very interesting
characteristic, that we had many components, and none of them were related. So basically,
the bulk of the work was done in parallel, meaning I broke the project down into small
components, meaning the estimates component, the orders components, and each component
had its own .MD plan for me to implement. But when I triggered the implementation, I
triggered for all plans simultaneously, meaning that all agents were working on the feature
like I had one agent for each component work on the feature simultaneously. And since the
features were not interceding with each other, all of the agents ran smoothly. So I could
test by the end of the process. Of course, this was not like perfect. And a lot of agents
got stuck in some points. But this talks a lot about this changing this view, where we
are not exactly maintaining the code directly, but we maintain the agents that maintain the
code. And we need these agents to be as well directed, and also have access as the tools
they need. So one example, if you allow one agent to be able to open your Chrome, screenshot
the page it's doing and go back to the to the workboard, let's say, we increase our
chances of by the end of the work of this agent, that you have built a interface that
is nice, because we added the capacity for these agents to screenshot its own work and
look at it and evaluate. So I think there's a lot of progress to be made in the sense
of thinking, how do I make this agent as capable as possible? But also, how do I implement
as much guardrails as possible? So this agent works like a train, it's working on this,
it's a locomotive, like it's we have the trails, and it's working on the right trails. And
our function as a developer now is to more or less to maintain the trails and maintain
the train, keep it running, and keep it flowing smoothly. And especially, don't let it run
over the city. So you don't want for because this is a very specific train that can also
make some form of decision making and build itself. So you don't want this to happen like
you don't want it to, you don't want an agent working on top of the other and stuff like
that. So yeah, I think more or less, this is a comprehensive view of like, what was the flow of
development?
That's good. I think. And also, I mean, technically, there's some things you can get
into. Like, we've used Git, like work trees as well, to be in the same branch and then have
like, each agent has its own tree, essentially, and then you kind of bring it all back
together. There's there's some we can get into that. There's some cool things there.
I also, I mean, what's also worth saying in this retrospective thing is that,
um, looking at the frame here and looking at kind of the finished, uh, product,
even, um, this was like, this type of view was obviously like this type of
project made for, for agentic coding.
There's a very, uh, other than this whole, like, you know, the reordering,
there's some customization there, but these it's referencing concepts
that are already in the code.
Um, and so it can go and reference how product, you know, looks how like
order stats, you know, these are things that you can go and everybody
has concepts for this in the app.
Um, so it is a great example of how we could use it.
Obviously we have, I have other projects, uh, working on with, with Greg and
other people this week that are just, just so complicated and there's so much
new content and there's so much new concepts that you have to put together.
But this is a good example.
So I just, I just want to mention that not to say like, Oh, well, no
wonder we're ahead of schedule.
And it's so easy because this is an easy project.
Um, it kind of became easy after a lot of like thinking and, you know,
diving into it and putting a lot of thought into the finished product.
Um, first, just like jumping in and having Claude sort of
put the structure together.
Uh, it was easy for Claude, like I said, to execute on these
individual components and tasks for the, yeah, for the frame, like this thing,
any, anything we, Alex, maybe on the process of the project, um, I think
like the agentic pieces is good.
And we basically breaking up like each slice to kind of run it simultaneously.
Um, and I've kind of like treated, even if you don't run, so if you're
like, Oh wow, running multiple parallel, uh, agents all at once sounds
intimidating, um, if you kind of break things up by like the slices, if you
take each one of these and kind of run that to me as like a work session, like
I can, you can pretty much rip through an entire slice in one, two or three
hours session and just kind of work through that it goes very, very quickly.
Um, So where, you know, this is a technically a four week project, but
it's, uh, it's a number of, you know, sort of deep work sessions to get, get
each one done and some of them will go very, very quickly.
Um, and this is a great case because you kind of have this one container of a.
Component.
And then you had lots of different types of components that were all very
easily able to reference the code itself.
So that kind of makes good sense to have like multiple running at the same time.
Um, I have done like two or three running at the same time.
If you work on different parts of the app, because a lot of the time, if you
guys have found that you're doing this coding, you just sit and waiting for
like two or three minutes to like it to crank through a bunch of stuff and you
get bored, so you start clicking through the app and you're like, Oh,
why is this bug still happening?
And so you've got to go on like another rabbit trail, at least when
I'm working on the dashboard.
Um, I, that's constantly how I do it.
So I ended up like making a few like, but smaller tasks kind of around
while the main task is working.
Or the other thing you can do is put it in plan mode.
So you could have two or three plan mode on, uh, running together.
So you're like planning different things altogether and then it's
building the, the execution plan.
And then you just kind of like execute, execute, execute.
Um, if you want to be safe, you can like execute, like build
all the plans at the same time.
And then kind of just build the first one, get it done, commit
that code, build a second commit.
So you kind of like queue them all up and then just like fire away.
Um, you can get, you can get a lot of work done very quickly.
So it's, I'm just, I'm giving you sort of like some, some baby steps to get
it to maybe what Jonathan was saying, if that sounds insane, but, um, there we go.
I think, yeah, the other thing with this is, um, like, um, this
is fresh cause I, we, I was shaping and doing all this process again
with, with Greg, uh, earlier this week.
And so, um, one thing is that we've also, I told him yesterday.
It's like, I don't think anyone here is doing any of this process solo.
Um, so like the framing, you know, we're getting stuff from the client.
We're framing stuff.
We're coming back doing like an internal team, um, uh, you know, review, then
we're going to kind of like a second phase at the, as at the breadboard.
Then we do another thing and we stick it through Claude and we're
kind of doing it all together.
And I think, um, I heard, I think it was Jason Freed made a great comment
is like the reason you need a second person is because you need someone
to kind of like pull on the thought process and kind of argue with you a
little bit, because that's the one thing like AI is not going to really do.
They're going to be like, you're absolutely right.
Like you're phenomenal.
Like just, it's going to keep just telling you that you're doing a great job.
Whereas as humans, we kind of keep this context window of like, um, you know,
and in one, just one with Greg, like Janata spent way more time in the Xdeck
code, uh, Greg has spent more time in this other project and I was kind of
coming in just to help put the system together, so there was like these
little nuances.
that you know about once you're kind of familiar with the code itself, that when you start to
frame it or think of how this new thing's going to fit in, you just don't have that context.
So there's a good tug of war going on between two different thoughts. And then you throw AI
in there to basically just make sure we're keeping to the process is really great. So those little
framing skills would be great. I think we're going to make a new shape up task grid skill as well
that can take that. Maybe it can use the Innovo dashboard API and just load them into the project
for us would be great. And then read them out of there when they're ready. That'd be really easy.
To help keep us on task with this, when you go into a new project, this one's a little bit
done after the fact, but there'll be a short list of things in a slice called admin and strategy.
So just random things that we need to do here. We need to email the client and we need to get
approval from the budget and we need to make sure we build the task grid. This is just like help keep
us a little checklist on kind of the rest of the project. So you'll see this little slice show up
on all new projects. If a project was made before last week, it doesn't have it, but you can easily
make one. But now when we start a new project, there'll be this little admin strategy slice
that gets added automatically. I don't think it follows exactly this, but it's
something similar to this where we will make sure all the things are connected,
the framing doc is set, we build up a task grid, actually get approval on the budget,
things like that. Just little hit list. If we think of something like, oh, I got to email the client
and ask them that question and you want to track it somewhere, this is a great little spot to keep
it there. Or I need to remember to actually send a video review of where we're at in this process.
That's also super helpful. So that'll be in there. And we'll continue to change that checklist
as we go through it. I will say also on the feedback of this task grid from a client standpoint,
this is a, it looks like there's a lot going on. This is about the easiest way I've ever seen in
the last 16 years of doing development projects to show a client what's going on. Because you can
see like major sections of the project being completed. And with a little bit of percentage
up here, just anyone could look at this and kind of look at the big headlines and kind of skim it
and kind of get a sense of where we're at. I just haven't seen like any other Kanban board or
anything else match this. So this would be something to just make sure we're keeping up with
at the end of each session. For my workflow, I have this up and VS Code and I just constantly
toggling between them. And as I think of tasks, I'm adding them, I'm marking them complete, and I
keep it kind of updated live. So as soon as we get the MCP working from Claude, then you can just
have it update the tasks for you. But just don't throw these all in the task and then go off and
do the project and come back. Because there's a reason there's like rewrite stuff down. Because we
just assume that we're not going to remember things. Same thing, you know, I'm just built like
trying to steal all the best practices and some good habits I learned getting my pilot's license.
Is that no one, even if you've been flying for like two decades, you still have your little checklist.
Because people just forget stuff. And the best, the way to make sure you're absolutely perfect
every time and don't miss things, is just to assume that you're not going to remember these
things and keep them all in your head. So it's a great way to do that. So any other questions,
thoughts? I know we'll wrap up in a minute here. That's good stuff.
Yeah, outstanding work. Yeah, awesome. Well done. Well done. Sweet. I think a couple
takeaways for us was just like, for the team, like keeping, getting, trying to get to like
something that we can demo or put in the client's hands around the 50 to 60% mark,
70% mark of the budget. Much easier, I know, when there's like a four-week budget than if you've
got like a one-week project and you're two days in, you're trying to show the client something
that I know that's hard. But at least keeping like the updates flowing, at least letting them
see stuff early on. One great trick we did with this project was actually prototype the front end
and get them to see it before we hooked up the back end. Of course, those types of little tricks
are great. They can see it in their app. They can see how all things connect. And then we spend
another step just like making stuff functional because we don't want to go too far down. So just
those regular quick updates is very helpful. It gives clients peace of mind because we're in it
and we're seeing everything happen so fast, we get excited. So capture some of that excitement,
like send it on over to the client. Like if you got a little cool screenshot to show,
that's always great. You can drop it in Notion or drop it in Slack, whatever.
and those go a long way.
It just keeps the excitement level up and the focus
and as you're making progress,
there's always probably something you could show for that.
So all good stuff.
And we'll figure out a good,
there's a couple other trainings we wanna do in the future.
One was maybe a longer, maybe an hour or two session
where we do go from zero to one
of setting up an entire new project,
just starting something from scratch.
So if you wanted to go do a side project,
how would you go from a concept to quickly shaping something
up to get it deployed?
Where do you host it?
How do you set up Stripe to get billing?
There's something you can do in an hour or two
to just get the bones of something up
and then you can go and fill out marketing
and you can fill out all the features
and all the other stuff.
So there's kind of like getting the framework
of something up.
I think we can help out with that
in like a one to two hour live build session
and maybe if you guys have projects,
we can do those alongside us and kind of keep,
do kind of a real time build of something.
And then I've been sort of watching a lot
of what Janata is doing and we'll kind of show some things
on the process side and then we've got some cool tools
potentially coming to where you guys could
maybe use some really cool tech stuff
that he's been building somewhere
between all these other projects he's doing.
I don't know when he had time for that,
but so good stuff, yeah.
Awesome guys, I'm gonna end the stream
and we can chat for a few minutes if you want.