# Rollback Strategies

## Why Rollback Matters

When building with Buzzy AI v3, things sometimes don't go as planned. Being able to safely undo changes is crucial for confident development.

**Non-technical explanation**: Think of rollback like a time machine for your app. Just as you might save different versions of a Word document before making major edits, Buzzy's version control lets you jump back to any previous working state of your app if changes go wrong.

**Common scenarios requiring rollback**:

* A Buzzy AI v3 prompt causes unexpected changes to your app structure
* New features accidentally break existing functionality
* Performance degrades after adding features
* Data model changes create cascading issues
* You realize your approach was fundamentally flawed
* Deadline pressure requires reverting to last stable version

**Why rollback capability is essential**:

{% @mermaid/diagram content="%%{init: {'theme':'default', 'themeVariables': {'fontSize':'16px'}}}%%
graph TD
A\[Confident<br/>Experimentation] --> B\[Try New Approaches]
B --> C{Does it work?}
C -->|Yes| D\[Keep Changes]
C -->|No| E\[Rollback Instantly]
E --> A

```
style A fill:#6c6,stroke:#333,color:#000
style D fill:#6c6,stroke:#333,color:#000
style E fill:#f88,stroke:#333,color:#000" %}
```

**With good rollback strategy**:

* ✅ Experiment fearlessly knowing you can undo
* ✅ Try ambitious features without risk
* ✅ Quickly recover from mistakes
* ✅ Maintain stable versions for production
* ✅ Test changes without fear of permanent damage

**Without rollback strategy**:

* ❌ Fear of making changes
* ❌ Stuck with broken versions
* ❌ Wasted hours trying to fix forward
* ❌ Lost work from catastrophic changes
* ❌ Stress and anxiety during development

## When to Rollback

Making the right decision about whether to rollback or fix forward is critical. Here's a clear decision framework:

### Decision Framework: Rollback vs Fix Forward

{% @mermaid/diagram content="graph TD
A\[Change Caused Issues] --> B{App Still<br/>Functional?}
B -->|No - Broken| C\[🔴 ROLLBACK NOW]
B -->|Yes - Has Issues| D{Can Fix in<br/>< 30 mins?}
D -->|Yes| E\[🟢 FIX FORWARD]
D -->|No| F{Understand<br/>What Broke?}
F -->|Yes| G{Worth the<br/>Fix Effort?}
F -->|No| C
G -->|Yes| E
G -->|No| C" %}

### Clear Rollback Situations

**1. 🔴 Breaking Changes - ROLLBACK IMMEDIATELY**

**Critical failures**:

* App won't load in preview mode at all
* Database/Datatable structure is corrupted
* Critical security vulnerability (e.g., Viewers fields accidentally removed)
* Data loss or corruption occurred
* Multiple core features stopped working simultaneously

**Action**: Stop everything. Go to Versions tab. Restore immediately. Don't try to fix.

**Example scenario**:

```
You prompted: "Reorganize all Datatables"
Result: App won't load, seeing errors everywhere
Decision: ROLLBACK - trying to fix would take hours
```

**2. 🟡 Can't Fix Forward - ROLLBACK AND REASSESS**

**When you're stuck**:

* Tried 3+ different AI prompts, issues getting worse
* Don't understand what Buzzy AI changed in the Data or Design tabs
* Fix would require rebuilding 5+ screens or restructuring Datatables
* Deadline is tomorrow, need working version now
* Each attempted fix creates new problems

**Action**: Rollback to last stable version. Take a break. Reassess your approach with fresh eyes.

**Example scenario**:

```
Attempt 1: "Fix the navigation" - made it worse
Attempt 2: "Undo that and fix properly" - still broken
Attempt 3: "Reset navigation to default" - now homepage broken too
Decision: ROLLBACK - you're digging deeper into a hole
```

**3. 🟠 Wrong Direction - ROLLBACK AND RESTART**

**Strategic pivots**:

* Realized data model approach is fundamentally flawed (e.g., should have used Subtables not Linked Fields)
* Requirements changed significantly mid-development
* App structure became over-complicated, simpler approach exists
* Prototype revealed better way to organize features
* Stakeholder feedback requires major architectural change

**Action**: Rollback to before the wrong path. Document lessons learned. Start fresh with new approach.

**Example scenario**:

```
You built: Complex many-to-many relationships with 3 linking tables
Realized: Simple 1-to-many Subtables would work better and be clearer
Decision: ROLLBACK - rebuild with better structure is faster than refactoring
```

### Don't Rollback When - Fix Forward Instead

**1. 🟢 Minor Issues - EASY TO FIX**

**Fixable problems**:

* Small bugs that are easy to fix (typo, wrong field displayed)
* Cosmetic problems (colors, spacing, alignment)
* Non-critical features not working perfectly
* Issues you understand and can fix with targeted prompt or manual edit

**Action**: Fix forward with specific prompt or use visual editor

**Example scenario**:

```
Issue: Button says "Submitt" instead of "Submit"
Decision: FIX FORWARD - 30 second fix, not worth rollback
```

**2. 🟢 Almost There - 90% WORKING**

**Near-success situations**:

* 90% of the feature works correctly
* Issue is well-understood and isolated
* Fix is straightforward and low-risk
* Already invested significant time and most changes are good

**Action**: Complete the fix. Don't waste good progress.

**Example scenario**:

```
Built: Entire task management system with 8 screens
Issue: Delete button missing on task detail screen
Decision: FIX FORWARD - add the button, don't throw away 8 working screens
```

**3. 🟢 Learning Opportunity - VALUABLE DEBUGGING**

**Educational situations**:

* Debugging will teach you important lessons about Buzzy
* Issue reveals a design flaw you need to understand and fix permanently
* Problem is interesting and worth solving
* Understanding this will help you avoid it in future

**Action**: Fix and document your learnings for future reference

**Example scenario**:

```
Issue: Display rule not hiding field as expected
Insight: Learning JSONATA syntax and display rule logic
Decision: FIX FORWARD - this knowledge will be valuable for all future work
```

### Quick Decision Checklist

Before deciding, ask yourself:

* [ ] **Can the app still function?** (No = Rollback)
* [ ] **Do I understand what went wrong?** (No = Rollback)
* [ ] **Can I fix it in under 30 minutes?** (No = Consider rollback)
* [ ] **Is most of my work still good?** (Yes = Fix forward)
* [ ] **Will fixing teach me something valuable?** (Yes = Fix forward)
* [ ] **Is this the 3rd+ failed fix attempt?** (Yes = Rollback)
* [ ] **Do I have a deadline soon?** (Yes = Rollback to stable)

## Rollback Methods

### Primary Method: Buzzy's Built-in Version Control

**What it is**: Buzzy Workspace has built-in version control in the Versions tab. Every significant change automatically creates a restore point.

**Non-technical explanation**: It's like the "Undo" history in Photoshop or the version history in Google Docs—but for your entire app. You can see a list of all previous versions and jump back to any one with a single click.

**Visual walkthrough**:

```
Buzzy Workspace → Your App

┌─────────────────────────────────────────────┐
│ Tabs: [Data] [Design] [Publish] [Versions] │ ← Click Versions
└─────────────────────────────────────────────┘

Versions Tab:
┌────────────────────────────────────────────────────────────┐
│ Current Version: v1.5 - Added comments feature            │
│                                                            │
│ ⏱️  Version History:                                       │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ v1.5 - Added comments feature          Oct 7, 2:30 PM │ │
│ │ v1.4 - Task filtering working          Oct 7, 1:15 PM │ │
│ │ v1.3 - Before navigation redesign      Oct 7, 11:00AM │ │
│ │ v1.2 - Stable version - all tests pass Oct 6, 4:00 PM │ │
│ │ v1.1 - Initial task management         Oct 6, 2:30 PM │ │
│ └────────────────────────────────────────────────────────┘ │
│                                                            │
│ Select version → [Restore] [Preview] [Delete]             │
└────────────────────────────────────────────────────────────┘
```

**Step-by-step restore process**:

1. **Open your app in Buzzy Workspace**
2. **Click the Versions tab** (top navigation)
3. **Review version history** - Each entry shows description and timestamp
4. **Select the version** you want to restore (click to highlight)
5. **Preview if unsure** - See what that version looked like before restoring
6. **Click "Restore"** button
7. **Confirm** - Buzzy asks "Are you sure? This will revert to \[version]"
8. **Done** - App instantly returns to that version state

**What gets restored**:

* ✅ All Datatables and field definitions (Data tab)
* ✅ All screens and layouts (Design tab)
* ✅ Display rules and JSONATA formulas
* ✅ Navigation structure
* ✅ Buzzy Functions code
* ✅ Constants and configuration
* ✅ Security settings (Viewers, Team Viewers)

**What doesn't get restored**:

* ❌ Actual data records in your Datatables (user data is preserved)
* ❌ Published app versions (those remain published)
* ❌ External integrations or API keys (Constants are preserved)

**Advantages of Buzzy's version control**:

* **No setup required**: Built into Buzzy, always on
* **Visual interface**: No command-line or Git knowledge needed
* **One-click restore**: Instant rollback, no complex procedures
* **Complete snapshots**: Entire app state saved, not just code files
* **No merge conflicts**: Unlike Git, never deal with conflicting changes
* **Automatic saves**: Buzzy creates snapshots at key moments
* **Safe experimentation**: Try anything, knowing you can always undo

**When to use**: For ALL Buzzy app structure changes. This is your primary and preferred rollback method.

**See**: [Getting Started Guide (v3)](https://docs.buzzy.buzz/getting-started-with-buzzy/new-buzzy-ai-v3) for detailed version control documentation

{% hint style="success" %}
**Buzzy Advantage**: Unlike traditional code projects that require Git expertise, branching strategies, and command-line tools, Buzzy's version control is:

* Built-in and always available
* Visual and intuitive
* Designed specifically for no-code app development
* Free from merge conflicts and complex workflows
* Accessible to non-technical users

You focus on building; Buzzy handles versioning complexity.
{% endhint %}

### Secondary Considerations

**For Buzzy Functions code**: If you're writing custom server-side code using Buzzy Functions (AWS Lambda), you may optionally use Git to track those specific JavaScript files separately. However, the Buzzy workspace still versions your Functions alongside your app structure, so Git is optional even for Functions.

**For collaborative team workflows**: Buzzy's Versions tab works seamlessly for team collaboration:

* Multiple team members can work on the same app
* Each save creates a new version with user attribution
* No branch management or merge conflicts
* Simple restore process for any team member
* Clear version history showing who changed what and when

**Data backup separate from versions**: Remember that Buzzy versions save your app structure (Datatables definitions, screens, logic), not the data itself. For backing up actual data records:

* Export data from Datatables as needed
* Buzzy's infrastructure provides automatic data backups
* Important: Test your rollback process to understand what gets preserved

## Rollback Best Practices in Buzzy

### 1. Save Versions Regularly

**Rule of thumb**:

* After each feature works in preview mode
* Before starting major AI prompts or changes
* End of each work session
* Before experimenting with new approaches

**Don't**:

* Work for hours without saving a version
* Wait until "perfect"
* Only save "big milestones"

**How to save**: Go to Versions tab → Save current state with descriptive note

### 2. Use Descriptive Version Notes

**Bad version notes**:

* "Update"
* "Changes"
* "Fix"
* "Testing"

**Good version notes**:

* "Working authentication with Organizations"
* "Task filtering by status and assignee implemented"
* "Before adding payment integration"
* "Stable version before navigation redesign"

**Why**: Makes it easy to find the right version to restore

### 3. Mark Stable Versions Clearly

**In Buzzy Versions tab**: Use clear naming conventions

**Examples**:

* "v1.0 - First stable production version"
* "Before major data model refactor"
* "Last working version before adding API integration"
* "Stable - all tests passing"

**Why**: Easy to find "known good" versions quickly when you need to rollback

### 4. Test Before Saving Versions

**Before saving a version in Buzzy**:

* [ ] App loads in preview mode without errors
* [ ] Core features work correctly
* [ ] No obvious issues introduced
* [ ] Data integrity maintained in Datatables
* [ ] Display rules and actions work correctly

**Why**: Ensures you're saving a genuinely working state

### 5. Keep Version Save Points Close

**Good frequency**:

* Save version every 30-60 minutes of work
* After each complete feature
* Before and after major AI prompts

**Too infrequent**:

* Daily versions only
* Only major milestones
* Waiting for "done"

**Why**: Rollback loses less work if you save versions frequently

## Selective Rollback in Buzzy

Sometimes you don't want to rollback your entire app:

### Approach 1: Manual Copy from Previous Version

**In Buzzy**:

1. Open your current app
2. Open a previous version (view-only)
3. Manually recreate specific screens or Datatables from the previous version
4. Copy display rules, actions, or field configurations

**When**: Only part of your changes broke something (e.g., one screen layout issue)

**Limitation**: Buzzy doesn't support restoring individual components, so you'll need to manually recreate them

### Approach 2: Isolate Experiments

**Workflow for risky changes**:

1. Save a stable version with clear note: "Before experiment"
2. Make risky changes with AI prompts
3. Test thoroughly in preview mode
4. If it works: Save new version "Experiment successful"
5. If it fails: Restore "Before experiment" version

**When**: Experimenting with major data model or navigation changes

### Approach 3: Use Display Rules as "Feature Flags"

**Concept**: Features exist but are conditionally shown

**In Buzzy**:

* Create display rules that hide/show features based on user role or data
* Can enable for testing users only
* Easy "rollback" by changing display rule

**Example**:

* New search feature controlled by display rule
* Show only to admin users initially
* If it works, enable for all users
* If it fails, disable via display rule (no rollback needed)

**When**: Rolling out risky new features to production

## After Rolling Back

### 1. Understand What Went Wrong

**Questions to ask**:

* What was I trying to accomplish?
* What AI prompt did I use or what manual changes did I make?
* What specifically broke (screens, Datatables, relationships)?
* Why did it break (data model issue, display rule problem, etc.)?

**Don't**: Immediately try the same AI prompt again

### 2. Plan Different Approach

**Based on what you learned**:

* Break change into smaller steps?
* Use different method?
* Seek expert help?
* Simplify requirements?

### 3. Document the Failure

**Keep notes on**:

* What you tried
* Why it failed
* What you learned
* What to try next

**Why**: Avoid repeating same mistakes

### 4. Consider If You Need the Change

**Honestly assess**:

* Is this feature necessary?
* Is it worth the complexity?
* Is there a simpler alternative?
* Can it wait?

**Sometimes**: The best answer is "don't build it"

## Common Rollback Scenarios in Buzzy

### Scenario 1: AI Prompt Cascade Failure

**What happened**:

* Used one AI prompt
* It created unexpected changes in app structure
* Tried to fix with another prompt
* Made it worse
* Multiple prompts later, app is very broken

**Solution**:

1. Use Buzzy's Versions tab to rollback to before first prompt
2. Review what you were trying to accomplish
3. Write more specific, targeted AI prompt
4. Test in preview mode immediately

### Scenario 2: Data Model Change Gone Wrong

**What happened**:

* Changed Datatable structure (e.g., removed Subtable, changed Linked Field)
* Data relationships broke
* Screens stopped displaying data correctly
* Features stopped working

**Solution**:

1. Use Versions tab to rollback immediately
2. Review the data model change needed
3. Plan Datatable changes more carefully (sketch it first)
4. Consider if you need to export/migrate any critical data
5. Make changes incrementally, test after each step

**Critical**: Always save a version before major Datatable structure changes

### Scenario 3: Screen Refactoring Regret

**What happened**:

* Asked AI to redesign navigation or screens
* AI changed more than intended
* Some screens broken or missing
* Display rules not working correctly

**Solution**:

1. Assess if easier to rollback or fix manually in Design tab
2. If mostly working: fix remaining issues in visual editor
3. If substantially broken: rollback using Versions tab
4. Next time: be more specific in AI prompts about scope

### Scenario 4: Performance Degradation

**What happened**:

* Added new feature (e.g., complex display rules, many Linked Fields)
* App became slow to load
* Preview mode showing delays

**Solution**:

1. Identify what changed (check recent versions)
2. Test performance in live mode vs preview
3. If feature is critical: optimize (simplify display rules, reduce data loading)
4. If not critical: rollback to previous version, optimize separately
5. Consider simpler implementation approach

## Preventing Need for Rollback

**Better than rolling back is not needing to**:

### 1. Make Changes Incrementally

Small AI prompts and manual edits are easier to verify and fix

### 2. Test Immediately in Preview Mode

Catch issues before doing more work

### 3. Understand Before Changing

Know what app structure you're modifying and why

### 4. Save Versions Before Experiments

Keep stable versions safe

### 5. Write Clear, Specific AI Prompts

Vague prompts lead to unpredictable results

### 6. Review AI Changes in Data and Design Tabs

Don't blindly accept generated app structures - review Datatables, screens, and relationships

## Quick Decision Guide

```
Something broke in your Buzzy app:
  |
  ├─ Can you fix it in < 15 minutes (using visual editor or quick AI prompt)?
  │   └─ YES → Fix it
  │   └─ NO → Continue...
  │
  ├─ Is it critical (app won't load / data model broken / security issue)?
  │   └─ YES → Use Versions tab to rollback immediately
  │   └─ NO → Continue...
  │
  ├─ Do you understand what's wrong (which Datatable, screen, or rule)?
  │   └─ YES → Try fixing in visual editor or with targeted AI prompt
  │   └─ NO → Use Versions tab to rollback, analyze, try again
  │
  ├─ Is deadline pressure high?
  │   └─ YES → Rollback to stable version using Versions tab
  │   └─ NO → Consider debugging as learning
  │
  └─ When in doubt → Rollback using Versions tab (better safe than sorry)
```

## Next Steps

* **Preventing issues**: [Making Changes Effectively](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/project-workflow/making-changes)
* **Testing to catch problems early**: [Testing Approaches](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/project-workflow/testing-approaches)
* **Deciding when to use AI**: [AI vs Manual Edits](https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/project-workflow/ai-vs-manual-edits)

{% hint style="success" %}
**Remember**: Rolling back isn't failure—it's smart risk management. With Buzzy's built-in Versions tab, rollback is simple and fast. Save versions often, test changes immediately, and don't hesitate to restore when things don't work out.
{% endhint %}