When I first started tinkering with AI agents, I never imagined I’d end up deploying a full-stack web To-Do app on SashiDo. I’m not a developer. I don’t dream in code. But with the help of tools like Cursor, ChatGPT, and a few well-tuned GPTs(using GPT-5 now) I had lying around, I managed to do exactly that.

In Part 1 of this blog post series, I shared best practices for working with AI agents in Cursor, setting up rules, managing context, and writing focused prompts. Now it’s time to put it all into action and share my journey with hands-on vibe coding!

This post is my honest account of what happened when I took the plunge - what worked, what didn’t, and how I kept moving when things got messy. If you’re not a dev either (or even if you are), this might help you navigate your own vibe coding journey.

What I’m building

My goal is to create a basic yet fully-functional web To-Do application that includes all the essential features you'd expect:

User authentication with email and password
Ability to create, edit, delete, and mark tasks as complete
Optional due dates, and “nice to have” offline behavior
A minimal, lightweight HTML/JavaScript frontend to interact with the backend
A backend powered by Node.js running on SashiDo, using Parse Server
And a few diagnostics to be fully transparent with my level here.

It’s exactly the kind of internal tool or prototype a product person can ship with AI help - fast enough to test, simple enough to maintain, but still useful in real life.

Creating my app in SashiDo

I had my SashiDo account already, so setting up the app was easy. Hit the Create New App button, pick a region, give it a name, and connect GitHub following a few simple steps - that’s where your backend logic lives. If you haven’t done this before, it’s all point-and-click, very non-threatening. In case you don't have a SashiDo account, go ahead and start your free trial from here.

My next step was to start Cloud Code(my business logic) from SashiDo Dashboard> Core > Cloud Code. Once the Deployment process is completed, the section in the Dashboard should look like this:

From here, I simply clicked on the Manage on GitHub button and I was forwarded to my playground a.k.a. brand new private GitHub repo.

First steps in Cursor

Cursor was where I did the heavy lifting - or rather, where the AI did. I cloned the SashiDo GitHub repo into a new Cursor project, told it I was building a simple To-Do app with Node.js and Parse Server on SashiDo, and let it roll.

Alternatively, if you’re starting from scratch, creating a new project in Cursor, just explain in plain English that SashiDo provides a GitHub repo for each app, and then you can attach a screenshot of the repo’s structure directly in the chat with the README.md file you can download directly from the repo. This way, you give the agent eyes so it can see how the structure looks and understand how SashiDo works. Now you can ask Cursor to adjust the local structure and files it built with the initial spec based on this new information.

Preparing the spec and prompting in Cursor

If you've followed Part 1 of the series, you've already seen how to prepare a project-specific ruleset and structure an effective prompt. But here’s a quick refresher on what I did to get started:

I used the Mobile App Feature Planner GPT to generate a detailed app spec. In my case, I’m building a web app, so once the GPT asked me, I just specified that using a sample prompt: "Write a spec for a simple To-Do web app. Be as specific as possible. We're going to be using Node.js and SashiDo as a backend."
I opened a new project in Cursor. Ensure the model is set to Claude 3.7 Sonnet Thinking.
Pasted my spec into the chat window.
Then manually loaded my project-specific rules from .cursor/rules/ as they aren't already active. These files define coding guidelines like using a specific tech stack, avoiding mock data in production, and keeping code DRY as explained in Part 1.
And lastly, prompted the agent to get started: "Build this app based on the spec above. Start with setting up the folder structure, Parse models, and backend routes."

After completing these steps, Cursor usually starts by inspecting your project’s current file structure and environment setup, then proceeds to generate and adjust everything you need - Cloud Code, HTML, CSS, JavaScript, environment configs, and even the app README. If required tools or packages aren’t installed, Cursor also handles their installation, making the whole setup process seamless and hands-free.

Once the setup is complete, Cursor installs dependencies, handles any common warnings, and tests the app locally to confirm everything runs smoothly. It finalizes the process by generating a deployment guide and a detailed summary of the application.

From Cursor to GitHub to SashiDo

Copy-pasting code was my comfort zone. I didn’t try to edit individual lines - too risky. I just replaced whole files and always asked questions like “Which GitHub files do I need to change?” just to be on the safe side. Function.js, main.css, index.html, and app.js (inside a new /js folder I created manually) were the main ones I worked with.App.js is where I put my app credentials. Those you can find in SashiDo Dashboard > App Settings > Security & Keys.

Then I simply hit “Commit changes”, and that triggered a build on SashiDo.

Boom. My app was deployed.

...Except it wasn’t working

The first time I loaded the app Public URL(you can find it in SashiDo Dashboard > App Settings > Security & Keys) felt like unwrapping a Kinder Surprise. I expected bugs. I got bugs.

So I started sending screenshots from the browser console errors and asked Cursor to help iteratively. I know that with enough iteration and stubbornness, I can achieve quite significant results and solve almost any problem or bug. Would it be the most efficient or the fastest way? No, for sure. But guessing and trial & error have gotten a lot faster since AI agents are here. And I’m about to show you just how fast.

Parse Is Not Defined. What?

One of the first issues hit hard: "Parse is not defined."

