Yeah, it might sound clickbaity, but think about it for a second. For as long as most of us can remember, developers have been haunted by an age-old constraint: fast, cheap, or good. Pick two.

We repeated it like gospel. We built project timelines around it. We gave it to stakeholders as the excuse for late nights and budget overruns.

But something’s changed. The game has shifted.

And that myth? It’s officially dead.

Let me show you why.

The "Pick Two" Rule That Ruled Us All

You’ve heard it a thousand times:

Want it fast and cheap? It won't be good.
Want it good and fast? Open your wallet.
Want it good and cheap? See you in a year.

For decades, this wasn't just a saying. It was reality. A law of nature in software development.

Photo by Karola G

But like all laws, it only lasts until someone rewrites the rules.

Enter: Vibe Coding.

Rewind to 2015: Building Was a Battle

Imagine you're a solo founder in 2015. You've got a spark of an idea - a collaborative app, maybe a slick dashboard, maybe a tool to bring people together.

You're dreaming big. But to make it real? That dream has to pass through a minefield of core points you need to fiugre out, design, configure and execute:

• Backend logic
• Authentication
• iOS and Android frontends
• Admin panels
• Payments
• Real-time sync

You hit Upwork. You hire freelancers in different time zones. You chase deadlines, quality slips, and you lose sleep over merge conflicts.

After weeks,sometimes months, you've spent thousands of dollars. And the result? A barely functional MVP that kind of works... until it doesn't.

You didn’t fail because your idea wasn’t good. You failed because building good software was just that hard and the system was broken.

Fast-forward to Now: Welcome to Vibe Coding

It’s the end of 2025. Same idea. Same ambition. But this time, you open your LLM interface and:

• Instead of managing people, you’re managing agents.
• Instead of writing boilerplate, you’re designing workflows.
• Instead of chaos, you’ve got orchestration.
  

Photo by Darlene Alderson

Then you just say something like:

"I want to build a collaborative note-taking app. Split it into phases. Backend on SashiDo, frontend in React, mobile via Capacitor. Postgres for data. Auth, tests, SDKs, and a CLI tool, too."

No cold emails. No flaky devs. No boilerplate from scratch. Just like that, your software pipeline activates.

Not just code. A process.

It doesn’t feel like you’re building an app. It feels like you’re assembling a machine that builds apps.

What Actually Changed?

Let’s get real: this isn’t just about AI writing code faster.

This is about how you build.

Old-school development was linear. You moved from PM to dev to QA to deploy like parts on a conveyor belt. And every handoff came with friction.

With Vibe Coding, you build workflows instead of writing tickets. You split your app into smart, orchestrated pieces. Each one is executed by a specialized agent, designed to work autonomously but in sync.

Suddenly, you're not managing chaos. You're designing harmony.

Your New Workflow Might Look Like This:

Let’s say you’re building that same note-taking app. Here’s how your workflow might run:

1. Plan the Architecture

Not just “build a feature” - you split it into micro-projects:

• Backend logic
• Frontend rendering
• SDKs
• CLI tools
• API docs

Each is treated as its own mini-project, with clear boundaries and expectations.

2. Use Specialized Agents

Assign Different Specialized Agents to handle seprately:

• A planning agent to scope work
• Implementation agents to code it
• Testing agents to validate it
• Review agents to sanity check it(in fresh context, to avoid bias)

Each one works in parallel— no waiting for the next.

Photo by Eric Krull on Unsplash

3. Run Async

Your frontend and backend are built in parallel. At the same time - test agent runs separately and docs are auto-generated while code is reviewed.

4. Review Like a Lead Engineer

You're not just hoping it works. You verify:

• Test coverage?
• Edge cases?
• Compliance with best practices?**

You ask agents to simulate load. To suggest improvements. To raise flags.

And just like that, you’re not coding at hyperspeed. You’re designing systems at scale.

Why This Isn’t Just “Better Prompting”

Let’s be clear: this isn’t about writing better prompts. This is about building intelligent workflows.

Because once you do, the cost drops. The speed jumps. And yes, the quality increases.

Your value as a developer isn’t how fast you type anymore. It’s how well you:

• Architect workflows
• Embed best practices
• Run everything asynchronously
• Decoupling tasks
• Testing in isolation
• Running async
• Iterate intelligently

You’re not cutting corners. You’re cutting friction.

Photo by cottonbro studio

From Complexity to Clarity

In the old world, planning meant whiteboards, spreadsheets, and days of meetings. Now? One well-structured request to a planning agent.

Dev used to mean line-by-line implementation. Now? Your intent is scaffolded in seconds.

Testing? Used to be late-stage and error-prone. Now it’s continuous and AI-driven.

Thousands of dollars in dev hours turnes into $5–$50 per workflow cycle.

Speed of development turns from weeks or months to hours or days.

And all that rework? Gone.

Everything flows in sync. Reviewers check code without context bias. Documentation is generated in real time. Deployments happen on demand.

Photo by Joylynn Goh on Unsplash

But Wait - Is the Code Actually Good?

Not always. But guess what?

Most human-written code isn't that good either.

What matters is that Vibe Coding gives you the framework to:

• Bake in quality from the start
• Enforce structure and conventions
• Test continuously, not just at the end
• Version and rollback with clear checkpoints

Yes, you still need understadning of how things works. You need to know what “good” looks like.
But with the right workflow, you can enforce good even if you’re not a senior engineer (yet).

Why This Is the Golden Era for Indie Builders

Let’s be brutally honest. The real bottleneck in shipping ideas has never been the idea itself. It’s the process.

Most indie projects die in the gap between version 0.1 and version 1.0.

Vibe Coding closes that gap. You no longer need a full dev team. You don’t need $50K in pre-seed funding. You don’t need six months of sleepless dev nights.

You need:

• A clear idea
• A smart workflow
• A hosting environment like SashiDo to deploy & host it all

That’s it.

You can launch. You can scale. You can build a business in fraction of the time and costs compared to old times.

Photo by Tima Miroshnichenko

One Last Thought

You don’t need to be the most senior engineer in the room anymore. But you do need to be the one with the best workflow. Because in this new era - workflow eats code for breakfast.

Ready to Build Smarter?

Launch your next idea with Vibe Coding workflows and deploy it on SashiDo.

• Fully managed backend
• Static hosting for your frontend
• API-ready out of the box
• Scales with your business

🚀 Deploy your app with SashiDo in minutes.
Start your Free Trial Now.
And here is a quick Getting Started Guide for a smooth take off.

Happy Coding!

We’ve just wrapped up a month of polish, flow‑enhancement and productivity wins inside your SashiDo Dashboard. From build visibility to logs export, every update was driven by your feedback - because we know your time is precious and flow matters. No fluff. Just sharper tools so you can ship with confidence and less friction.

Let’s walk through what’s new.

1. Builds: Visibility Upgrade

We kicked off the improvements with the Builds section so you have complete context for every build without leaving your SashiDo dashboard.

Here’s what we added:

• Full commit context inside each build: branch name badge, complete commit message, author avatar + name, list of files added/modified/removed and a direct link to GitHub.
• If a build includes multiple commits (e.g., a merge or a bulk update), you’ll now see each commit listed rather than just the latest.
• One‑click copy icons next to commit hashes so you don’t have to highlight manually.
• Smart filters for build status: All Builds / Running / Complete / Failed - each with a count badge for at‑a‑glance clarity.
• Auto‑expand the latest commit by default, assuming that’s most likely what you’re after.
• Some dev‑friendly touches: force‑push detection with warning; commit count badge; GitHub links everywhere; helpful empty‑state guidance for new users.

Why it matters:

When a build breaks, you don’t want to play detective. With this update you stay in context—branch, author, diff, commit history—all in your dashboard. Faster diagnosis, less tab‑hopping, quicker fixes. And when your team moves faster, your users notice.

2. Deployments: Smarter Filters & UX Updates

Next in our sprint: your Deployments page got a refresh to help you move faster and stay in sync.

Here’s what changed:

• Status filters: Active, Running, Complete, Failed, Cancelled. Each filter shows a count (e.g., “Failed (2)”) so you immediately know where to focus.
• One‑click deployment number copy: Just click the deployment number and it copies to your clipboard—ready to paste into Slack, JIRA, terminal, etc.
• Green highlight for the active deployment: The deployment currently live in production is visually emphasized with a bright green border/background. Makes scanning quick.

Why it matters:

Deployments are high stakes. When things go wrong (or you just need to track what’s live), you need clarity and speed, not hunting through pages and timestamps. These tweaks remove friction so you can focus on what matters: shipping safe and fast.

3. Environment Variables: One‑Click Examples

Third in our sequence: we improved how you set up and manage environment variables - a foundational but often pain‑point step.

Here’s the update:

• When you create a new environment variable, you’ll now see a grid of pre‑built examples for 12 of the most‑used services - from AI tools to payment systems.
• Examples include the correct variable name, an example format of the value, and copy‑to‑clipboard buttons. For services like:
  • AI / LLMs: OpenAI (OPENAI_API_KEY), Anthropic/Claude (ANTHROPIC_API_KEY), Hugging Face (HUGGINGFACE_API_KEY), Cohere (COHERE_API_KEY), Replicate (REPLICATE_API_TOKEN), Stability AI (STABILITY_API_KEY)
  • Core services: Stripe (STRIPE_SECRET_KEY), Sentry (SENTRY_DSN), SendGrid (SENDGRID_API_KEY), Twilio (TWILIO_ACCOUNT_SID), Google Maps (GOOGLE_MAPS_API_KEY), Cloudinary (CLOUDINARY_URL)
• Setup now: Click the example → paste your key → Save & Deploy. No guesswork on naming or value formats.

Why it matters:

Onboarding a new integration shouldn’t feel like a scavenger hunt. Developers were losing time deciding what to name variables, what format to use, etc. With this release, you’re guided from start to deploy in ~30 seconds. Fewer errors, fewer Slack threads about “why isn’t this var named correctly?”, and faster iteration.

4. Logs: Search, Export & Copy for Fast Debugging

Finally, we wrapped the month of releases by tackling one of the biggest developer pain‑points: digging through logs.

Here are the key features:

