FashionTech

The problem

Many small fashion retailers in Taytay still run their business on notebooks and memory. They lose track of fabric and product stock, can't tell whether a product actually earns a profit once fabric and production costs are counted, and juggle job orders that involve several fabrics and suppliers.

We framed it as three questions:

• How might we simplify fabric and product inventory tracking to prevent oversupply and wastage?
• How might we help retailers monitor profitability in real time?
• How might we streamline job orders that involve multiple fabrics and suppliers?

Who it's for

We designed around two personas. Ate Lorna, 45, owns a small fashion stall, tracks inventory in notebooks, and mostly uses Messenger and calls. Her daughter Anna, 22, helps with inventory and sales and is comfortable with digital tools. That pairing pushed us toward a mobile-first app with simple layouts and minimal forms.

The solution

FashionTech is a mobile app that puts the daily operations in one place:

• Inventory: fabric and product stock with variants, low-stock indicators and an automatic activity log.
• Job orders: assign fabrics and yardage to each product order and follow it through a status workflow.
• Profit checker: profit per product, calculated from the sales log and unit costs.
• Transactions: record sales, income and expenses, and see total profit with a fabric-cost breakdown.
• Customers and suppliers: who bought what, when, and how much.
• Roles and per-user data: admin and user roles. Each record carries its creator's ID and pages query by it, so users see their own records, and admins can see everything.

How we split the work

We worked closely and both touched most of the app, with different focus areas.

My focus:

• Designed the Firestore data model and migrated it through several revisions (ERD v7 to v9), updating the collections, models and services each time.
• Built the fabric, product (variants, colors, sizes, multi-image upload), job order, customer, supplier and transaction modules.
• Built the Transaction Dashboard (income, expenses, total profit and a fabric-cost breakdown) and the sell modal.
• Implemented the activity-logging system across products, fabrics, job orders, transactions and suppliers.
• Added per-user data filtering through Firestore queries, plus admin role checks.
• Collaborated on the UI design in Figma and built responsive UI components.
• Wrote the project README and tests for category management and fabric logging.

Justin Andrei Ibañez's focus:

• The admin side.
• The profit calculation and the stock-deducting sale transaction, and the profit checker on the home dashboard.
• Notifications, profile and settings pages, and the recent-activity feed.
• Bug fixing across the app.

Challenges

• A dynamic app for traditional users: we kept layouts simple and forms short, and designed for phones first.
• An evolving data structure: jobs, products, fabrics and logs all relate to each other, so we kept an ERD and revised it as feedback came in.
• A short internship: we prioritized the core modules first (inventory, job orders and profit checker) and left the rest for later.
• Firestore has no joins, so related records are fetched and combined in the app, and per-user filtering is done with queries on a creator ID field.

What I'd do next

Per-user data is filtered in the Firestore queries, since each record carries its creator's ID. I'd enforce this with Firestore security rules, so it holds on the server side too.

What I learned

• Building and shipping a working Flutter and Firebase MVP end to end in a short timeframe.
• Structuring Firestore data and queries so they stay maintainable as requirements change.
• Resolving bugs quickly in a fast-paced team environment.
• Good design starts with the real user's problem, not only the interface.