[00:00] (0.16s)
Many of you are already familiar with
[00:02] (2.08s)
the growing number of noode and
[00:04] (4.00s)
promptbased app builders that can
[00:05] (5.92s)
generate full stack applications with
[00:08] (8.08s)
very little effort. Platforms like
[00:09] (9.68s)
Lovable, Bolt, new, and V0ero from
[00:12] (12.48s)
Versel are strong examples of tools that
[00:14] (14.88s)
fall into this category and are designed
[00:16] (16.88s)
to simplify the process of building
[00:18] (18.80s)
modern web applications. However, one
[00:21] (21.04s)
area where many of these tools still
[00:22] (22.88s)
tend to fall short is in back-end
[00:24] (24.72s)
development. Some of you might point out
[00:26] (26.24s)
that Lovable is a full stack solution
[00:28] (28.24s)
and does include back-end support and
[00:30] (30.16s)
you would be absolutely right. It relies
[00:32] (32.00s)
on Superbase to handle the back end.
[00:33] (33.84s)
However, when it comes to building with
[00:35] (35.44s)
AI models, Superbase is not always the
[00:38] (38.00s)
most seamless option. I believe that
[00:40] (40.00s)
Convex is currently the best back-end
[00:42] (42.24s)
solution available for this kind of
[00:44] (44.00s)
development. I will go into more detail
[00:45] (45.92s)
later in the video, but Convex recently
[00:48] (48.00s)
released a new tool about 3 weeks ago.
[00:50] (50.16s)
While it is no longer brand new, it is
[00:52] (52.08s)
surprising how little attention it has
[00:54] (54.00s)
received considering how powerful and
[00:55] (55.92s)
efficient it is. I tried it out myself
[00:58] (58.08s)
and was genuinely impressed with how
[01:00] (60.00s)
quickly it sets up a complete backend,
[01:02] (62.16s)
especially when used in combination with
[01:04] (64.32s)
other integrations in the Convex
[01:06] (66.00s)
ecosystem. In this video, I am going to
[01:08] (68.08s)
give you a complete walkthrough of Chef
[01:09] (69.92s)
and highlight its key features. I will
[01:11] (71.92s)
start by showing you a pre-built
[01:13] (73.52s)
application that I created using the
[01:15] (75.28s)
platform and then I will go ahead and
[01:16] (76.88s)
build a brand new app from scratch so
[01:18] (78.80s)
that you can see how the tool performs
[01:20] (80.56s)
in a real world context. Let's get
[01:22] (82.40s)
started. This is the application that I
[01:24] (84.64s)
built and it functions as a splitwise
[01:26] (86.88s)
clone. It was not my first attempt
[01:28] (88.88s)
because the initial version I tried did
[01:31] (91.04s)
not turn out the way I wanted. The
[01:32] (92.88s)
problem was that the default prompt chef
[01:35] (95.04s)
used lacked enough detail which led to
[01:37] (97.28s)
an app that was missing several
[01:38] (98.96s)
important features and didn't function
[01:40] (100.72s)
the way it should have. I have said this
[01:42] (102.56s)
before and it remains true. AI tools
[01:45] (105.04s)
require a strong and well ststructured
[01:47] (107.12s)
prompt right at the beginning of the
[01:49] (109.04s)
process. If you try to introduce a major
[01:51] (111.52s)
feature later on, it becomes
[01:53] (113.28s)
significantly harder to implement and
[01:55] (115.44s)
the chances of something breaking
[01:57] (117.36s)
increase rapidly. That is why I decided
[01:59] (119.60s)
to try again. this time using a much
[02:02] (122.08s)
more comprehensive and thoughtfully
[02:03] (123.92s)
written prompt and the result was this
[02:06] (126.08s)
much more complete and functional
[02:07] (127.92s)
version of the app. You can see the app
[02:09] (129.76s)
running on my screen. It includes a
[02:11] (131.84s)
working signup page and it even allows
[02:14] (134.32s)
you to log in anonymously which is a
[02:16] (136.64s)
feature I personally find quite useful.
[02:19] (139.12s)
This means that the backend is already
[02:21] (141.04s)
set up with user authentication
[02:22] (142.84s)
capabilities. I will go ahead and sign
[02:24] (144.88s)
in so you can see how it works. Once
[02:26] (146.80s)
logged in, there is an option to create
[02:29] (149.04s)
a new group. And for this demo, I'll
[02:30] (150.96s)
name the group friends. After creating
[02:33] (153.28s)
the group, we are brought into the main
[02:35] (155.20s)
group interface, which looks clean and
[02:37] (157.28s)
welldesigned. If I open the convex
[02:39] (159.36s)
database in the background, you will
[02:41] (161.20s)
notice that the backend has been set up
[02:43] (163.20s)
completely. All the necessary tables
[02:45] (165.20s)
have been created and Chef has already
[02:47] (167.52s)
generated the appropriate schemas. When
[02:49] (169.68s)
we look inside the groups table, we can
[02:51] (171.76s)
see that the friends group has been
[02:53] (173.44s)
successfully added. If you notice that
[02:55] (175.36s)
it appears twice, the reason is that I
[02:58] (178.16s)
had previously logged in anonymously
[03:00] (180.00s)
while testing the app which resulted in
[03:02] (182.00s)
duplicate entries during earlier
[03:03] (183.76s)
sessions. Now I will add a new member to
[03:06] (186.16s)
the group. There are two options
[03:07] (187.76s)
available. Either add a member using
[03:09] (189.84s)
their email address or add someone who
[03:12] (192.08s)
is not yet registered on the platform. I
[03:14] (194.40s)
added the second option myself so that I
[03:16] (196.72s)
could test the app quickly without
[03:18] (198.48s)
needing to go through the full signup
[03:20] (200.32s)
flow every time. As I scroll down the
[03:22] (202.56s)
page, you can see the section that
[03:24] (204.48s)
displays all group members expenses and
[03:27] (207.60s)
their individual balances. I am going to
[03:29] (209.84s)
record a new expense titled sports items
[03:33] (213.20s)
with an amount of $100 and I will mark
[03:36] (216.16s)
myself as the one who paid for it. The
[03:38] (218.72s)
expense is recorded immediately. And as
[03:41] (221.04s)
we continue to scroll, you can see that
[03:43] (223.12s)
it now appears in the list below. Next,
[03:45] (225.52s)
I will record a payment within the same
[03:47] (227.44s)
group. Let us say Alex paid me $50. The
[03:50] (230.72s)
system captures the payment correctly
[03:52] (232.80s)
and both the expense and the payment are
[03:55] (235.12s)
now visible in the group's activity
[03:56] (236.96s)
history. I also want to mention that I
[03:58] (238.96s)
built this app in a single run using
[04:01] (241.28s)
only one prompt without making any
[04:03] (243.28s)
further modifications afterward. You can
[04:05] (245.36s)
see that reflected in the output here.
[04:07] (247.52s)
However, the member balances currently
[04:09] (249.52s)
seem a little inaccurate which suggests
[04:11] (251.44s)
that I need to make some adjustments to
[04:13] (253.28s)
fix those calculations. If you're
[04:15] (255.28s)
enjoying the video, I'd really
[04:16] (256.80s)
appreciate it if you could subscribe to
[04:18] (258.56s)
the channel. We're aiming to reach
[04:20] (260.20s)
25,000 subscribers by the end of this
[04:22] (262.64s)
month, and your support genuinely helps.
[04:24] (264.96s)
We share videos like this three times a
[04:27] (267.04s)
week, so there is always something new
[04:28] (268.72s)
and useful for you to explore. I was in
[04:30] (270.96s)
the middle of editing my project when I
[04:32] (272.96s)
ran out of tokens, and the interface
[04:34] (274.96s)
immediately displayed the limit message.
[04:37] (277.04s)
As you can see here, I've completely
[04:39] (279.04s)
used up all the tokens that were
[04:40] (280.80s)
available on my account. If you scroll
[04:42] (282.88s)
down to the section labeled API keys,
[04:45] (285.52s)
you'll notice that there's an option to
[04:47] (287.20s)
add your own key. And that's exactly
[04:49] (289.36s)
what I did by entering my Anthropic API
[04:52] (292.00s)
key. Regarding the pricing, the only
[04:54] (294.24s)
plan I currently see available is priced
[04:56] (296.88s)
at $25. And it does not seem like there
[04:59] (299.84s)
are any alternative pricing options
[05:01] (301.76s)
being offered at the moment. I gave the
[05:03] (303.84s)
prompt another try and it looks like the
[05:06] (306.16s)
issue has been resolved. This time the
[05:08] (308.80s)
system used claude and now all the
[05:11] (311.04s)
member balances are accurate and evenly
[05:13] (313.36s)
distributed exactly the way they should
[05:15] (315.52s)
be. To test things further, I added a
[05:17] (317.84s)
new expense titled dinner and set the
[05:20] (320.24s)
amount to $100, which I marked as paid
[05:23] (323.04s)
by me. The expense was added immediately
[05:25] (325.44s)
and the net balance updated correctly.
[05:27] (327.84s)
At this point, Alex owes the creator
[05:30] (330.40s)
$50. To make sure the payment system is
[05:32] (332.88s)
working as expected, I recorded that
[05:35] (335.04s)
payment where Alex pays the creator $50.
[05:38] (338.32s)
Once the payment was logged, the balance
[05:40] (340.32s)
adjusted and returned to zero. If you
[05:42] (342.88s)
scroll down through the interface, you
[05:44] (344.88s)
can clearly see that all the charges and
[05:46] (346.96s)
payments are displayed accurately. The
[05:48] (348.96s)
reprompting worked exactly as intended.
[05:51] (351.28s)
There's also the option to sign out at
[05:53] (353.04s)
any time, which adds a nice finishing
[05:55] (355.20s)
touch. Overall, I think this was a
[05:57] (357.60s)
strong attempt at replicating the
[05:59] (359.44s)
functionality of Splitwise. The app is
[06:01] (361.84s)
fully deployable and the source code is
[06:04] (364.16s)
also available for download, which makes
[06:06] (366.32s)
it easy to reuse or build upon. However,
[06:08] (368.96s)
there was one thing that stood out as a
[06:10] (370.72s)
drawback. The platform does not
[06:12] (372.72s)
currently support images in the prompt,
[06:15] (375.04s)
meaning you can only rely on text
[06:16] (376.96s)
instructions. This becomes a major
[06:19] (379.04s)
limitation when you need to address UI
[06:21] (381.28s)
issues. For instance, in an earlier
[06:23] (383.44s)
version of this same app, I had to
[06:25] (385.52s)
manually tweak the layout after
[06:27] (387.36s)
generating certain components. Because
[06:29] (389.28s)
the initial prompt lacked visual
[06:31] (391.04s)
reference, the resulting interface
[06:32] (392.88s)
looked inconsistent. The theme did not
[06:35] (395.04s)
match across different parts of the app,
[06:37] (397.04s)
and trying to describe all the necessary
[06:39] (399.20s)
adjustments using only text became
[06:41] (401.52s)
tedious and timeconuming. I couldn't
[06:43] (403.92s)
upload screenshots or mock-ups to
[06:45] (405.84s)
clarify what I wanted, which made the
[06:47] (407.76s)
process unnecessarily difficult. That
[06:49] (409.92s)
part of the experience was definitely
[06:51] (411.52s)
frustrating. However, setting that
[06:53] (413.60s)
aside, I have to say that the built-in
[06:55] (415.60s)
database integration is genuinely
[06:57] (417.60s)
impressive and makes a strong case for
[06:59] (419.52s)
using this tool in realworld projects.
[07:01] (421.84s)
The first prompt I used was actually one
[07:03] (423.84s)
of the available presets designed to
[07:06] (426.00s)
generate a splitwise style application
[07:08] (428.40s)
automatically. I had to make a few
[07:10] (430.16s)
adjustments to the prompt to get it
[07:11] (431.76s)
working properly, but the foundation was
[07:14] (434.00s)
already there. After working with that,
[07:16] (436.24s)
I started thinking it might be more
[07:17] (437.92s)
interesting to try building something
[07:19] (439.68s)
completely new from scratch. Right now,
[07:22] (442.08s)
I'm working on a new idea and have given
[07:24] (444.32s)
it a prompt to build a tool rental
[07:26] (446.24s)
platform that I'm calling neighbor gear.
[07:28] (448.72s)
I came up with the concept while
[07:30] (450.40s)
brainstorming with chat GPT. And once
[07:32] (452.64s)
the idea was clear, I provided the full
[07:35] (455.12s)
prompt directly into the builder. As you
[07:37] (457.52s)
can see, the system has already started
[07:39] (459.68s)
generating the application based on the
[07:41] (461.84s)
instructions I gave. I'll fast forward
[07:44] (464.08s)
to the point where the app is fully
[07:45] (465.84s)
generated so I can show you the preview
[07:48] (468.16s)
and walk through what it came up with.
[07:50] (470.08s)
While the app is being built, I want to
[07:51] (471.92s)
take a moment to explain why this entire
[07:54] (474.16s)
process is so powerful. The backend that
[07:56] (476.40s)
Chef generates is actually written in
[07:58] (478.48s)
React using TypeScript, which brings the
[08:00] (480.80s)
advantage of type safety to your
[08:02] (482.64s)
application. If you've noticed the type
[08:04] (484.56s)
checks running during the build process,
[08:06] (486.72s)
those are responsible for ensuring that
[08:08] (488.88s)
everything functions correctly and
[08:10] (490.64s)
consistently. The reason this approach
[08:12] (492.48s)
is referred to as a backend for AI is
[08:14] (494.72s)
because the majority of code that AI
[08:16] (496.88s)
models have been trained on comes from
[08:19] (499.12s)
React and TypeScript. These models are
[08:21] (501.44s)
extremely familiar with this structure,
[08:23] (503.44s)
which means they perform exceptionally
[08:25] (505.20s)
well when building frontends. Since
[08:27] (507.20s)
Convex also uses TypeScript on the back
[08:29] (509.52s)
end, the AI has no trouble understanding
[08:31] (511.92s)
the codebase. It can make changes,
[08:34] (514.08s)
introduce new functionality, and extend
[08:36] (516.32s)
features with a high degree of accuracy
[08:38] (518.40s)
and very few errors. This is exactly
[08:40] (520.72s)
what makes Chef such an effective tool.
[08:42] (522.80s)
As it builds your front-end interface,
[08:44] (524.88s)
it is simultaneously generating a fully
[08:47] (527.20s)
functional backend in React. If you
[08:49] (529.12s)
decide to download the code, you can run
[08:51] (531.04s)
the entire project locally on your
[08:52] (532.96s)
machine without any additional setup. In
[08:54] (534.96s)
my opinion, this is what makes the tool
[08:56] (536.88s)
not only powerful, but also genuinely
[08:59] (539.20s)
impressive in terms of practical
[09:00] (540.96s)
usability and developer experience. The
[09:03] (543.44s)
app has finished building and I have to
[09:05] (545.36s)
say that it looks genuinely impressive.
[09:07] (547.76s)
Everything is functioning exactly as
[09:09] (549.68s)
expected and the overall layout feels
[09:11] (551.92s)
polished and well thought out. This
[09:13] (553.76s)
particular listing was added earlier by
[09:15] (555.76s)
an anonymous user and now we can go
[09:17] (557.76s)
ahead and test whether the booking
[09:19] (559.28s)
system is working as it should. While
[09:20] (560.96s)
the app was being generated, I started
[09:23] (563.36s)
thinking about just how valuable this
[09:25] (565.44s)
tool could be for anyone who wants to
[09:27] (567.76s)
quickly launch a SAS product or set up a
[09:30] (570.48s)
small online business. If I needed a
[09:32] (572.64s)
website ready in a short amount of time,
[09:34] (574.88s)
I would not have to hire a developer or
[09:36] (576.88s)
outsource the work. Instead, I could
[09:38] (578.80s)
simply use this tool, create the website
[09:41] (581.04s)
myself, and have it live and running
[09:42] (582.96s)
almost immediately. What makes it even
[09:44] (584.88s)
more compelling is the fact that the app
[09:46] (586.72s)
is fully hostable and comes with a
[09:48] (588.72s)
working database built in, which means
[09:50] (590.72s)
that if the business grows over time,
[09:52] (592.64s)
the platform can grow alongside it
[09:54] (594.64s)
without needing major changes. One of
[09:56] (596.88s)
the most impressive aspects is that the
[09:58] (598.96s)
backend is written entirely in React
[10:01] (601.12s)
code, which makes it both efficient and
[10:03] (603.12s)
familiar for anyone with experience in
[10:05] (605.20s)
front-end development. It is easy to
[10:07] (607.04s)
maintain and integrate seamlessly with
[10:09] (609.12s)
the rest of the application. Now,
[10:10] (610.72s)
returning to the app itself, what you
[10:12] (612.56s)
are looking at is the main page of
[10:14] (614.40s)
Neighbor Gear. The listing currently
[10:16] (616.16s)
shown was created by me during testing,
[10:18] (618.40s)
and I used a picture of the R code
[10:20] (620.24s)
kangaroo from my local files to quickly
[10:22] (622.72s)
add some content. The process was simple
[10:24] (624.88s)
and worked exactly as intended. To test
[10:27] (627.04s)
the booking functionality, I will go
[10:29] (629.12s)
ahead and choose May 20th as the start
[10:31] (631.36s)
date and select a 1-day rental period.
[10:33] (633.68s)
The system immediately calculates the
[10:35] (635.60s)
price, which is set at $80 for a single
[10:38] (638.08s)
day, and everything appears to be
[10:39] (639.76s)
working perfectly. You also have the
[10:41] (641.52s)
option to list your own gear for rent
[10:43] (643.60s)
using the built-in submission form,
[10:45] (645.44s)
which is the same one I used earlier to
[10:47] (647.44s)
create the listing for climbing
[10:48] (648.88s)
equipment. Visually, the app looks clean
[10:51] (651.20s)
and modern, and from a usability
[10:53] (653.04s)
perspective, everything runs smoothly
[10:55] (655.36s)
and responds well. Overall, I am
[10:57] (657.76s)
genuinely impressed with what this tool
[10:59] (659.76s)
can accomplish, and I would definitely
[11:01] (661.52s)
consider using it again for future
[11:03] (663.84s)
projects or quick startup ideas. That
[11:06] (666.24s)
brings us to the end of this video. If
[11:08] (668.24s)
you'd like to support the channel and
[11:09] (669.84s)
help us keep making tutorials like this,
[11:12] (672.08s)
you can do so by using the super thanks
[11:14] (674.16s)
button below. As always, thank you for
[11:16] (676.24s)
watching and I'll see you in the next