This project is a full-stack-style Flutter application organized around receipts as the core aggregate: capture customer fields, attach one or many configurable order lines, validate combinations against a central constants and pricing layer, then either save as draft or finalize and open a dedicated preview surface. The UI splits “business” and “client” presentations so totals and discounts can appear only where policy allows, and PDF generation mirrors those same rules so exports stay aligned with on-screen truth.

Persistence deliberately sits in two places. A remote data source talks to Firestore for shared team access while a local data source mirrors JSON (file-based on native, preferences on web) so interruption or flaky networks do not erase work. The repository writes locally first on create and update, then reaches remote, merges reads with cache-fill behavior, and can bulk-upload local records after authentication—matching how real operators expect continuity between sessions.

Navigation is explicit: declarative routing, login vs dashboard redirects driven by auth state changes, and screens for dashboard, drafts, history, form entry, and preview. Supporting services handle PDF filenames, sanitization, and attachment flows; optional third-party mail integration is isolated from Firebase credentials so operational concerns stay separated. Throughout, presentation stays in BLoC while the domain keeps entities, repository contracts, and use cases narrow and test-shaped.

Soulireye is a production-grade Flutter desktop application built primarily for Windows, designed for a real studio workflow: turn high-resolution iris photographs into framed, printable artwork. The product spans the full operational story—from the moment a practitioner opens the app to the moment a finished PNG (or print layout) leaves the workspace. That breadth is deliberate: intake, editing, staging, templating, and export are treated as one continuous pipeline rather than unrelated screens.

The journey begins on a splash surface with a dark, brand-consistent shell, then moves into client intake with a split marketing and form layout. Practitioners enter name, email, and country; the app validates required fields, supports session history within a twenty-four-hour window, and can detect an existing session to offer a “jump back in” path instead of duplicating data. Resume logic is non-trivial: depending on what is stored in Hive—raw paths, edited paths, Art Studio outputs—the router sends the user to Image Prep, the secondary prep workspace, or Art Studio with history primed, so returning users are not punished with empty state when work already exists.

Image Prep is the upload hub: up to six JPG/PNG assets, duplicate and format checks, desktop drag-and-drop, copies into controlled prep temp locations, and a grid with per-image cleanup. A parallel instruction column keeps the mental model clear—review on the left, then continue into the Iris Editor. The editor itself is a dense, desktop-native surface: a large canvas region paired with a fixed queue sidebar listing every iris, its status (pending through done), locking rules for slots that arrived from downstream flows, hover delete on desktop, and background overlays while Photoshop-backed jobs run (cropping iris boundaries, removing flash, applying color).

Circling, flash correction, and color are three explicit steps with explicit gating—you cannot shortcut the pipeline in ways that corrupt later exports. Circling persists parameters per image; flash work supports brush masking, undo, skip with confirmation, and resets tied back to cropped baselines; color combines global sliders with optional localized brush modes and version-aware resets. When every item in the queue is complete, Proceed syncs edited paths back into session storage and hands off to Prep 2, where draggable thumbnails assemble the set that should enter Art Studio.

Art Studio synchronizes Dropbox-hosted Photoshop templates with the on-canvas iris count, chosen solo or duo effect families, layout shape rules that change when pair effects constrain geometry, reorderable thumbnails, personalization fields when PSD metadata allows, and a generation funnel with cancellable downloads, rotating status copy, failure dialogs that read human, and Hive-backed artwork lists plus dimension caches for history grids. Finish options include save-as download, conditional print ladders by layout, and email composition hooks when configuration and client email allow.

A global app bar pattern ties the experience together: contextual back behavior, quitting to intake, working identity in the subtitle, and help dialogs indexed by numbered guides so operators are never orphaned on a dense screen.

Shoply is a mobile commerce experience built in Flutter for Android and iOS, aimed at teams that want Firebase-backed auth and catalog data without surrendering structure in the codebase. The product narrative is straightforward for end users—sign in, browse, trust the system—and intentionally strict for engineers: every feature is a slice with its own data, domain, and presentation boundaries so the app can grow new verticals without turning presentation widgets into accidental databases.

Authentication is a first-class story, not a splash afterthought. Email flows and Google Sign-In both land in the same session model, with failures communicated clearly and navigation that never leaves users on dead-end routes. The catalog experience is powered by Cloud Firestore, which means thinking early about how documents map to domain entities, how reads are shaped for list and detail screens, and how UI state tracks loading and empty outcomes without flicker or duplicate requests.

Routing uses go_router so deep links and nested flows remain explicit; dependency injection through GetIt keeps constructors honest and tests reachable; flutter_bloc keeps event-driven transitions predictable; and supporting packages like dartz, hive, and equatable reinforce immutability and caching choices where they matter. The interface is calm and retail-focused—large imagery, readable product lines, and motion that supports comprehension rather than distraction.

From a delivery perspective, Shoply demonstrates how a solo or small team can ship a credible storefront prototype that is already organized like a product bound for production: feature folders, shared core utilities, and a mindset that treats authentication, catalog, and navigation as collaborating services rather than a single “god screen.”