Skip to main content
Back to selected work

Pricing PWA / Small Business

PriceCraft

A pricing tool for small food businesses that answers a recurring question: after ingredients, labor, and overhead change, what should this product sell for?

PriceCraft results screen for chocolate chip cookies showing recommended price, break-even price, margin, profit, and cost breakdown.
Source: Live productThe results view keeps the recommended selling price beside break-even, margin, per-unit profit, batch profit, and the underlying cost breakdown.

Public evidence

These reviewed public sources support the adjacent build claims; they do not imply adoption or unmeasured outcomes.

Problem

Target user
Small food businesses that need to price products repeatedly as ingredient costs change.
Challenge
A price is easy to calculate once; keeping it current is harder when spreadsheets repeat ingredient costs and related products duplicate the same base recipe.
Why it mattered
Missing a shared cost can make real margins look healthier than they are, while required sign-in or connectivity can block a quick pricing check.

Constraints

  • The calculator must remain useful before sign-in and during connectivity loss.
  • Related product variants need one source for shared recipe costs.
  • Noisy receipt OCR output cannot be trusted to update ingredient costs without user review.

Solution

PriceCraft keeps the recipe, selling-price options, and future cost updates together so a business can recalculate instead of rebuilding its math.

  1. The business records ingredients, labor, overhead, and shared recipe costs, then compares markup and profit-margin prices with break-even and profit figures.
  2. Product variants reuse one base recipe and add only the costs that differ.
  3. Receipt OCR proposes ingredient names, quantities, units, and prices; the user edits and confirms them before the ingredient catalog or price history changes.
  4. Guest data works offline, can move into an account after sign-in, and can synchronize through Supabase with Row-Level Security; JSON import and export provide a portable backup.

Engineering Decisions

  1. Share one base recipe across variants

    Constraint
    Related products needed to share a base recipe without duplicating shared ingredient costs.
    Decision
    Model reusable base recipes and allocate shared costs across product variants.
    Rationale
    Update shared costs once while keeping each variant’s added costs and resulting margin visible.

  2. Treat receipt OCR as a draft

    Constraint
    Receipt text is noisy and cannot safely update ingredient costs without review.
    Decision
    Preprocess captured images, extract candidate lines through the available OCR path, and require editable confirmation before catalog or price-history writes.
    Rationale
    Reduce re-entry work without letting uncertain text silently alter a selling-price calculation.
    Trade-off
    The user remains responsible for checking names, quantities, units, and prices before saving.

  3. Let the calculator work before sign-in

    Constraint
    The calculator needed to remain useful before sign-in and during connectivity loss.
    Decision
    Support local guest changes, optional Supabase authentication and synchronization, and guest-data migration.
    Rationale
    Make the core calculation immediately useful, then offer cloud sync when the user wants it.

Outcomes

Product and delivery

  1. 2 strategies

    Two ways to set a price

    Calculates selling prices with both markup and profit-margin strategies across ingredient, labor, and overhead costs.

  2. Offline-capable

    Works before sign-in

    Lets a guest calculate and save locally without a connection, then migrate and synchronize data after signing in.

  3. Receipt to catalog

    Cost capture

    Turns user-reviewed receipt lines into new catalog ingredients or updated price-history records.

Implementation evidence

  1. 300+ tests

    Pricing changes checked

    Covers pricing logic, persistence, migration, catalog, and interface behavior with more than 300 unit and integration tests.

Learnings and Next Steps

What I learned

  • Receipt OCR is most useful as a draft that reduces typing; it should not silently rewrite the costs behind a selling price.
  • A calculator earns trust faster when it works before account creation and explains the cost behind its recommendation.

What I would improve

  • Test receipt extraction across more layouts and let users review several detected price changes in one pass.

What remains unvalidated

  • User adoption, pricing time saved, and business-margin improvement have not been measured.