Expense Tracker Project

An expense tracker is a financial interface, so the way you store numbers matters. A common beginner mistake is storing amounts exactly as users typed them, such as "12.50", "$12.50", or "12,50". This seems harmless while the app only displays one expense, but it becomes fragile when you calculate totals, category summaries, monthly spending, averages, or remaining budget.

Display formatting and calculation should be separate. The app should store amounts as numbers, preferably in the smallest practical unit such as cents, and format them only when rendering the UI. This prevents parsing bugs, rounding issues, and incorrect totals when users add many transactions.

This is especially important in Svelte because reactive statements make recalculation very easy. If the source data is clean, derived totals stay reliable. If the source data is a mix of formatted strings and numbers, every reactive calculation becomes risky.

Problematic approach:

          const expense = {
            id: "1",
            title: "Groceries",
            amount: "$42.90",
            category: "Food"
          };

          $: total = expenses.reduce((sum, expense) => {
            return sum + Number(expense.amount.replace("$", ""));
          }, 0);

This forces every calculation to clean the value before using it. It also breaks easily if the format changes.

Better data model:

          type ExpenseCategory =
            | "Food"
            | "Transport"
            | "Shopping"
            | "Utilities"
            | "Health"
            | "Other";

          type Expense = {
            id: string;
            title: string;
            amountCents: number;
            category: ExpenseCategory;
            createdAt: string;
            note?: string;
          };

Safe amount parsing:

          function parseAmountToCents(value: string): number | null {
            const normalizedValue = value.trim().replace(",", ".");
            const amount = Number(normalizedValue);

            if (!Number.isFinite(amount) || amount <= 0) {
              return null;
            }

            return Math.round(amount * 100);
          }

          function formatMoney(amountCents: number): string {
            return new Intl.NumberFormat("en-US", {
              style: "currency",
              currency: "USD"
            }).format(amountCents / 100);
          }

Svelte reactive total:

          $: totalExpenseCents = expenses.reduce((sum, expense) => {
            return sum + expense.amountCents;
          }, 0);

          $: formattedTotal = formatMoney(totalExpenseCents);

Pay attention to: Store financial values as clean numbers and format them only for display. This keeps totals, category summaries, and budget calculations accurate.

Expense trackers often show total spending, transaction count, category totals, largest expense, or remaining budget. A common mistake is updating these values manually whenever an expense is added, edited, or deleted. This creates synchronization bugs because every action must remember to update every related summary.

Svelte is very good at derived values. Instead of storing totals as separate source state, calculate them from the expense list. When the list changes, the summary updates automatically. This is one of the main learning goals of the project: understanding how reactive declarations can replace unnecessary bookkeeping.

For example, if a user edits an expense from $20 to $35, the total should change automatically. If a user deletes all transactions in the Transport category, that category total should disappear or become zero without manual cleanup logic.

Problematic approach:

          let expenses = [];
          let total = 0;
          let foodTotal = 0;

          function addExpense(expense) {
            expenses = [...expenses, expense];
            total = total + expense.amountCents;

            if (expense.category === "Food") {
              foodTotal = foodTotal + expense.amountCents;
            }
          }

This works only while adding expenses. Editing or deleting expenses can easily leave totals outdated.

Better derived summaries:

          $: totalExpenseCents = expenses.reduce((sum, expense) => {
            return sum + expense.amountCents;
          }, 0);

          $: transactionCount = expenses.length;

          $: largestExpense = expenses.reduce((largest, expense) => {
            if (!largest || expense.amountCents > largest.amountCents) {
              return expense;
            }

            return largest;
          }, null);

Category summary:

          function createCategoryTotals(expenses: Expense[]) {
            return expenses.reduce<Record<ExpenseCategory, number>>((totals, expense) => {
              totals[expense.category] = (totals[expense.category] || 0) + expense.amountCents;

              return totals;
            }, {} as Record<ExpenseCategory, number>);
          }

          $: categoryTotals = createCategoryTotals(expenses);

Rendering summary cards:

          <section class="summary-grid" aria-label="Expense summary">
            <SummaryCard
              title="Total expenses"
              value={formatMoney(totalExpenseCents)}
            />

            <SummaryCard
              title="Transactions"
              value={String(transactionCount)}
            />

            <SummaryCard
              title="Largest expense"
              value={largestExpense ? formatMoney(largestExpense.amountCents) : "$0.00"}
            />
          </section>

Pay attention to: Totals and summaries should be derived from expenses. Do not maintain separate total state unless it truly represents independent data.

Local persistence is an important feature because users expect their transactions to remain after refreshing the page. A common mistake is putting localStorage.getItem and localStorage.setItem directly inside several components. This makes persistence scattered, difficult to test, and easy to break when the data structure changes.