• Instant search with highlighting: As you type in the search bar, results appear immediately across all log entries (messages, stack traces, metadata). Matches are highlighted in yellow for quick scanning.
• One‑click copy on each log line: Hover over a log line, click the copy icon, and the full entry is copied in tidy format. No screenshot, no manual formatting.
• Log export: Click “Export Logs” to get a clean .txt file of what’s currently visible. Auto‑generated filename helps with communication or compliance.
• Timestamps: relative + absolute: Logs now show both relative time (e.g., “5 days ago”) and the full absolute timestamp (e.g., “17:29:20 +02:00 on Oct 29, 2025”).
• Color‑coded badges: Log entries are tagged visually with badges: INFO (green), WARN (yellow), ERROR (red) — so your eyes land on what matters.

Why it matters:

When an incident hits - say, “payment failed around 3pm” - you don’t want to scroll endlessly or alt‑tab between tabs. These improvements let you identify the error, copy it, export if needed, and share in very fast. Minutes turn into seconds; frustration turns into fix momentum.

Wrapping Up

We shipped 20+ improvements this month across the SashiDo Dashboard - each one targeting a specific developer pain point: build visibility, deployment clarity, environment‑setup friction, and log debugging speed.

Photo by Mikhail Nilov:

Here’s what that means for you:

• Less time hunting for context, more time shipping features.
• Fewer clicks, fewer tabs, fewer cognitive overheads.
• More consistent workflows across your team - onboarding, debugging, deployment.
• Real‑world wins: faster issue resolution, smoother releases, lower downtime.

What’s next?

We’re not done. This month’s sprint is part of a larger effort to make your SashiDo Dashboard work the way you do. We’d love to hear what’s slowing you down next - hit us at support@sashido.io with your feedback and ideas.

Log in now, fire up your dashboard, and check out the updates.

Happy Coding!

Welcome to Week 3 of our Dashboard Improvements Series. Over the last two week we've covered what's new in Builds and what's new in Deployments sections. This week, we’re improving one of the most foundational steps in your backend setup: adding environment variables.

You know the routine: you sign up for a service, copy your API key, and then spend the next 10 minutes Googling what to name the variable. STRIPE_KEY? STRIPE_SECRET? STRIPE_API_KEY? Trial and error until it works.

We’ve all been there. So we fixed it.

We know this part of the process often leads to repetitive questions and unnecessary friction, especially when integrating third-party services.

Which variable name should I use? What should the format look like? Why are there three different naming conventions floating around?

You shouldn’t need a scavenger hunt just to wire up Stripe, OpenAI, or Twilio.

So we’re making it easier.

From Guessing to Guided

When you create a new environment variable, you’ll now see a helpful set of examples of third-party services - everything from payment processors to LLMs. We took the top 12 services SashiDo developers actually use - like Stripe, OpenAI, Sentry, and Google Maps - and created Environment Variable Examples for each.

Now, when you add a new variable, you just Click the example > Paste your key >Save & Deploy

And you’re done. No docs. No guesswork. No naming debates.

Each example comes pre-filled with:

• The proper variable name(what your code or SDK expects)
• An example value format
• Instant Copy to clipboard buttons for both

You go from setup to deployment in 30 seconds flat.

Note: Each example helps you create one variable at a time. Once saved, you can click on the "Add Environment Variable" button to create another custom one.

What’s Included?

We started with the 12 services developers on our platfrom use the most - from AI tools to core infrastructure and created examples that make setup easier.

AI Services

• OpenAI - OPENAI_API_KEY - Powers ChatGPT, GPT-4, DALL-E, and Whisper. For chat, text generation, image generation, and audio transcription.
• Claude AI - ANTHROPIC_API_KEY - Anthropic's Claude 3 models. For advanced reasoning, coding assistance, and longer context windows.
• Hugging Face - HUGGINGFACE_API_KEY - Access thousands of open-source ML models. For NLP, computer vision, audio processing, and more.
• Cohere - COHERE_API_KEY - Enterprise-grade NLP. For text generation, semantic search, and classification.
• Replicate - REPLICATE_API_TOKEN - Run open-source ML models via API. For image generation, video processing, and audio synthesis.
• Stability AI - STABILITY_API_KEY - Stable Diffusion and other image generation models. For AI-powered image creation and editing.

Core Services

• Stripe - STRIPE_SECRET_KEY - Payment processing for online businesses. Handles credit cards, subscriptions, and invoicing.
• Sentry - SENTRY_DSN - Real-time error tracking and performance monitoring. Catch errors before your users report them.
• SendGrid - SENDGRID_API_KEY - Transactional and marketing email delivery. For password resets, receipts, and notifications.
• Twilio - TWILIO_ACCOUNT_SID - Programmable SMS, voice, and video. For 2FA, notifications, and customer communication.
• Google Maps - GOOGLE_MAPS_API_KEY - Maps, geocoding, places, and directions. For location-based features and store locators.
• Cloudinary - CLOUDINARY_URL - Image and video storage, transformation, and delivery via CDN. For user uploads and media optimization.

A Real Setup Example

Let’s say you’re integrating OpenAI into your app for the first time — maybe to power chat, generate text, or use DALL·E. You go to SashiDo Dashbaord > Runtime > Environment Variables and then:

No trial and error. Just done. That's 20x faster.

Why These 12 Services?

We didn't pick these randomly. We analyzed what services SashiDo developers integrate most, what mobile & AI developers need most daily, and of course - what causes the most "how do I set this up" support tickets.

The result:

• Mobile devs need push notifications, error tracking, maps → Sentry, Google Maps
• AI builders need LLM APIs → OpenAI, Claude AI, Hugging Face, Cohere, Replicate, Stability AI
• SaaS founders need payments, email, SMS → Stripe, SendGrid, Twilio
• Everyone needs media storage and errors → Cloudinary, Sentry

These examples cover 90% of third-party integration setup.

Why This Matters

You get faster setup and fewer context switches. No docs to open. No trial and error. Just click, paste, deploy. And for your team this means consistency across environments. Easier onboarding for new devs. No more Slack threads about variable names. Which ultimately leads to fewer bugs due to misnamed vars. Faster integrations. Less friction when trying new tools.
Photo by Priscilla Du Preez 🇨🇦 on Unsplash

Try It Now

This is live for all SashiDo customers:

👉 Log in to SashiDo Dashboard → Go to any app → Runtime → Environment Variables → See the examples grid

Click a service. Experience what setup should feel like.

Want More Examples?

We started with the 12 most-requested services. But we're not done.

What service should we add next?

• Firebase?
• MongoDB Atlas?
• Redis Cloud?
• Algolia?
• Auth0?

Email us at support@sashido.io to tell us which ones you need. If enough people request it, we'll build it.

What’s Next?

This is part of a bigger effort to make your entire SashiDo dashboard more helpful. Over the last week of our 4-week sprint, we'll be sharing updates to Logs section. Each one solves a real problem we heard from you, so we'd love your feedback!

Not using SashiDo yet?

We’re a serverless backend built on Parse Server. No vendor lock-in. No credit card. And a real-human support team that actually responds.

👉 Start your Free trial now

Happy Coding!

When push notifications fail, your users notice, but until now, getting to the why behind those failures hasn’t been easy. You’d see the error count, maybe even the device type, but no real way to connect the dots between the failure and the specific user or their device.

So you asked us for deeper visibility into push delivery. We listened and we built Advanced Diagnostics for Push Notifications - a powerful new way to investigate delivery issues, trace them down to exact devices, and take action fast.

No more guesswork. No more back-and-forth. Just the right data, in the right place, when you need it most.

Failing Push Notifications: The Missing Context

Until now, you could see that some pushes failed. You could see the number. But tying those failures to actual devices? Connecting them to specific users? You see a handful of errors, but you don’t have enough context to act. That was… messy. We know.

And if you wanted to know why they failed - like Unregistered, Invalid Token, NotSubscribed, etc. - you had to do some serious log archaeology.

That changes today.

Photo by bruce mars on Unsplash

What We Built

Meet Advanced Diagnostics for Push Notifications - a focused upgrade to give you more context, faster insight, and actionable data where you need it.

Enable Diagnostics with One Toggle

In your app’s settings, click "Enable Advanced Diagnostics" under Push Notification settings.

Once toggled, SashiDo Push Notification Service begins automatically collecting:

• Push delivery errors by Installation ID
• Full list of affected device types (iOS / Android)
• Exact failure reason (e.g. Unregistered)
• Timestamp and Push ID context
• Filtering and export support for deeper analysis
  

You can access all diagnostics metadata from the Push Failures tab or via the Database Browser.

Visualize Detailes