Cursor had forgotten to load the Parse JavaScript SDK in the browser. Rookie move, honestly - but easy to miss. As someone who doesn't naturally think in code, I spent hours just trying to figure out what that even meant, but I’ll share more about that in the next points.

Fix: manually add the official CDN <script> for Parse before loading .js. Not obvious. Not fun. But fixed it.

Then came the "process.env" issue. Cursor was using environment variables in frontend code - which, if you know browsers, doesn’t work. Browsers don’t have process.env. I had to tell the agent to switch to a config file instead.

Except for sending error screenshots to Cursor, I also copied and pasted the official Parse Server documentation for Java Script to give it a clearer context. I took just the Getting Started part, which includes how to initialize Parse Server. Then I also stated to Cursor that I don’t want it to add any additional files and keep up with the standard GitHub structure we duplicated in the beginning. Also mentioned that SashiDo has predefined environment variables and that for my app I’m using Parse Server v3.6.0 - node 18 version on SashiDo, as I wanted to be on the safe side.

Cursor fixed some of the issues - like outdated Parse SDKs and random extra files it tried to add - but I was burning through free usage fast. I did a few more rounds of prompts and re-deployments of the app, but the loops got longer. I still liked the agent flow, but I needed faster back-and-forth to keep the flow going.

The takeaway from this step for me is that when an agent “improves” structure, I need to re-anchor it with how the platform I’m using(e.g. SashiDo) actually works (browser SDK, CDN tag order, no process.env in the frontend). Don’t assume it knows.

ChatGPT Speaks My Language

Here I had to make a call, so I switched to ChatGPT.

ChatGPT’s strength? It talks to you like a human. I told it I was using SashiDo and Cursor so far, that I was non-technical, and what my app was trying to do.

When enableLocalDatastore() started crashing my app, ChatGPT explained that the browser build I had didn’t support it. So I had two options:

Guard the offline code and focus on online-only
Use a different Parse SDK build that supports local datastore

Option 1 was the easy fix. I commented out the offline bits, committed, and… it worked.

Takeaway: Just because you can build a feature doesn’t mean you should build it now. Ship what works first.

Yeah, it works, and it needs more testing

You can imagine I was very happy to see this screen and be able to register and log in to my app successfully! Behind the scenes, what happened is that I had a new user and session created in my database, which you can see in the SashiDo Dashboard>Database Browser.

Still, I knew I needed to test all basic functionalities, and the first one was to try to create a New Task. Oops! Not working. I always test with my console open.

To give ChatGPT more context for this error, I copied and pasted my app.js and my main.js files. This way, it could check the logic for my Cloud Functions createTask, getTasks, updateTask, deleteTask, syncTasks works fine, or correct it if needed.

I did a few iterations of ChatGPT, suggesting code changes to my app.js and my main.js files and committing them in GitHub, which didn’t bring much success, just some error messages changing. I checked the SashiDo Logs from Dashboard → Logs to get some more context on the issue, but there wasn’t anything relevant there. Still, it’s an important step for debugging. I also added additional logging logic as per ChatGPT's suggestion. It basically got me in ruling out possible reasons for the errors one by one. At some point, I felt it was looping, and it’s time to open a new chat as this one was becoming way too heavy and killing my vibes.

Enter GPT-5: Debugging Reinvented

Just as I was knee-deep in debugging my task creation logic, GPT-5 launched. I fired up the new model using my Cloud Code Debug Advisor, uploaded my app.js and main.js, and shared my error screenshots.

Again, we went through checking out the SashiDo logs and checking my app’s health at https://pg-app-.scalabl.cloud/1/health to rule out some of the possible reasons for the 400 error message. But then it told me to do something wild: open the console and run direct tests. I’d never done that. Didn’t even know I could.

That changed everything. Suddenly, I had visibility. I could see what was actually happening. We narrowed down the issues, reverted one bad change (yes, I got a 503 error for a while), and eventually, the app worked. All of it!

Log in, create a task, edit a task, mark complete. Done.

I tested a few more functionalities, like completing a task and editing a task, and since everything was running smoothly, I decided that this is the moment I’ll stop. After all, I wanted to build a very simple, yet functional MVP of a web To Do app. This task was achieved, so trying to improve and add features is part of a different story.

What I Learned

This journey had its ups and downs, but overall I really enjoyed it. More importantly, it proved to me that with vibe coding, you can achieve anything. If I, without being deeply technical, managed to release a real app, just imagine what professionals in the field can build. Still, to keep things practical, here are my key takeaways:

Momentum matters more than the tool. Cursor, ChatGPT, GPT-5, SashiDo’s Custom GPTs - each had a role. When one slowed me down, I switched.
Give your agents context. Re-state your tech stack, environment, and platform each time. Don’t assume they know or remember initial prompts.
Simplify. If you're not a dev, lean into that. Don’t overbuild. Don’t overengineer.
Keep going. You don’t need to understand every log to fix bugs. Screenshot, paste, ask. Iterate.

I didn’t build the flashiest To-Do app in the world. But I built my To-Do app. I shipped it. And I learned a lot.

That’s the power of vibe coding. You don’t need to be a coder. You just need to keep trying, follow the vibes, and enjoy the ride!

Start building your own app with AI agents and SashiDo’s free trial now - no dev experience required!