A cleaner Svelte implementation should centralize expense state in a writable store. The store can handle loading from localStorage, saving updates, and exposing actions such as addExpense, editExpense, and deleteExpense. Components should not need to know how persistence works. They should call store actions and render store values.

This separation also makes it easier to replace localStorage later. If the project grows into a Firebase or API-backed app, most components can stay the same because the persistence details are hidden behind the store.

Problematic approach:

          <script>
            let expenses = JSON.parse(localStorage.getItem("expenses") || "[]");

            function addExpense(expense) {
              expenses = [...expenses, expense];
              localStorage.setItem("expenses", JSON.stringify(expenses));
            }

            function deleteExpense(id) {
              expenses = expenses.filter((expense) => expense.id !== id);
              localStorage.setItem("expenses", JSON.stringify(expenses));
            }
          </script>

This works in one component, but it becomes messy when several components need to update the same expense list.

Better Svelte store:

          import { writable } from "svelte/store";

          const STORAGE_KEY = "expense-tracker-expenses";

          function loadExpenses(): Expense[] {
            try {
              const savedExpenses = localStorage.getItem(STORAGE_KEY);

              if (!savedExpenses) {
                return [];
              }

              const parsed: unknown = JSON.parse(savedExpenses);

              return Array.isArray(parsed) ? parsed.filter(isExpense) : [];
            } catch {
              return [];
            }
          }

          function createExpenseStore() {
            const { subscribe, set, update } = writable<Expense[]>(loadExpenses());

            subscribe((expenses) => {
              localStorage.setItem(STORAGE_KEY, JSON.stringify(expenses));
            });

            return {
              subscribe,
              add: (expense: Expense) => {
                update((expenses) => [expense, ...expenses]);
              },
              edit: (updatedExpense: Expense) => {
                update((expenses) => {
                  return expenses.map((expense) => {
                    return expense.id === updatedExpense.id ? updatedExpense : expense;
                  });
                });
              },
              remove: (expenseId: string) => {
                update((expenses) => {
                  return expenses.filter((expense) => expense.id !== expenseId);
                });
              },
              reset: () => set([])
            };
          }

          export const expensesStore = createExpenseStore();

