Development Workflow

This page covers the day-to-day rhythm of building and deploying data apps.

Starting Your Dev Server

Each time you sit down to work:

pnpm install
pnpm run build
pnpm run dev

This starts your local dev server. The terminal will show URLs for your apps — open them in your browser to see them running. The dev server watches for changes and reloads automatically, so you can see updates as they happen.

Environments

Wallabi gives you three environments, each serving a different purpose:

Environment	How it works	Who sees it
Dev	Runs on your computer via pnpm run dev	Just you
Preview	Created automatically when you open a pull request	You and your reviewers
Production	Updated automatically when changes merge to main	Your end users

Each environment is completely isolated — your dev experiments won’t affect what your users see.

The Begin / Ship Workflow

Wallabi provides a structured workflow for making changes. Instead of jumping straight into code, you start a session that captures what you’re trying to accomplish — and when you’re done, you wrap it up with a clean record of what was built and why.

1. Start a session with /begin

With your dev server running, open Claude Code and type:

/begin Add a revenue breakdown chart to the sales dashboard

This tells Claude Code what you want to accomplish. It will:

• Create a session folder to track this piece of work
• Draft a summary of what you’re trying to build (requirements)
• Set up a scratchpad to capture important decisions along the way

You can give as much or as little detail as you want — a one-liner is fine. Claude Code will ask a quick follow-up if it needs more context, then get to work.

2. Build and iterate

Once the session is started, work with Claude Code like normal:

• Describe what you want to build or change
• Let Claude Code explore your data first — it’ll look at your tables and columns before building
• Review the changes in your browser as they happen
• Ask for adjustments — “Make that a line chart instead” or “Add a drill-down table”

Behind the scenes, Claude Code keeps a running log of important decisions, pivots, and trade-offs made during the session. You don’t need to do anything — this happens automatically.

3. Finish with /ship

When you’re happy with your changes, type:

/ship

Claude Code will:

• Finalize the requirements document with what was actually built (which may differ from the original intent — that’s normal)
• Create a technical design document capturing the key decisions and approach
• Show you both documents for review
• Commit everything

The result is a clean record of what was built and why, saved in your project under .wallabi/changes/. This is valuable context for your team — and for Claude Code itself in future sessions.

Why this matters

Without /begin and /ship, it’s easy to lose track of why something was built a certain way. These session records mean:

• Future you can look back and understand past decisions
• Your team can review changes with full context
• Claude Code automatically picks up where you left off — when you start a new session, it sees what’s been done before and can build on it

Working with Claude Code

Claude Code is your AI assistant for building data apps. With your dev server running, it has access to your data and the full Wallabi toolkit.

Useful Commands

Command	What it does
/begin	Start a development session — captures what you’re building
/ship	Finish a session — finalizes documentation and commits
/create-app	Create a new data app from scratch
/generate-transform	Create or modify how your data is shaped

Tips for Good Results

• Start with /begin — it helps Claude Code stay focused on your goal and creates a useful record of the work
• Start simple — ask for a basic table view first, then add charts and interactivity
• Explore before building — “What data sources do I have?” and “Describe the tables in [source]” help Claude Code give you better results
• Be specific — “Show monthly revenue by region with a date filter” works better than “Make a dashboard”
• Iterate — it’s easy to refine. “Make that a line chart instead” or “Add a drill-down table”

Working with Git

Under the hood, your work is tracked with Git. The /ship command handles committing your session artifacts, but you’ll still use Git to share your work with your team.

If you’re new to Git, here’s the short version:

# Create a branch for your work
git checkout -b my-feature-name

# After making changes and running /ship, push to share
git push

Pushing creates a pull request where your team can review the changes — including the session documents that /ship generated.

Your team may have specific conventions for branch names — check with your team lead.

Project Structure

Your app host (the project that contains your data apps — think of it as your team’s workspace) is organized like this:

your-app-host/
├── apps/                    # App host configuration
├── data-apps/               # Your data apps (one folder per app)
│   └── my-app/
│       └── src/             # App-specific code
├── packages/                # Shared data packages (transforms and sources)
└── .wallabi/
    └── changes/             # Session records from /begin and /ship

• data-apps/ is where your individual apps live — each one has its own folder
• packages/ contains the data definitions that your apps use
• .wallabi/changes/ stores the requirements and design documents from each development session