When people talk about building an e-commerce site, they often focus only on the storefront UI. My experience on MatoCrafts was the opposite: we needed a system that could handle product operations end-to-end, from inventory and variants to stall-level sales, while still feeling usable to real store staff. MatoCrafts is an e-commerce platform for Nepali products, built to support more than a typical online storefront. The project needed to serve customers browsing and ordering online, while also helping the business manage products, variants, inventory, physical stalls, and sales operations behind the scenes. I joined the project as a Full-Stack Developer at Niyalo Creatives, working primarily with Next.js and Sanity CMS. Although the project began as a collaborative internship effort, I took ownership of most of the implementation as the work progressed, approximately 60% of the final product under the guidance of senior team members. The result is a platform that has grown from a simple, functional e-commerce prototype into an operational system designed around the real needs of a growing retail business.
The starting point: functional, but not operational
The initial usable version of MatoCrafts was intentionally simple. It was built primarily to test core commerce functionality: displaying products, adding them to a cart, and completing a purchase through Stripe. At that stage, the platform had a generic interface and supported only basic products without variants. It did not yet include Nepali language support, structured inventory workflows, barcode operations, stall management, delivery integration, or a dashboard for managing day-to-day business activity. That version proved that the basic e-commerce flow could work. The next challenge was more important: turning that foundation into a system that could support how the business actually operates.
Understanding the real workflow
A normal online store tracks products and orders. MatoCrafts needed to account for more than that. Products could have multiple variants. Stock could exist in a warehouse but also be moved to physical stalls for in-person selling. Staff needed to understand what was available, what had been sold, and where inventory was located. At the same time, the public storefront needed to remain simple enough for customers to browse and purchase without being exposed to operational complexity. This meant the project was not only about building pages. It was about designing a workflow where product information, variants, stock, sales, and physical operations could remain connected. The key question became: how can the system make inventory understandable for both customers and staff?
Designing product variants around inventory
Product variants were one of the most important parts of the platform. A single product can have different sizes, colors, materials, or other options. Each variation may need its own stock count, price, barcode, and availability. Handling this well required more than adding dropdown menus to a product page. The system needed a clear relationship between a parent product and its sellable variants, while ensuring that stock remained accurate across the storefront and the internal dashboard. I worked on the product and variant workflow so that staff could create variants, associate them with products, manage their available quantity, and keep the customer-facing purchase experience understandable. This was especially important because a variant-based system affects several areas at once:
- What the customer sees on a product page
- Which option can be added to the cart
- How stock is tracked
- How inventory is updated after a sale
- How staff identify items during physical operations
The work required careful refinement of both the data structure and the user interface. The goal was not simply to support variants technically, but to make them manageable for the people who would use the system every day.
Extending inventory beyond the warehouse
A major improvement in MatoCrafts was moving from a basic stock counter to a more practical inventory workflow. The business needed to manage stock held in a warehouse as well as products taken to physical stalls. Without a structured process, stock can become difficult to reconcile: an item may appear available online while it has already been sold in person, or a team member may not know where a particular product is currently located. To address this, I worked on dashboard-driven inventory and stall management flows. The system supports tracking inventory in the warehouse, transferring stock for stall operations, and recording stall sales through the dashboard. This made the platform closer to the business’s real workflow. Instead of treating online sales and physical sales as separate activities, the system could support both as part of one inventory process. The implementation also created a foundation for better reporting and future operational improvements, since stock movements can be understood in context rather than as isolated number changes.
Adding barcode-supported operations
Barcode support was another feature I am particularly proud of because it connects the software to the physical handling of products. For a growing retail workflow, barcodes can reduce the friction of identifying items, managing variants, and recording sales. A barcode-based approach is particularly useful when products have similar names or multiple variants that are difficult to distinguish manually. I worked on the barcode-related implementation and its connection to inventory and sales workflows. The goal was to make products easier to identify during stall operations and to support a more consistent process for stock and receipt handling. The system currently supports virtual printing for barcode and receipt workflows. Physical printer testing is planned once the appropriate printer hardware is available. This is an important reminder that real-world software does not end at deployment: some features depend on operational equipment, staff processes, and testing in the environment where the product will actually be used.
In short, MatoCrafts taught me that “done” in portfolio terms is not the same as “usable” in business terms. A strong case-study article should show this tension clearly: what was promised, what was built, what was constrained, and what still remains.
Making the platform more accessible with Nepali language support
MatoCrafts is built for a Nepali market, so language support was not a decorative addition. It was part of making the platform more approachable for its intended users. Nepali language support was introduced as the project evolved, following an idea contributed during the early collaboration phase. I implemented and refined the broader platform around this direction so that the site could better serve users who prefer to browse in Nepali. Localization is easy to underestimate. It affects navigation, product information, calls to action, layout spacing, and the overall clarity of the customer journey. The intention was to make the platform feel usable for its audience rather than simply translating isolated words.
Delivery integration remains an active challenge
Not every challenge is fully solved at the time a product goes live. MatoCrafts currently uses Packers for delivery-related workflows. While its documentation is usable, the client is interested in moving to Pick & Drop because it better matches their operational preference. The difficulty is that the required integration documentation is not yet available in a form that makes implementation reliable. This is an active product and integration challenge rather than a finished feature. For me, it has reinforced the importance of balancing technical possibilities with the tools and partnerships a business can realistically use. Instead of presenting this as a failure, I see it as part of responsible development: the platform is functional, but the operational workflow continues to be improved based on real client needs.
What I handled
- Built and refined the full-stack e-commerce experience using Next.js and Sanity CMS, including storefront and dashboard work.
- Designed and implemented product variant, inventory, warehouse, stall-sales, and barcode-supported workflows.
- Took ownership of the majority of the project after the initial collaboration phase, while working under senior guidance and continuing to refine the platform from real client feedback.
Outcome: a platform prepared for real operations
MatoCrafts is live at matocrafts.com and continues to evolve through feedback from the business. In one 30-day Cloudflare analytics snapshot, the website recorded approximately 3,070 unique visitors and 79,610 requests. These numbers indicate meaningful early traffic and provide a useful baseline as the business continues activating and refining its online sales workflow. At the same time, I do not treat traffic alone as the final measure of success. The more meaningful outcome is that MatoCrafts now has a stronger operational foundation: structured product variants, inventory awareness, dashboard-based stall workflows, barcode support, and a platform that can continue adapting as the business grows. The next steps include testing barcode and receipt printing with physical hardware, improving delivery integration based on the client’s preferred partner, and making smaller user-interface refinements requested after real-world use.
Reflection
MatoCrafts taught me that building an e-commerce platform is not only about creating a polished storefront. The difficult and valuable work is often behind the scenes: keeping variants understandable, making inventory reliable, connecting physical and digital operations, and adapting the product as real users reveal what they need. It also taught me to think beyond the first version. A working prototype is useful, but a real product must keep evolving through feedback, constraints, operational realities, and continuous refinement. For MatoCrafts, that evolution is still ongoing and that is exactly what makes it a meaningful project in my portfolio.