Component usage:

          <script lang="ts">
            import { expensesStore } from "./stores/expensesStore";

            function handleDelete(expenseId: string) {
              expensesStore.remove(expenseId);
            }
          </script>

          {#each $expensesStore as expense (expense.id)}
            <ExpenseListItem
              {expense}
              on:delete={() => handleDelete(expense.id)}
            />
          {/each}

Pay attention to: Keep persistence inside a store or dedicated utility. Components should render expenses and call actions, not manage localStorage details.

Category filters are useful, but they should not destroy the source data. A common mistake is filtering by replacing the original expense array with only matching transactions. The UI looks correct for the selected category, but when the user clears the filter, the removed transactions are gone unless you manually reload them from storage.

Filtering should be derived UI state. The original expense list should remain unchanged, while a reactive statement calculates which expenses are visible based on selected category, search query, date range, or amount range. This keeps the app predictable and prevents accidental data loss.

This is also important for summary cards. You need to decide whether summaries show all expenses or only filtered expenses. Both are valid, but the decision should be intentional. For example, a category filter might show filtered list totals while the main dashboard total still shows all-time spending.

Problematic approach:

          function filterByCategory(category) {
            expenses = expenses.filter((expense) => {
              return expense.category === category;
            });
          }

This permanently removes all expenses outside the selected category from the current state.

Better filter state:

          let selectedCategory: ExpenseCategory | "all" = "all";
          let searchQuery = "";

          function matchesExpenseFilters(expense: Expense): boolean {
            const matchesCategory =
              selectedCategory === "all" || expense.category === selectedCategory;

            const normalizedQuery = searchQuery.trim().toLowerCase();

            const matchesSearch =
              !normalizedQuery ||
              expense.title.toLowerCase().includes(normalizedQuery) ||
              expense.note?.toLowerCase().includes(normalizedQuery);

            return matchesCategory && matchesSearch;
          }

          $: visibleExpenses = $expensesStore.filter(matchesExpenseFilters);

Filtered totals:

          $: visibleTotalCents = visibleExpenses.reduce((sum, expense) => {
            return sum + expense.amountCents;
          }, 0);

          $: isFiltering =
            selectedCategory !== "all" || searchQuery.trim().length > 0;

Helpful empty state:

          {#if visibleExpenses.length === 0 && isFiltering}
            <EmptyState
              title="No expenses match these filters"
              description="Try another category or clear the search field."
            />
          {:else if visibleExpenses.length === 0}
            <EmptyState
              title="No expenses yet"
              description="Add your first transaction to start tracking spending."
            />
          {/if}

Pay attention to: Filters should change what is displayed, not what is stored. Keep the original transaction list intact and calculate visible expenses reactively.

Expense forms seem simple, but they need validation. Users should not be able to add an empty title, a negative amount, a zero amount, an invalid category, or a transaction with a broken date. If the app accepts invalid data, every summary and filter becomes less reliable.

Validation should happen before updating the shared store. The form component can own temporary input state, validation errors, and submit behavior. Only after the form is valid should it create a clean Expense object and send it to the store. This keeps the store data trustworthy.

In Svelte, two-way binding makes forms pleasant to build, but it can also hide validation problems. Do not treat a bound input value as valid just because it exists. Trim strings, parse amounts carefully, validate categories, and show clear error messages near the relevant fields.

Problematic approach:

          <script>
            let title = "";
            let amount = "";
            let category = "Food";

            function submitExpense() {
              expensesStore.add({
                id: crypto.randomUUID(),
                title,
                amountCents: Number(amount) * 100,
                category,
                createdAt: new Date().toISOString()
              });
            }
          </script>

This can submit empty titles, invalid numbers, or amounts that become NaN.

Better validation result:

          type ExpenseFormErrors = {
            title?: string;
            amount?: string;
            category?: string;
          };

          function validateExpenseForm(input: {
            title: string;
            amount: string;
            category: string;
          }): {
            isValid: boolean;
            errors: ExpenseFormErrors;
            amountCents: number | null;
          } {
            const errors: ExpenseFormErrors = {};
            const amountCents = parseAmountToCents(input.amount);

            if (!input.title.trim()) {
              errors.title = "Enter an expense title.";
            }

            if (amountCents === null) {
              errors.amount = "Enter a valid amount greater than zero.";
            }

            if (!isExpenseCategory(input.category)) {
              errors.category = "Choose a valid category.";
            }

            return {
              isValid: Object.keys(errors).length === 0,
              errors,
              amountCents
            };
          }

Svelte form submit:

          function handleSubmit() {
            const result = validateExpenseForm({
              title,
              amount,
              category
            });

            errors = result.errors;

            if (!result.isValid || result.amountCents === null) {
              return;
            }

            expensesStore.add({
              id: crypto.randomUUID(),
              title: title.trim(),
              amountCents: result.amountCents,
              category,
              note: note.trim() || undefined,
              createdAt: new Date().toISOString()
            });

            title = "";
            amount = "";
            note = "";
            category = "Food";
          }

Accessible error message:

          <label for="expense-amount">Amount</label>
          <input
            id="expense-amount"
            bind:value={amount}
            inputmode="decimal"
            aria-describedby={errors.amount ? "amount-error" : undefined}
          />

          {#if errors.amount}
            <p id="amount-error" class="form-error">
              {errors.amount}
            </p>
          {/if}

Pay attention to: Validate form data before it reaches the store. Clean input state, parsed numbers, category validation, and accessible errors make the app feel much more professional.

A beginner expense tracker can easily become just a list with add and delete buttons. That is not wrong, but it misses the main value of the project. A good expense tracker should help users understand their spending. That means the interface should make totals, categories, recent transactions, and patterns easy to read.

Think about the user experience. The most important numbers should be visible immediately. Categories should be scannable. Transactions should show amount, title, category, and date. Delete actions should be clear but not too easy to trigger accidentally. Empty states should explain what to do next. On mobile, the form and list should not feel cramped.

This does not mean adding complex charts immediately. A simple but thoughtful layout with summary cards, category chips, readable transaction rows, and responsive spacing is more valuable than a cluttered dashboard full of unfinished widgets.

Problematic layout:

          <main>
            <form>...</form>

            {#each $expensesStore as expense}
              <p>{expense.title} {expense.amountCents}</p>
            {/each}
          </main>

This technically shows the data, but it does not help the user understand their spending quickly.

Better page structure:

          <main class="expense-page">
            <section class="expense-page__hero">
              <h1>Expense Tracker</h1>
              <p>Track daily spending and understand where your money goes.</p>
            </section>

            <SummaryGrid
              total={formattedTotal}
              transactionCount={transactionCount}
              largestExpense={largestExpense}
            />

            <section class="expense-page__content">
              <ExpenseForm />

              <div>
                <ExpenseFilters
                  bind:selectedCategory
                  bind:searchQuery
                />

                <ExpenseList expenses={visibleExpenses} />
              </div>
            </section>
          </main>

Responsive layout idea:

          .expense-page__content {
            display: grid;
            gap: 24px;
          }

          @media (min-width: 900px) {
            .expense-page__content {
              grid-template-columns: minmax(280px, 360px) minmax(0, 1fr);
              align-items: start;
            }
          }

          .summary-grid {
            display: grid;
            grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
            gap: 16px;
          }

Pay attention to: Build a small financial product, not only a CRUD demo. Summary, filters, readable rows, empty states, and responsive layout make the project more useful and portfolio-ready.