View a dedicated list of all push failures (e.g., “Push ID #27: Unregistered”).

Where you can find details by device type, error type, date, or Push ID so you can isolate patterns.

Quick Export

Export the data as CSV for offline analysis or sharing with stakeholders.

Dedicated Failure Collection & Filters

Once the feature is enalbed and erros are logged the service automaticaly creates a collection called _PushFailureDetails where you can easily review a detailed summary of the errors righ in the Dashbaord. This way you can easily leverage the Database Browser for filtrering a specific push ID.

Copy & Share Instantly

Each failure has a “Copy” option. Click it to get full context: Push ID, Device Type, Error Reason, Timestamp. Perfect for support tickets, bug reports, or Slack threads—no screenshot cropping required.

Real-world use case

A customer tells you “I didn’t get the push”. Previously, you had two options:

• Hope it was a one-off
• Or start exporting _PushStatus and _Installation manually

Now? You go to Push Notification Details → Failed Device Tokens → open _PushFailureDetails collection → Filter by Push ID → See all devices that failed → Copy and investigate.

Less guesswork. More resolution.

Photo by Brett Jordan on Unsplash

Why This Matters

You spend less time hunting and more time fixing. One toggle, clear data, instant context. Everyone on your team sees the same data set. No more “whose token is this?” or “why did this fail?” slack threads. All this ultimately means faster recovery from push failures, better reliability for your users and stronger trust in your shipping process.

Try It Now

This feature is live for all SashiDo users.

👉 Log in to SashiDo Dashboard → choose your app → Settings > Push → Enable Advanced Diagnostics → ready, set, go.

Start your next investigation with confidence.

Want More Debug Power?

Got feedback? We want to know what info you need to take troubleshooting from “maybe” to “done”. We’re actively prioritizing improvements based on real feedback - like this one.

👉 Drop us a note at support@sashido.io or directly open a ticket through the dashabord.

Because shipping code is hard enough, debugging it shouldn’t be.

Not using SashiDo yet?

We’re a serverless backend built on Parse Server. No vendor lock-in. No credit card. And a real-human support team that actually responds.

👉 Start your Free trial now

Happy Coding!

Welcome to the final post of our Dashboard Improvements Series! Over the last three week we've introduced visibility upgrades in Builds, redesigned Deployments, and rolled out Environment Variables Tempaltes. This week, we’re turning our attention to a part of the dashboard you rely on when things break: Logs.

Logs have always been there to help. But as your app grows and the data piles up, finding the exact log entry you need hasn’t always been fast or easy. So we made it better.

The “Log Archaeology” Problem

It’s 3pm. A customer says their payment failed. You open the logs and start scrolling. And scrolling. And scrolling.

You try Cmd+F. You get 147 hits for “payment.” You start clicking through, hoping one of them is the one you need. By the time you find the relevant log line, if you even do, you’ve lost more than just 5 minutes and a chunk of your focus.

And then sharing it? You screenshot. Or copy-paste. Or try to describe what you saw in words.

This shouldn’t be the workflow. So we rebuilt it.

What We Built

We intordoduced updates to the Logs that will increase debuging speed and improve your workflow.

Instant Search with Highlighting

Type anything into the search bar and get results instantly. It checks every log entry, including messages, stack traces, and metadata. Matches are highlighted in yellow so they pop off the screen. The time to find what you need now is significantly reduced.

One-Click Copy

Every log line now has a copy button. Just hover, click, and the full entry is copied with perfect formatting.

Full context.Ready to paste it into Slack. Support tickets. Bug reports or documentation. Done. No screenshots, no manual formatting.Just click and paste

Log Export

Need to share logs with Stripe, AWS, or anyone external? Just click “Export Logs” and get a clean .txt file of your entire present on the screen logs.

File names are auto-generated (e.g., logs_error_2024-10-21.txt) so it’s always clear what you’re sending.

Perfect for:

• Sharing with external support teams
• Archiving for compliance backups
• Offline debugging
• Creating reports

Relative + Absolute Timestamps

Logs now show both absolute and relative time:

• Relative time is easier to parse: "Oh, this error happened 5 days ago"
• Absolute time is precise for sharing: "The error occurred at exactly 17:29:20 +02:00 on Oct 29, 2025."

You get precision for sharing, and quick insight for triaging automatically. Best of both worlds.

Color-Coded Log Badges

Visual cues help you scan faster:

🟩INFO - green badge
🟨WARN - yellow badge
🟥ERROR - red badge

When you’re scanning a long list, these badges guide your eyes right to what matters.

Real-World Example

In a secenario where a user reports: “Payment failed around 3pm.”, here is how your workflow goes before and after this release:

That’s not just a small improvement, that’s the kind of fix that makes your day better.

The Time Math

Let's say you debug 3 production issues per week, and this saves 5 minutes per issue.

• Per week: 15 minutes saved
• Per month: 1 hour saved
• Per year: 12 hours saved

What would your team build with an extra 12 hours per year? New features? Better testing? Taking a real team lunch break every couple of months? We vote for all of the above.

Photo by Scott Graham on Unsplash

The Support Ticket Win

One customer told us: "We integrate with a bunch of third-party APIs. When something breaks, they always ask for logs. I used to take screenshots, crop them, paste them in tickets... it was a nightmare."

After this release's changes: "Now I search for the error, click copy, paste it in the ticket. Done. Our support response time improved because I can give them what they need in seconds instead of minutes."

Photo by Guillaume de Germain on Unsplash

That's the real value: You solve problems faster, which means your users get back to work faster, which means your business runs smoother.

Try It Now

This is already live for all SashiDo users:

👉 👉 Log in to SashiDo Dashboard → Go to any app → Core → Logs → Search Your Logs → Just type and go.

See how much faster things get when your tools work the way you do. Intuitively.

What’s Next?

Each one of the updates we released through this 4-week sprint solves a real problem we heard from you! We’re not stopping here. Want to help shape what comes next? Tell us what’s slowing you down - we’ll listen. And we’ll build.

Email us at support@sashido.io or open a ticket trough your dashbaord to share your feedback.

Because we earn your trust by improving your experience, not through lock-in, but by showing up every day and making things better.

Not using SashiDo yet?

We’re a serverless backend built on Parse Server. No vendor lock-in. No credit card. And a real-human support team that actually responds.

👉 Start your Free trial now

Happy Coding!

Welcome to the first post in our Dashboard Improvements Series - a 4-week sprint into the biggest upgrades we've rolled out across the SashiDo platform recently.

Each week, we’re putting the spotlight on one key area of your dashboard: Builds, Deployments, Environment Variables, and Logs. Whether you’re debugging builds, setting up API keys, or rolling back a deployment, these updates are designed to save you time and reduce frustration.

This week, we’re kicking things off with Builds, because we know how crucial build visibility is when something breaks right after you push to GitHub.

The Problem You Kept Running Into

You push to GitHub. A build runs. Something fails. And now you’re juggling browser tabs trying to debug it.

Sound familiar?

We heard the same thing from dozens of developers: the build logs just weren’t giving enough context.

Photo by Mikhail Nilov

You could see that a build failed. You got a hash. A timestamp. But not the full story.

• Which branch was this on? Time to open GitHub.
• What files changed? Another tab.
• Was this one commit or five? Only the latest showed up.
• Who pushed this? Better go dig.

By the time you pieced it all together, you’d lost 5 minutes and your flow. That’s not good enough.

What’s New in Builds

The Builds section now comes with enhanced GitHub integration, giving you complete context for every build without leaving your SashiDo dashboard.

Full Commit Details

Each build now displays:

• Branch name (with a clean badge)
• Complete commit message
• Author name and avatar
• Files added, modified, or removed
• Direct link to view changes on GitHub
  

Multi-Commit Visibility

If your build includes multiple commits, PR merges, or bulk updates, you’ll now see each one listed with full context, so debugging multi-commit builds is quick and straightforward.

One-Click Copy

Need to share a commit hash in a bug report or Slack message? Click the copy icon next to any hash. Done. No more manual selection, accidental extra characters, or "did I get the whole thing?"

Smart Filters

Zoom in fast:

• All Builds - your full history
• Running - builds in progress
• Complete - successful ones
• Failed - needs attention

Each filter includes a count badge for quick status at a glance.

Auto-Expanded Latest Commit

Your most recent commit opens automatically when you visit the page. Because let’s be honest - that’s probably what you came for.

Workflow improvment and Speed Boost Example

We not only removed some steps and saved you time, but improved your everyday worflow. Let's take for example a situation where an user reports: "The app crashes after login."

Why This Matters

This upgrade isn’t just about aesthetics, it’s about getting you back in flow.

When your app breaks, you want answers fast. With the new build view, you’ve got all the context right there: which branch you’re on, what changed, who made the commit, and how it fits into the bigger picture. No need to bounce between tabs or copy hashes into GitHub. You stay focused, move quicker, and get the fix in motion.

For your users, that means less time waiting for things to get patched. Bugs are caught and resolved faster, reducing downtime and smoothing out their experience with your app.

And for your team, especially if you’re working in a fast-moving environment, this is a real win. No more blockers from mysterious build failures or trying to figure out who pushed to the master and what. Just instant visibility, faster resolution, and more momentum on the things that matter: shipping features and improving your product.

Dev Details We Think You’ll Love

And lastly, there are a few little touches also worth mentioning as we designed them to make your life easier:

• Force push detection: We show a warning when a push was forced - important context when tracking issues.
• Commit count badge: Instantly see how many commits were included.
• GitHub links everywhere: Click through to view full diff, individual commits, or the compare view.
• Empty state help: New to builds? We show clear guidance on how to trigger your first one.
  

And remember: SashiDo automatically builds and deploys only when changes are pushed to the master branch of your private cloud code GitHub repo, keeping your staging and experimental branches separate.

Try It Now

These upgrades are already live for all SashiDo users. No config. No billing changes. Just log in and go to Runtime > Builds.

💡 Want more tips on managing your runtime efficiently? Check out our guide on tracking builds and deployments.

What’s Next?

This is part of a bigger effort to make your entire SashiDo dashboard more helpful. Over the next few weeks, we'll be sharing updates to Deployments, Environment Variables, and Logs. Each one solves a real problem we heard from you, so we'd love your feedback!

Got feedback? Questions? Ideas?

Ping us in chat or email us at support@sashido.io.

Not using SashiDo yet?

We’re a serverless backend built on Parse Server. No vendor lock-in. No credit card. And a real-human support team that actually responds.

👉 Start your Free trial now

Happy Coding!

Welcome to Week 2 of our Dashboard Improvements Series. Last week we've covered what's new in Builds section. This time, we’re leveling up Deployments - with upgrades designed to help your team move faster, stay in sync, and debug with confidence.

No more scrolling and searching. No more manual copy + pasting. Just clarity, speed, and flow.

Deployment Debugging - Less Searching. More Solving.

The issue wasn’t lack of information – it was how long it took to reach the part you actually needed.

Previously, if something failed, you’d have to scroll through a long list of deployments, scan timestamps, try to remember the status, and manually grab the deployment number to share with a teammate.

That might not sound like much. But when you're troubleshooting under pressure or collaborating on a fix, every extra step chips away at your focus.

What we built isn’t just cleaner UI, it’s real UX improvement. All designed to help you move faster, stay in sync, and get to the root of issues without the mental overhead.

What We Built

Your deployments page now makes it immediately obvious what's happening – no detective work required.

Status Filters

Find exactly what you're looking for in one click:

• Active - what's live right now
• Running - deployments in progress
• Complete - successful deployments
• Failed - need investigation
• Cancelled - manually stopped
  
  Each filter shows a count, like "Failed (2)" so you know what needs attention.

One-Click Deployment Numbers

Let’s say someone on your team asks about a deployment from yesterday. You don’t need to highlight anything manually.

Just find the deployment, click the number, and it’s copied to your clipboard. Clean. Fast. Ready to paste into Slack, a ticket, or your terminal.

"Deployment #4" is now one tap away from your clipboard.

Green Highlight for Active Deployment

No more squinting at timestamps.The deployment currently running in production gets a bright green border and background. Easy to spot at a glance.

Workflow improvment and Speed Boost Example

We not only removed some steps and saved you time, but improved your everyday worflow. Let's take for example a situation where a customer reports an issue and a teammate is asking you for the specific number of the deployment that Faild 10 days ago and you have more than a 100 deployments.

Why This Matters

Your workflow is faster. You spend less time scanning for info and more time solving real problems. When something goes wrong, you’re not lost in the UI - you’re in control.

And faster debugging means quicker fixes. That means less downtime, fewer issues lingering in production, and a smoother experience for your customers.

And last, but not least - clearer deploy visibility leads to better coordination, fewer delays during incidents, and shorter time-to-resolution. That means happier teams, happier users, and fewer costly mistakes.

Try It Now

These upgrades are already live for all SashiDo users. No config. No billing changes. Just log in and go to Runtime > Deployments.

💡 Want more tips on managing your runtime efficiently? Check out our guide on tracking builds and deployments.

What’s Next?

This is part of a bigger effort to make your entire SashiDo dashboard more helpful. Over the next few weeks, we'll be sharing updates to Environment Variables and Logs. Each one solves a real problem we heard from you, so we'd love your feedback!

Got feedback? Questions? Ideas?

Ping us in chat or email us at support@sashido.io.

Not using SashiDo yet?

We’re a serverless backend built on Parse Server. No vendor lock-in. No credit card. And a real-human support team that actually responds.

👉 Start your Free trial now

Happy Coding!

Let’s be real, writing rules manually for your AI assistant in 2025 is starting to feel a lot like coding without version control in 2010.

Still doing it? You’re not alone.
Still doing it manually? There's a better way.

If you're working with Cursor(or planning to) and your SashiDo-powered backend or fullstack app, this guide will walk you through how to make your Cursor rules evolve automatically based on how your codebase grows.

Yes, you read that right - your codebase can start teaching itself! And it only takes one file to unlock that capability. Let me show you how.

Build a Self-Improving AI Codebase with Cursor

You might already know Cursor lets you define .mdc rules—markdown-based config files that guide your AI assistant. But one rule takes things to another level: the self-improvement rule.

Photo by Tara Winstead

This is how you create a feedback loop that:

• Helps Cursor learn from your patterns
• Prevents repeating the same prompts
• Boosts your dev velocity on autopilot

Let’s walk through the steps together.

Step 1:Define the Foundational Rules

Create cursor-rules.mdc file to teach Cursor how to process, format, and locate other rules in your project. Without it, Cursor is essentially guessing. With it, you're giving it a playbook of your structure and training it to follow it exactly.

File: .cursor/rules/cursor-rules.mdc

Tip: Keep examples relevant and up to date.

Step 2: Create the Self-Evolving Brain

Once the foundational rules are in place, it’s time to add a self-improvement.mdc file to set up the feedback loop. These rules tells Cursor to analyze your codebase over time, learn from recurring patterns, and recommend or evolve new rules.

Photo by ThisIsEngineering

File: .cursor/rules/self-improvement.mdc

Make Rule Maintenance a Habit

Rules are not a set-and-forget operation. Like your codebase, your rule system should evolve with your team, your tech stack, and your workflows. Treat your rules as part of your product.

Here’s how to build a culture of ongoing refinement:

Monitor and Iterate

• Watch PR comments - If reviewers keep pointing out the same issue, that’s a rule waiting to be created.
• Track onboarding questions - When new devs get stuck or ask for clarification, your rules (or docs) probably need an update. Keep track of onboarding questions from new developers
• Update rules after large-scale refactors - Big refactors change structure and logic. Make sure the rules reflect those shifts.
• Cross-reference related rules to improve discoverability - Rules are more useful when they connect to deeper references, examples, or related context.
  
  Photo by Mikhail Nilov

Handle Rule Deprecation

Not all rules age well. And as we all know tech evolves fast so best practices shift as well. Clean out the stale stuff and do it regularly.

• Mark outdated practices - Add a deprecated notice at the top.
• Update deprecated rules - Modernize where possible.
• Document migration paths - If rules are being retired, explain what to do instead and where it’s documented.

Rules should never be a liability. Make them an asset—living documentation that grows smarter and improves with your team and projects.

Follow cursor-rules.mdc for proper structure and consistency.

Wrap-Up

The smartest developers don’t just ship code. They build systems that teach the next dev, the AI assistant, and their future selves how to think.

By connecting cursor-rules.mdc with self-improvement.mdc, you're not just writing rules, you’re building a feedback-powered rule engine that teaches itself, helping your team stay consistent, efficient, and forward-moving.

No more repetitive code reviews. No more retraining your AI every time you switch context. Just structured, automated, and evolving workflows that scale.

Start building smarter today. Let your codebase grow its own brain.

🚀 Deploy your app with SashiDo in minutes. Start your Free Trial Now. And here is a quick Getting Started Guide for a smooth take off.

Happy Coding!

This self-improving rules setup was inspired by real-world examples from danmindru/page-ui open-source repo.

If you liked this post, you might want to also check out:

10 Pro Tips to Master Cursor Agent (and Boost Your Coding Flow)
Vibe Coding with AI Agents: Best Practices for Using Cursor with Node.js and SashiDo - Part 1
Vibe Coding with AI Agents: A Non-Developer’s Journey to Shipping an MVP on SashiDo - Part 2
How to Master Vibe Coding: Best Practices and Useful AI Tool

Every team has a war story about downtime.

It could have been a Friday evening deployment that broke production. Or a sudden traffic spike that took your app offline just as your biggest customer was giving a demo. Or worse - a quiet outage that went unnoticed for hours until users started flooding support with angry emails.

When your app is mission-critical, these aren’t just technical hiccups. They’re business problems: lost revenue, shaken trust, and sleepless nights for your team. This is why, when all hell breaks loose, having adequate and fast support is essential.

At SashiDo, every app comes with a Standard Support Package by default. For most teams, that’s enough to keep things running smoothly with 24/7 monitoring, automated recovery, and our super-friendly human support.

For teams operating mission-critical apps, where every minute counts, we created the Advanced Support Package. It builds on the Standard package and adds faster response times, priority incident handling, direct collaboration with our engineers, and more.

Let’s break down what’s included and when each package makes the most sense.

Standard Support - A Solid Foundation

Every SashiDo app starts with Standard Support at no extra cost. It’s designed to give you peace of mind without added complexity, and it is included within each app’s base fee.

Photo by Yan Krukau

24/7 App Health Monitoring & Auto-Recovery

Your apps are continuously monitored around the clock. If an infrastructure issue appears, our automated recovery mechanisms step in to fix it in the background, often before you’re even aware that anything went wrong. This self-healing layer resolves the majority of infra-related problems without disruption to your users.

Real Human Support & Guidance

When you do need help, you’re never left talking to bots. Our Level 1 support team is staffed by real people who provide practical guidance and basic technical assistance to keep you moving forward.

Reliable Channels of Communication

Email and ticket support come with a guaranteed response within one business day, while live chat is available Monday to Friday during business hours for sales, billing, and general questions. You always have a clear way to reach us.

AI Assistants & Self-Help Resources

On top of human support, every customer has access to SashiDo’s AI Vibe Coding Assistants - pre-configured GPTs that can help you debug Cloud Code, generate functions, manage databases, and optimize performance. And if you prefer to explore solutions on your own, our Developer Docs and Blog tutorials offer best practices, troubleshooting tips, and step-by-step guides.

For the majority of apps, Standard Support is more than enough. The platform’s monitoring and auto-healing systems resolve most infrastructure issues automatically, while human guidance, AI tools, and resources ensure your team has the help it needs, when it needs it.

Advanced Support - The Next Level

Our Advanced Support Package builds on the Standard support included in every SashiDo app. It’s designed for teams that need faster response times, priority incident handling, and closer collaboration, running mission-critical applications where every minute of downtime impacts revenue, users, or trust.

Photo by cottonbro studio

With Advanced Support, you keep all the 24/7 baseline monitoring and auto-recovery from Standard. But on top of that, you get the kind of partnership and priority treatment that makes the difference when quick resolutions and availability matter most.

Here is what’s included beyond Standard:

Critical Incident Response

Faster Response When It Counts

With Standard Support, our team aims to respond as quickly as possible, often much faster than the guaranteed one-business-day window. In urgent cases, we do our best to step in quickly, even outside working hours, but response times may vary depending on availability. Advanced Support, on the other hand, guarantees acknowledgement of your incident within two hours, day or night. It’s a level of responsiveness designed for high-stakes situations, where knowing the clock has started and someone is actively working on your issue provides extra peace of mind.

Fast-Track Recovery During Outages

Downtime on SashiDo’s platform is rare and usually short-lived; most incidents are resolved within two hours and often impact only part of the service. But for mission-critical apps, even short disruptions can hurt. With Advanced Support, your incidents are handled with top priority, so fixes are applied faster and escalations happen immediately. You’re not waiting in a queue; your issue is being actively worked on from the moment it’s reported.

Failover Support During Planned Maintenance

When planned maintenance is necessary, whether for infrastructure upgrades or provider changes, your availability remains top priority. With Advanced Support, we proactively migrate your apps to backup infrastructure ahead of time when needed, so scheduled work doesn’t disrupt your users. You stay online, your launches stay on track, and your business keeps moving without interruption.

Photo by panumas nikhomkhai

Direct Communication & Transparency

Dedicated Slack Channel for Critical Communication

With Advanced Support, you get a private Slack channel connected to our Level 2 Support team. It’s your direct line for faster coordination during urgent situations like critical app issues or infrastructure incidents. You’ll get timely updates, shared context, and quicker decisions, without going through standard ticket queues.

While real-time replies aren’t always guaranteed, your requests are prioritized and handled with full visibility from our senior team.

Post-Incident Reports

When a major platform incident lasts more than one hour, fixing it isn’t enough. In the rare cases that happen, we follow up with a clear, actionable report that explains the causes, the resolution steps taken, and what measures have been implemented to prevent recurrence. These reports aren’t just technical documents - they’re tools you can share with stakeholders, clients, or investors to show transparency, accountability, and a commitment to reliability.

Engineering & Scaling Support

Extra Engineering Help

Support isn’t only about reacting to problems - sometimes it’s about making sure they don’t happen in the first place. With Advanced Support, you get up to four hours per month of dedicated engineering time and an additional hour of architecture consultation. These hours are scheduled in the calendar upon request with our team and can be used for anything from bug fixes and performance tuning to one-off development tasks or custom setups.

Photo by Kevin Ku

Think of this as having a safety net. Whether your dev team pushed a buggy release that locked up production, or you’re prepping for a high-stakes launch and want a safety net, we’re here to help. Our engineers can jump in to debug complex cloud code-related issues, optimize performance, or guide you through custom infrastructure setups, so you’re not troubleshooting alone under pressure.

Proactive Architecture & Scaling Guidance

Scaling a fast-growing app brings its own risks. What worked for a few thousand users might not survive a 10x spike. That’s why Advanced Support includes monthly architecture consultation and tailored monitoring setup, so you can plan ahead instead of firefighting.

Monitoring That Warns You Early

One of the most frustrating ways to discover downtime is through angry users or customer support tickets. With Advanced Support, you’re alerted long before it gets that far. We’ll set up Grafana dashboards to track three key performance metrics for each app and configure proactive alerts when thresholds are reached. This way, you know something’s off before your customers do, and you can react quickly instead of being blindsided.

Pricing

The Advanced Support Package is a prepaid service available for a flat monthly fee of $2,500 per account, covering up to three applications. To keep things smooth, billing is prepaid in three-month cycles. Additional apps can be added for $500/month each.

This makes Advanced Support a strong fit not only for teams with ongoing needs but also for those preparing for specific high-impact events, like product launches, seasonal traffic spikes, investor demos, or major migrations.

Real-world context: Back in 2013, Amazon lost an estimated $1 million in just 15 minutes of downtime. That’s over $66,000 per minute in sales. If your app drives revenue, uptime is more than just a technical goal - it’s a business-critical asset.

Photo by Monstera Production

Standard vs. Advanced Support (At a Glance)

Need to tailor the coverage or add extra services? We’re flexible, just fill in this request form and we’ll work with you to customize the plan.

Who Is Advanced Support For?

Advanced Support is designed for teams running mission-critical apps where downtime directly affects revenue, trust, or compliance. It’s a fit for businesses bound by SLAs who must guarantee reliability to their own customers, for startups and enterprises scaling quickly and needing occasional experts’ guidance, and for developers who are actively shipping new features and want the safety net of faster recovery when mistakes inevitably happen.

Photo by cottonbro studio

A Track Record You Can Trust

Before we wrap up, let’s take a moment to talk about uptime and reliability - because support matters most when things go wrong, but stability matters sooner. It’s not just about how fast we respond. It’s also about how rarely you need to call for help.

That’s why we went back and reviewed every incident and maintenance event logged on our status page over the past two years. The goal? Give you a clear picture of what really happens when something breaks, how fast we recover, and how we’re constantly improving.

Photo by Christina Morillo

At SashiDo, we believe transparency and continuous improvement are the foundation of long-term trust. Here’s what the data shows.

In the past two years, SashiDo recorded 50 events - 43 incidents and 7 planned maintenance windows. The majority were short-lived or low-impact, often resolved before most users even noticed.

From the moment an issue is detected to full resolution, the average response window is 1.5 to 2 hours. In many cases, issues move directly from “Investigating” to “Resolved,” meaning fixes are applied quickly, sometimes before a root cause is formally logged.

A few longer incidents were tied to external dependencies like Docker Hub outages or data center fiber cuts. Others were part of essential internal updates to maintain compatibility, such as our recent maintenance for Apple’s updated APNs SSL certificate requirements.

Across more than 17,500 hours of continuous operation, SashiDo delivered 99.8% uptime. That’s roughly 35 hours of downtime over two years and even that number is conservative. Most incidents only affected a subset of customers or platform features and were resolved in under an hour. No global outages or failures whatsoever.

Even more encouraging is the trend: incident durations are shrinking, and proactive maintenance is increasing. By mid-2025, most issues were resolved in under an hour. We’ve steadily shifted toward pre-emptive infrastructure hardening, API migrations, and other upgrades that reduce risk before it impacts your app.

Bottom line? SashiDo is stable, responsive, and consistently improving. For most teams, Standard Support is more than enough. But if your app is mission-critical and every minute of downtime matters, Advanced Support delivers the added speed, guidance, and peace of mind to keep you covered — no matter what.

Final Thoughts

Ultimately, choosing between Standard and Advanced Support comes down to one key question:

👉 How much does downtime cost you?

If your app can’t afford interruptions, if your business depends on real-time stability, or if your team wants closer collaboration with our experts, the Advanced Support Package is built for you.

With guaranteed response times, priority failover, proactive monitoring, and direct access to engineers, you’ll have peace of mind knowing your app is in safe hands.

Keep your mission-critical apps running at peak reliability - request a quote for SashiDo’s Advanced Support today.

If you're using Cursor as your AI code assistant, you're already ahead of the game. Gone are the days of coding solo in the dark. With Cursor AI, your editor becomes your smartest teammate - one that can read your codebase, suggest improvements, and help you ship features faster and cleaner.

Whether you're a developer working solo, an indie hacker, a startup founder, or a team sprinting on a platform like SashiDo, these tips will help you go from using Cursor to mastering it. Let’s dive into the techniques that will optimize your workflow and enhance your coding rhythm.

1. Use Plan Mode as Your AI Architect

One of the most underused features in Cursor is Plan Mode. It’s designed to take the heavy lifting off your shoulders by generating clear and actionable implementation strategies.

Hit Cmd + N for a new chat, then Shift + Tab to switch into Plan Mode. The agent will:

1. Read and analyze your codebase
2. Understand your app's structure
3. Propose a clean, actionable implementation plan

This is your secret weapon for shipping new pages, integrations, or UI flows without overprompting.

💡 Pro Tip: The best results come when you let the agent take the lead initially. You can always tweak the plan later, but avoid micromanaging the AI from the start.

2. Master the Context Menu

Type @ in the chat to summon a context menu with files, folders, branches, past chats, and docs.

This lets you direct the agent’s attention precisely and avoids context overload.

Whether you're reviewing a specific branch, referencing past conversations, or pulling in errors from a linter, the context menu keeps your development focused and efficient.

3. Create Custom Slash Commands

Define your own workflows with /commands and lets cursor to automate repetitive work.

Create a folder of markdown-based commands like /pr for auto-generating PRs. This is a great way to maintain team standards while freeing up your time to focus on logic and implementation

Automate away the boring stuff so you can focus on the hard stuff!

4. Paste Images for UI Help

Trying to clone a design or get visual inspiration? Paste a UI screenshot directly into the chat and ask Cursor to replicate the layout.

For example, you might say:

*"Make my Top Artists page look like this." *

Cursor will then generate a matching layout, adjusting components and configs as needed. This feature is particularly useful for frontend developers working with SashiDo to quickly prototype screens.

Go from Design inspiration to functional UI, instantly!

💡 Pro Tip: Sometimes, if the LLM doesn’t quite get what you’re trying to explain, it’s much more effective to attach a visual example instead.

5. Duplicate Chats Strategically

Instead of cluttering your main thread with multiple directions, use the duplicate chat feature to experiment. It works like forking your development process - giving you space to test, iterate, and compare results without losing your main conversation.

This strategy is especially useful when exploring alternative solutions to complex UI or backend logic.

6. Watch the Context Window

Your context window is like memory bandwidth - keep it lean for best results when it gets full, quality drops.

To keep the conversation sharp, use /summarize to condense earlier parts of the chat or simply start fresh threads for new features.

Fresh contexts yield clearer, more actionable responses.

7. Monitor Usage Limits

If you're on a metered plan, toggle Usage Summary to track percentage, reset time, and model usage.

Perfect for cost-conscious startups and indie devs scaling efficiently.
Helpful for teams and budget-conscious devs.

8. Learn the Shortcuts

Speed is life. Here are a few favs:

Cmd + I -> Open agent
Cmd + / -> Switch model (GPT-5, Claude, etc.)
Cmd + N -> New chat

💡 Pro Tip: Customize in settings to better fit your flow.

9. Start Fresh Often

Long chats = overloaded context = bad answers.

The best Cursor users treat each chat like a mini sprint: start fresh for each feature or bugfix. This keeps your context clean, responses sharp, and productivity high.

Make it a habit: new feature, new chat. Bugfix? Start another one.

10. Time Travel with Checkpoints

Made a bad change? Roll back effortlessly with Cursor's Checkpoints.

It's like Git for your conversations - perfect for UI tweaks or logic reversions, A/B tests, or quick fixes.

This safety net gives you confidence to explore without fear of losing progress.

11. Bonus Hidden Gems

Here are a few lesser-known features worth exploring:

• Completion Sounds: Audible feedback when the agent finishes responding. Get a "ding" when the agent finishes!
• Mermaid Diagrams: Visualize complex app logic with just a prompt.
• New Layout Beta: Test a new layout with agents on the left, code in the center, and diffs on the right

Fin

Cursor isn't just another AI assistant. It's your coding co-pilot that understands your code, proposes implementation plans, and helps you ship clean, production-ready features faster.

The most effective Cursor users aren’t the ones who type the most prompts. They’re the ones who guide the agent smartly - using structure, context, and the right tools at the right moment.

So whether you're hacking together a new MVP, improving UX, spinning an MCP server or scaling a SaaS on SashiDo, these Cursor strategies will help you focus on what really matters - building great products!

🚀 Ready to take your AI-assisted development even further? Deploy your app with SashiDo in minutes. Start your Free Trial Now. And here is a quick Getting Started Guide for a smooth take off.

If you liked this post, you might want to also check out:

Vibe Coding with AI Agents: Best Practices for Using Cursor with Node.js and SashiDo - Part 1
Vibe Coding with AI Agents: A Non-Developer’s Journey to Shipping an MVP on SashiDo - Part 2
OpenAI’s New Apps SDK (Preview): What It Means and How to Experiment
How to Master Vibe Coding: Best Practices and Useful AI Tool

OpenAI just dropped something big - the new Apps SDK, a toolkit that lets developers build fully interactive apps inside ChatGPT.

If that sentence alone made your brain spark with “wait… what does that even mean?”, you’re not alone.

Let’s unpack what we know so far, what it could mean for developers, and how you can start experimenting, especially if you’re already building on SashiDo or another mBaaS platform.

What the Apps SDK Actually Is

The Apps SDK is OpenAI’s way of turning ChatGPT into a platform, not just a chatbot. Instead of relying on a plain API integration, developers can now build apps that live inside ChatGPT and respond to users in real-time.

Think of it like giving your backend a front-row seat in the conversation.

With the Apps SDK you can:

• Define tools your app exposes (e.g. fetch data, trigger actions, send updates)
• Build interactive UI components - cards, tables, even full-screen layouts
• Use the Model Context Protocol (MCP) to connect ChatGPT with your external APIs
• Handle authentication, state, and logic in your own backend
• Monetization is expected via Instant Checkout and the Agentic Commerce Protocol; app submissions open later this year.

Photo by Solen Feyissa on Unsplash

The Apps SDK is currently in preview, meaning it’s an early-access version still evolving. It’s available to some developers, but not everyone can use it yet. If you’re amongst the lucky ones, you can experiment with it today, but expect changes and limited availability as OpenAI continues testing and rollout.

The docs are live on developers.openai.com, and it’s very early days, but the implications are huge, and interest around it is already loud.

⚠️ Note: What this isn’t (yet): Not GA, limited regional availability, evolving APIs, and discovery/monetization still in progress. Build prototypes, not production.

Why You Should Care

For anyone who builds products with GPT-based functionality, this unlocks an entirely new layer of distribution and UX.And if you’re just exploring GPT-powered UX, this is worth a look.

Here are just a few reasons you might want to consider:

Reach new users directly inside ChatGPT.

Hundreds of millions of people(some reports estimate ~800M) use ChatGPT every week. Apps SDK lets them invoke your service by name or discover it through ChatGPT’s suggestions. This goes beyond SEO, GEO, or any kind of content optimization.

Build a conversational UI without building a chat UI.

Your users can talk to your app naturally. ChatGPT handles the conversation, context, and follow-ups. You just focus on logic and data. And if we have to be honest, some users are already doing this, so why not make it an even smoother experience?

Photo by Solen Feyissa on Unsplash

Reuse your existing backend.

You don’t need to reinvent your infrastructure. Or at least it looks like it at this point, as this is a preview version only, and surely it will evolve. Seems that if you already have APIs, data models, and logic running on your backend, you’re halfway there.

Open door to future monetization.

OpenAI hinted at an upcoming “Agentic Commerce Protocol” and instant checkout flow for paid apps. Early builders will likely have the advantage when that ecosystem matures. Back in the days, OpenAI mentioned monetization for GPTs as well, but so far, we haven’t seen the release of a direct way to do this. This time, the claim sounds stronger, so I do believe it’s worth the early bet.

⚠️ Note: The Apps functionality in ChatGPT is already available to all logged-in ChatGPT users outside of the EU on Free, Go, Plus, and Pro plans. Amongst the first apps are Booking.com, Canva, Coursera, Figma, Expedia, Spotify, and Zillow in English-speaking markets. More pilot apps are expected to launch by the end of the year, bringing apps to EU users is defined with the vague “soon”.

But… You’ll Still Need a Backend That Scales

Here’s the catch: Apps SDK handles the front-end experience inside ChatGPT, but all the real work - fetching data, running logic, processing actions - still happens on your servers.

That means your backend needs to be reliable (no timeouts or lag - users won’t wait), secure (handle tokens, data, and permissions cleanly), flexible (connect to APIs, store state, run business logic), and of course - easy to extend as you iterate

Photo by ThisisEngineering on Unsplash

According to the officially released docs, OpenAI’s Apps SDK is essentially a client/runtime + protocol (MCP) that invokes standard web APIs. Most managed backend providers already provide and scale such web APIs. So the capability is architectural, not a product toggle, and those backends should be compatible by design.

If you’ve selected SashiDo for your backend, please contact us at support@sashido.io so we can discuss and advise if and how your use case can be implemented.

What to Do Next

If you’re curious about experimenting with the Apps SDK, here’s a simple way to start:

1. Check access to the Apps SDK preview

In ChatGPT, go to Settings → Connectors → Advanced and toggle Developer mode(some accounts show ‘Apps & Connectors’ → Advanced → Developer mode). If you see it, you can start building right away. If you don’t see Developer mode, you may need to be added to the current developer experiment or (for Enterprise) ask your workspace admin to enable connector creation.

2. Start with the official examples

Clone the Apps SDK examples and run them locally. Expose your local server securely (e.g., via ngrok) so ChatGPT can reach it while you iterate. This is the fastest way to understand the server ↔️ ChatGPT loop.

3. Plan your backend approach (keep it tiny at first)

Any HTTPS server can speak MCP (the protocol the Apps SDK uses). Begin with a single, well-scoped tool (one endpoint, one job), add logging, and version your payloads so you can adapt as the preview evolves.

4. Link it in ChatGPT and test

In ChatGPT, Settings → Connectors → Create, point to your HTTPS server, and link it in Developer mode. Run “golden prompts,” record which tools fire, and iterate.

⚠️ Reminder: The Apps SDK is in preview - APIs and UX may change(OpenAI notes app submissions open later this year.). Plan for iteration and keep your rollout gated behind Developer mode while you experiment.

Fin

The Apps SDK is new and in preview. We haven’t shipped production apps with it yet, and that’s intentional. It will change, and that’s what makes it worth exploring. If you’re curious, start small: wire one narrowly scoped MCP tool, measure latency and UX, and learn. We’re doing the same on our side.

SashiDo is a managed mBaaS that allows you to spin up APIs fast, simple & with minimal budget as our prices start at $4.95/mo per app. We believe our platform can become the perfect playground for such experiments, so we’re open to collaborating with you and exploring this new and uncharted path together.

👉Have a use case? Send a short paragraph to support@sashido.io and we’ll suggest a lean experiment plan.

👉Want a place to tinker? Spin up a project on SashiDo’s free trial and prototype an MCP tool against a tiny endpoint.

Curious, cautious, experimental - that’s the energy. Let’s see what this new surface can unlock together.

Useful Links:
Official release announcement form OpenAI
Apps SDK official docs
Announcement for OpenAI's Apps in Techcrunch

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:

1. 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."
   
2. I opened a new project in Cursor. Ensure the model is set to Claude 3.7 Sonnet Thinking.
3. Pasted my spec into the chat window.
4. 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.
5. 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:

1. Guard the offline code and focus on online-only
2. 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!

It's been a long time, and we want to thank everyone who's been waiting patiently. Parse Server version upgrades have been one of the most frequent requests on our Standard plan, and we're finally ready to take the next step forward together.

But before we dive into the what and when, let’s talk about the why. The path that brought us here is just as important as the milestone itself.

A Strategic Shift: Betting on Growth, Without Leaving Anyone Behind

Back in 2020, during the COVID-19 pandemic, we saw some of our customers unfortunately shut down, some hit a plateau, but many others began growing - and growing fast. That growth showed us where our platform could make the biggest difference and, at the same time, persist through the challenging times as a business ourselves. So we made a strategic choice to focus our efforts on supporting those customers who were positioned for rapid scale as the pandemic reshaped the market. In simple words, times were uncertain for all of us, and we chose to make a bet on where we saw growth potential, while continuing to deliver the same reliable service our customers count on.

What This Meant for Our Customers

These rapidly growing apps had specific infrastructure and feature requirements that couldn't be easily supported on the shared infrastructure offered in our standard offering. That led us to prioritize building dedicated, high-performance environments where we could provide more flexibility, faster updates, and hands-on support.

This is why new Parse Server versions were rolled out only on dedicated setups where this was explicitly requested over the past few years, as most of those customers had quite different requirements and priorities from one another.

We know this pause in version upgrades on Standard plan wasn’t ideal for everyone. For teams running stable apps without major growth spikes, newer versions of Parse Server still mattered. And yes, we lost a few customers due to this tradeoff. But we didn’t just sit on our hands all those times, and even though we had to make some difficult decisions, we managed to excel and persevere during a global disruption. We kept our services fully operational for thousands of apps, supported mission-critical workloads, and ensured consistent performance for businesses with spiking growth in those uncertain times.

What We Delivered in the Meantime

Despite the pause in version bumps, we also didn’t stop improving the platform:

• Maintaining the best pricing on the market, using the flexible pay-as-you-go model.
• Absorbing major cost increases - like 150%+ growth in DB hosting expenses - without raising your rates.
• Delivering 99.99% uptime, even during global disruptions like the supply chain crisis and the Russia-Ukraine conflict.
• Flexible payment options for customers from countries where COVID and Russia-Ukranian conflict had an impact on the bank system
• Multiple infrastructure maintenance and upgrades without major service interruptions to ensure everything runs smoothly.
  

Photo by Andrea Piacquadio

And a steady stream of platform upgrades at no extra cost, including:

• Micro CDN Upgrade - faster content delivery, better reliability.
• Increased File Upload Limits - from 20MB to 60MB, free on request up to 3 times per account.
• Push Notification Upgrade - support for Google FCM v1 API.
• MongoDB Server Enhancements - smoother DB operations.
• Custom Solutions and Advanced Support - tailored help when you need it.

And last, but not least, we managed to protect our entire team(we didn’t cut costs by losing people) and remain a trusted partner to our customers during uncertain times like the COVID pandemic.

These foundational improvements laid the groundwork for the upgrades we’re releasing now - and the ones that are just around the corner.

What's Changing Now?

We’re excited to share that Parse Server Version 4.1.0 will be available in experimental mode on SashiDo's Standard plan by mid-September 2025. The update is compatible with the current infrastructure. This is a big step forward, and we appreciate the patience and understanding from everyone who’s asked about version upgrades over the past few years.

Photo by Ann H

What Does "Experimental Mode" Mean?

This release will be opt-in for standard plans and is intended for testing and feedback. Although it's technically in experimental mode, version 4.1.0 is stable and production-ready for most use cases. We're looking to validate its performance across a wide range of app configurations before making it the default.

Your feedback on how the new version performs in your environment is not just welcome, but valuable and highly-appreciated. It will help us move faster and ensure the update meets the high standards you expect.

What to Expect Next?

If your app runs on the standard plan and you’re ready to test Parse Server 4.1.0, keep an eye on your Dashboard and announcements. We’ll roll out opt-in access by mid-September 2025, and we'll be sending additional guidance on how to upgrade your apps as smoothly as possible.

Looking ahead, we’re also preparing support for a newer Parse Server Version that depends on enhancements in the underlying data infrastructure. These improvements will bring even greater stability, performance, and scalability, but they’ll require a bit more than just a version bump.

Once testing phase of the infrastructure is complete, we’re aiming for a full rollout of the latest stable Parse Server version by the end of Q1 2026.

We Appreciate Your Continued Partnership

We truly appreciate your trust and support through this journey. Your feedback and persistence have helped shape this update. During this experimental phase, we’d love to hear how 4.1.0 performs for your apps.

If you require newer versions sooner or want the perks coming with a custom setup, we can deploy the latest Parse Server versions on a dedicated environment upon request. Just fill in the official form, and our team will contact you with the details right away.

Happy Coding!

The SashiDo Team

AI-powered software development is entering a new phase - one where you're not just getting code suggestions or autocomplete. You’re building entire features and even complete apps with minimal manual input. Welcome to Vibe coding: a radically efficient way of working where you collaborate with intelligent agents to do the heavy lifting.

In this blog post series, I’ve been using Cursor - a cutting-edge IDE designed for agentic workflows - to quickly spin up full-stack Node.js applications on SashiDo. Our team has tested a bunch of different approaches to make sure this setup is smooth, stable, and easy to follow. Easy enought that a Product and Business Dev like me can follow it.

So instead of spending hours figuring things out on your, you can just follow my lead and get building right away. I’ll walk you through what works best, what to watch out for, and how to get the most out of both Cursor and SashiDo - step by step through the lense of a non-developer.

TABLE OF CONTENTS

WHAT IS VIBE CODING

SETTING UP FOR VIBE CODING WITH CURSOR

• To Set Up a Model in Cursor:
• Use Rules - Seriously

ESSENTIAL CODING RULES AND PREFERENCES

• General Rules
• Coding Workflow

IINTERACTION AND EXECUTION MODES

• Interaction Modes
• Execution Modes

BEST PRACTICES

• Keep Context Clean
• Keep Prompts Small and Targeted
• Testing: Integration Over Unit
• Bonus Tips for a Smooth Vibe Coding Workflow

WRITING A DETAILED SPEC AND HOW TO USE IT

FINAL THOUGHTS

What Is Vibe Coding?

Vibe coding - also called agentic coding - is using an AI agent(in tools like Cursor or Windsurf) to build your app with you, not just finishing your lines of code, but generating entire features, testing them, and even deploying. You're not typing everything out - you’re giving the AI instructions, watching it work, and stepping in to guide when needed.

Think of it like being a movie director. You’re not holding the camera or setting up the lights - you’re saying: “Make this scene happen. Use this style. Keep the tone consistent.” The AI? It’s your production crew, pulling it off.

With tools like Cursor and Windsurf, you're collaborating with agents that can read your spec, understand your rules, and build entire apps end-to-end. It’s not perfect, but when it clicks, it feels like magic.

Setting Up for Vibe Coding with Cursor

For the next steps, I’ll use a free plan on Cursor Version: 0.50.5, VSCode Version: 1.96.2 and Claude 3.7 Sonnet models. These models support agentic behavior really well, including tool calling and function execution.

To Set Up a Model in Cursor:

• Go to Cursor settings
• Choose from the predefined models or add any model that you like from the “Add Model” button
• If you like, you can add a custom model by overriding the OpenAI API Key with a custom one (e.g., from Groq) using the OpenAI API standard formatting. To do that, you turn on the OpenAI API Key, you add your own key, and then override the base URL.
• You can only set one custom base URL at a time.

Regardless of your model choice, make sure it supports function calling and agent-style behavior. I used Claude 3.7 Sonnet Thinking - a hybrid reasoning model that supports both fast responses and deeper ‘thinking’ via its extended mode. You might not see a separate model called Claude 3.7 Sonnet Thinking in the Dropdown menu(availability may vary based on your Cursor version or plan) - it’s actually a feature of Claude 3.7 Sonnet that enables deeper reasoning when needed. To activate extended thinking in Cursor go to Settings → AI Models → Select all Claude 3.7 Sonnet as your model.

Use Rules - Seriously

Before actually pasting any specs and prompts in Cursor, it’s key to define our coding rules (especially as the codebase gets larger). Cursor and Windsurf both support them. In simple words, the rules are a way to tell AI, the agent, how you want to code, what technologies you should use, what workflows you want to use, etc.

These rules are essentially system messages for your agent. You can set up:

• Global user rules(applicable to all your projects)
• Project-specific rules (apply only to a specific project, recommended)

They’re stored in .cursor/rules/ and written in .mdc files. You can reference those files as a system message for the AI to work with. The rules help prevent the AI from doing weird things, like switching your storage backend mid-session or building or debugging using technologies that are not within your stack.

Essential Coding Rules and Preferences

Here’s what I kicked off my journey with and what SashiDo’s team recommends adding to almost every project formatted in all natural language descriptions:

General Rules:

• Always prefer simple solutions. - Complex solutions often lead to more bugs, harder debugging, and longer development cycles. Simplicity ensures that the AI generates maintainable code you can reason about quickly.
• Avoid code duplication whenever possible and always check if similar code or functionality already exists. - The agent tends to add new code even when similar logic already exists. This leads to bloated codebases and harder-to-maintain functionality. The rule reminds the agent to check before generating redundant code.
• Use separate environments for Dev, Test, and Prod - Without this rule, the AI could accidentally mix environments, like writing tests that affect production data or using local files in production. This separation is key for stability and debugging.
• Only make changes that are requested or are clearly related to the requested changes. - The agent can sometimes fix one issue and change three unrelated things, breaking other functionality. This rule keeps the agent focused and prevents “collateral damage”.
• When fixing bugs, don’t introduce new patterns or technologies unless you've exhausted the current implementation, and if you do, remove the old code. - The AI sometimes “solves” problems by switching to a completely different tech (e.g., from SQL to JSON file storage). This rule forces it to stick to the original design unless a change is unavoidable, and prevents hybrid solutions that create confusion.
• Keep the codebase clean and organized. - AI-generated code can get messy fast. This rule helps ensure files are properly structured, logic is modular, and things stay readable over time.

Photo by Ibrahim Yusuf on Unsplash

• Avoid scripts and one-off files unless absolutely necessary. - The AI often leaves behind one-off test or debug scripts, cluttering the project. This rule tells the agent to clean up after itself or execute inline.
• Avoid long files (over 200–300 lines); refactor early. - Long files are harder for the AI to understand and refactor later, often leading to broken tests. Preemptive refactoring reduces complexity and keeps things modular.
• Avoid mock data in Dev/Prod, only allow it in test. - When something like a web scraper fails, for example, the AI can silently fall back to fake data and pretend things worked. This leads to false positives and hidden bugs in production.
• Never overwrite .env or hardcode secrets without first asking and confirming - The agent sometimes replaces or edits environment files during testing, breaking access to APIs or databases and forcing the user to regenerate keys.
• Stick to my stack: Node JS v18 backend, MongoDB v3.6, SashiDo backend, Parse Server v3.6.0 HTML/JS frontend, separate DBs per environment - Without this, the AI is left a lot of space to improvise, so be as specific as possible versions included - e.g., switch from SQL to local file storage. This rule locks in tech choices and ensures consistency across the app.

Coding Workflow:

• Stay focused only on the code relevant to the task stated in each prompt and do not touch code that is unrelated to this task. - The agent would often wander into unrelated parts of the codebase, creating bugs or introducing inconsistencies. This rule keeps its attention where it's needed.
• Write thorough tests for all major functionalities. - We’re all human, and now and then, we can forget best practices like always requesting tests, and the AI wouldn’t write them by default. This rule ensures test coverage is always included.
• Keep the codebase clean and DRY. - The AI has a tendency to create redundant functions or reimplement logic it didn’t realize already exists. Over time, this leads to duplication, inconsistent behavior across the app, and a messy codebase. By explicitly telling the agent to keep things DRY, you help it reuse existing code, maintain a single source of truth, and prevent conflicting logic or edge case errors. This rule reinforces once again the need for maintainability and clarity, especially important in longer sessions where the AI might lose track of previous implementations.
• Avoid major changes to working patterns and the architecture of how a feature works, after it has been shown to work well, unless explicitly instructed. - Sometimes the AI would rewrite an entire module or feature just to fix a small bug. This rule prevents unnecessary overhauls.
• Always consider the ripple effect of any code change and how changes might affect other parts of the code. - The AI doesn’t always grasp the full impact of a change. This rule forces it to think more holistically before editing core logic.

Those are the rules I’ll be adding on Project-specific level for the purposes of my experiement in building a full-stack all by myself with the help of AI. You can always add more and give it as many instructions as you see fit.

Understanding why setting up these preferences initially is necessary would hopefully save you a lot of time. Those rules kind of reflect some of the tendencies these AI coding agents have that don’t really work all that well. Hopefully, with the advancement of AI, most of them will become obsolete, but until then, we’ll stick to the lengthy list and add more as needed.

Interaction and Execution Modes

When working with AI in Cursor, it's also helpful to understand that there are two layers of interaction modes:

Interaction Modes

Cursor gives you several ways to interact or "talk" with the AI assistant, depending on what you’re trying to do:

• Edit Mode - Highlight any block of code and tell Cursor what to do - like "Change this code", "Optimize this function" or "Add error handling". It will rewrite that section based on your instructions.To enable it go to Highlight → Right-click → “Edit with Cursor” or Cmd+K / Ctrl+K

• Ask Mode - Use the Ask panel to pose open-ended questions, like "Explain or guide me to...", “What does this function do?” or “How can I structure a REST API?”. The AI replies with suggestions or explanations, without changing your code. To enable it go to Sidebar → “Ask Cursor” or Cmd+Shift+K / Ctrl+Shift+K

• Autocomplete (Inline Suggestions) - As you write code, Cursor proactively offers completions - from full lines to entire functions. This is the default behavior, so suggestions pop up as you type (can be configured in settings).

In a nutshel, Edit Mode is perfect when you know exactly what you want to change - quick refactors, bug fixes, or applying a known pattern; Ask Mode shines when you're exploring or need guidance - learning, debugging, or getting unstuck; and Autocomplete keeps you in flow as you build features or write boilerplate code. Choosing the right interaction mode helps you stay efficient no matter what's your end goal.

Execution Modes

When you ask Cursor to do something, especially through agents or multi-step operations, you decide how hands-on or hands-off you want to be.

• Manual - "Always ask before changing anything.” - The AI proposes changes, but pauses before applying them. You review and approve every action.

• Auto Mode – "Decide when to ask and when to act" - Cursor evaluates the risk level and either applies changes automatically or asks for confirmation if needed.

• Auto-Run mode(also known as YOLO) – "Just do it, no questions asked" - Short for “You Only Live Once,” YOLO mode gives Cursor full control - it applies code edits, runs agents, and even triggers commands (like tests or deploys) without asking. Please be mindful as this mode is not recemended and can be dangerous in production environments.

You can enable or switch between Manual, Auto, and YOLO execution modes via:
Command Palette (Cmd+P) → Search for execution mode or Settings → AI Agents → Execution Mode

To sum it up, Manual mode gives you full control and peace of mind - perfect for sensitive or production code. Auto mode strikes a smart balance by letting Cursor handle low-risk tasks while still checking in when needed, whcih makes it sutiable for iterative development or trusted workflows. And YOLO mode? It’s your go-to for fast iteration, early prototyping, experiments, or solo projects, but definitely not the one to trust near live systems. Choosing the right execution mode means moving fast when it’s safe, and staying cautious when it counts.

Best Practices

Keep Context Clean

One of the most important things to stay on top of when vibe coding is context management. Cursor has a limited context window, and as your session grows(adding more files, rules, and chat history), the AI’s performance starts to drop. It might miss important details, get confused, or behave unpredictably. I found out that once too much context had built up, the agent’s ability to reason effectively degraded noticeably. That’s why it’s crucial to recognize when a session is getting too “heavy.” When that happens, the best move is to start a new chat, but keep in mind: you’ll need to manually reinsert your spec and rules because they don’t carry over automatically. You’ll also need to be mindful that the overall context from the previous chat is lost, and you might be more explanatory, even repetitive, in your initial prompts in a new chat.

Photo by Samir Malek on Unsplash

Here are a few quick examples that show Cursor is overwhelmed and you might need to start a new chat:

• Inaccurate Context Handling: Cursor may forget previous steps or misunderstand your intent, especially in long conversations or if multiple files are open.
• Delayed Suggestions or Freezes: A noticeable slowdown in response time or missing completions can mean Cursor is overloaded or your local setup is under strain.
• Empty or Incomplete Edits: Sometimes, you’ll trigger a refactor or ask for code and receive a partial or blank response. This is usually a sign the model hit a context or token limit.
• Vague Error Pop-Ups: You might run into generic “Something went wrong” messages or unexplained failures when trying to use Cursor’s features. These, similarly to the previous point, often indicate that the assistant hit a limit or got stuck behind the scenes.
• "Lost in the Sauce" Moments: If the AI starts generating code that clearly doesn’t fit your file, stack, or logic, it's likely confused and needs a reset.
• Endless Loading or Spinning Cursor: Sometimes Cursor just hangs, stuck on “thinking” without producing any output. If it’s spinning forever, it’s usually time to refresh or simplify your request.

Keep Prompts Small and Targeted

Equally important is to keep your prompts focused and narrow. Don’t ask the AI to do too much at once. Instead of piling on complex requests, stick to one small change at a time: fix a bug, add a feature, write a test. This bite-sized, incremental workflow helps maintain stability and gives you more predictable, testable results. I repeatedly emphasized in this tutorial how broader instructions often lead to the agent making unrelated changes, duplicating code, or breaking working functionality. Keeping the scope tight not only prevents that but also gives you better checkpoints to roll back to if something goes wrong.

Testing: Integration Over Unit

Test as much as you can and have the agent write tests. I've found that end-to-end tests (where the agent clicks through real app flows) work better than unit tests. So write tests often and run them constantly. If a test fails, have the agent fix the test, but watch it closely. Sometimes it’ll “fix” the test by rewriting real functionality. Make sure it understands the intent and if needed, go to the app yourself and test that functionality yourself.

Bonus Tips for a Smooth Vibe Coding Workflow

To keep your vibe coding sessions stable and recoverable, it’s crucial to commit often. Frequent commits let you roll back cleanly using Git if something breaks beyond repair. But even beyond version control, Cursor itself tracks chat history, and you can restore earlier checkpoints with a single click. This built-in safety net makes experimentation much less risky.

Photo by Kevin Ku

Another bonus tip is to run multiple branches in parallel, especially when the AI is slow or tackling large changes. You can spin up multiple Cursor windows, let each agent work on a different task or feature branch, and later merge everything together.

Finally, when quality matters, favor “Thinking” models like Claude 3.7 Sonnet Thinking. While they’re a bit slower, the tradeoff in accuracy, context awareness, and reasoning is usually worth it - especially for complex logic or larger codebases. These habits might seem small, but they make a big difference when working with autonomous agents.

Writing a Detailed Spec and how to use it

Now that you’re familiar with the main best practices of working with Cursor, I recommend writing a detailed technical spec. And since in this experiemnt we keep things simple and non-developer friendly, I used SashiDo’s Mobile App Feature Planner GPT to help write it. For example, I’ll prompt:

Write a spec for a simple To Do app. Be as specific as possible. We're going to be using Node.js and SashiDo as a backend.

It’ll output technical specs, database schema, API endpoints - everything you need. Then, I copy that and paste it into a new Cursor window and prompt the agent with:

Build this based on the spec above.

You can add instructions like “Start with setting up the folder structure and database schema.” if you want a specific entry point.

That’s it. The agent will begin planning and coding according to your spec. Just remember: the first step sets the tone for the entire session - be clear, complete, and intentional with your input.

Final Thoughts

Vibe coding isn’t just a trend - it’s quickly becoming a smarter, faster way to build real-world apps. With the right setup, clear rules, and focused prompts, working with agents in Cursor can feel less like typing code and more like directing a build crew...and for non-developers like me - like pure magic.

This post was Part 1 of our hands-on blog post series, where I share all the best practices for collaborating with Cursor effectively while experimenting with the tool and picking my Dev colegues's brains continiously. In Part 2, we’ll roll up our sleeves and actually build a full-featured To-Do app together using SashiDo as the backend, applying everything I covered here in a real-world scenario. I'll share my unflitered journey what Broke, what worked, and how I shipped an MVP on SashiDo using AI.

Stay tuned - and if you haven’t already, try writing your first spec with SashiDo’s Mobile App Feature Planner GPT and loading it into Cursor. It's not perfect yet, but this is the worst these tools will ever be. They’ll only get better from here, and you might be surprised how much you can build without actually writing any code.

Keeping your users informed builds trust and during critical moments, it matters more than ever. When something goes wrong - servers crash, the app won’t load, the database misbehaves - it’s not just a technical issue. It’s a communication challenge. Tickets and notifications start piling up. Teammates scramble. Customers worry. That’s why clear, timely updates are just as important as fixing the problem itself. The way you handle these moments can shape your business' reputation and strengthen your team’s efficiency.

That’s exactly where Opsie comes in.

Opsie is an AI-powered assistant built for anyone managing critical applications with public-facing status pages. It automates the translation of raw DevOps data (logs, alerts, tickets, timelines) into clear, tailored communications for every audience. Whether you're writing a tweet, a customer support reply, or an internal report for management, Opsie helps ensure your message is accurate, consistent, and on-brand.

The Challenge

During an incident, various stakeholders rely on timely and well-tailored updates. Support teams need deeper technical context, but with simplie and understandable wording, so they can respond to user concerns accurately. Management depends on high-level summaries that help guide decisions and prioritize resources. End-users simply want clear, concise updates that explain what’s happening and how they’re affected. Meanwhile, your social media followers expect quick, informative posts that keep them in the loop without causing alarm.

Manually crafting all of these messages - especially under pressure - can be overwhelming and slow.

Photo by Sebastian Herrmann on Unsplash

Meet Opsie

If you've ever scrambled to write a service update during an incident, you know how hard it is to strike the right tone. Should it sound technical or simple? Empathetic or direct? Formal or casual?

Opsie is an AI-powered assistant designed to ease the communication burden during DevOps incidents. It's built for Developers, Support, and DevOps Teams. Working seamlessly along your SashiDo-hosted applications, Opsie analyzes complex incident data form SashiDo logs and generates clear, audience-specific messages.

Opsie removes the guesswork. Here is how a typical chat starts:

Key Features

Real-Time or Retrospective

Opsie is helpful during both live incidents and post-incident reviews. Whether you're triaging in the heat of the moment or crafting a follow-up summary for your support team, Opsie brings clarity and professionalism.

A Trustworthy, Professional Voice

High-pressure situations demand cool heads and clear words. Opsie delivers both. It speaks with the confidence and reassurance your audience expects, while saving your team valuable time.

It even includes helpful resources from trusted SashiDo and Parse documentation when relevant.

Automated Summarization

Opsie converts complex logs, alerts, and timelines into concise, readable summaries. It ensures you never miss the critical details users and stakeholders care about, even under pressure.

Audience Tailoring

From public status pages to internal tech reports, Opsie customizes your message format and tone for the intended audience - ensuring clarity, empathy, and relevance every time.

Photo by Flipsnack on Unsplash

Multilingual Support

Need to communicate with a global user base? Opsie can translate your incident communications, so you can keep users informed in multiple languages.

Consistent, but Tailored Outputs for Every Channel

Opsie doesn’t just send out messages - it understands the nuance behind each type of communication. A status page update calls for calm and clarity, phrased in a way that's safe and transparent for public view. A support email, on the other hand, needs a friendlier, more empathetic tone, paired with just the right amount of technical detail to reassure users. When it comes to social posts, Opsie keeps things short, confident, and accessible, avoiding jargon and panic. For internal reports, it shifts gears to deliver structured, focused updates rich in technical insight to help teams act quickly and effectively.

No matter the channel, each message from Opsie consistently includes the key details people need: the incident’s timestamp, a clear explanation of the root cause or suspected issue, the current status and scope of the impact, a summary of the actions taken so far, and the next steps or an estimated resolution time. It’s a clear, professional approach that keeps everyone informed and reassured - without the communication overhead.

How Opsie Enhances Your Workflow

By integrating Opsie into your incident response process, you can:

• Reduce response time: Cut down the time needed to inform stakeholders - no more scrambling to write from scratch.
• Improve accuracy and consistency: Ensure your messaging is always clear, accurate, and aligned with your brand tone.
• Follows your tone: Whether the audience is users, teammates, or execs, Opsie adapts the language to a suitable format.
• Enhance user trust: Keep users informed and reassured with timely, thoughtful updates that show you’re in control.
• Free up resources: Allow your technical teams to focus on resolving the incident rather than crafting messages.

Photo by Alex Knight on Unsplash

Getting Started with Opsie

Integrating Opsie into your workflorw is straightforward: just follow the link to access the Opsie GPT interface, then paste in your incident data - such as logs or a brief summary. Next, select your intended audience, whether it’s your users, support staff, or internal stakeholders. Let Opsie generate the appropriate message, review the output, and make any final tweaks before sending.

By following these steps, you can ensure efficient and effective communication during critical times.

Fin

Whether you're a solo developer or part of a global support team, Opsie empowers you to communicate with clarity and confidence. No more scrambling for the right words - just fast, professional updates every time you need them.

For more insights on optimizing your application's performance and user experience, explore our Getting Started Guide.

If you have any questions or need assistance integrating Opsie into your workflow, feel free to reach out to our support team. We're here to help you make the most of your SashiDo experience.