Live Site

Alawe Meat Merchants

Digitizing Alawe - School Project

Year

2024 ( Timeframe - Sep - Oct )

Category

  • UI/UX ,
  • Front-End ,
  • Back-End

My role

  • UI/UX ,
  • Front-End ,
  • Back-End

Overview

Alawe (an alias) is a meat processing and retail company based in Malawi. They handle everything from buying livestock to processing and selling meat products in their stores. They also sell groceries and other resalable items alongside their own products. This project aimed to solve some key challenges the company was facing, like disconnected inventory systems, supply chain inefficiencies, and the lack of a platform for online sales. The goal was to create a centralized system that keeps all branches connected, provides real-time access to data, and makes operations smoother. At the same time, the project focused on improving the customer experience with features like an online store and AI-driven support.

Context

This project was undertaken as part of a school assignment aimed at applying technical skills to real-world scenarios. The task required selecting a company and developing a system to automate and improve its operations. Alawe, an alias for the actual company chosen, operates in the meat processing and retail industry. Due to confidentiality requirements, the company’s real name and identifying details are not referenced in this case study. The project involved analyzing the company’s operations to identify inefficiencies and opportunities for improvement. The focus was on designing a solution that would streamline workflows, automate manual processes, and integrate data across different departments. This case study outlines the research, development, and outcomes of the system created for Alawe.

Research

The research phase began with direct discussions with Alawe’s stakeholders to understand their daily operations and the broader workings of the company. This included learning about their processes for procurement, production, sales, and management. Observations of their workflows revealed critical gaps in efficiency and communication. One of the primary challenges was the isolation of data from different operations. Procurement records, sales transactions, and other key datasets were stored separately, making it impossible to gain a holistic view of the company’s performance. For example, managers often needed to manually deploy someone to gather and consolidate data for analysis, leading to delays and errors. It also became clear that many processes, such as data analysis and report generation, were handled manually, further slowing operations. Additionally, the lack of a company website left Alawe without an online presence, limiting their ability to reach potential customers and partners. These findings shaped the foundation of the project, emphasizing the need for a centralized system to connect all branches and operations, streamline data access, and improve collaboration. The goal was to transition Alawe into a more modern, connected, and efficient business model while ensuring the solution was intuitive and accessible for all users.

Design

UI/UX Design

The UI/UX design phase focused on balancing functionality and efficiency due to limited time constraints. Rather than creating a complete set of designs upfront, each page was designed based on specific use cases. For instance, a single dashboard page was created as a reference for all user roles during development.

In cases where more upfront design was essential, quick, low-fidelity wireframes were sketched manually using pen and paper. This approach ensured that critical elements were planned while leaving room for iteration during development. The focus throughout the design phase was on usability, clarity, and ensuring that the system could effectively meet the company’s needs.

System Design

The system was designed around five users with the ability to scale to multiple users in the future. The system was designed with modularity and scalability in mind. Each user role was assigned its own set of routes and actions, ensuring they only had access to the features relevant to their responsibilities. The business logic was separated from the user interface, allowing the same core functionality to be reused across different parts of the system. This approach made it easier to add new features or user roles without affecting existing components, keeping the system flexible and maintainable.

The system also consists of subsystems for example the notification system, file upload system, authentication system and data aggregation system.

The notification system was built using middleware that automatically generated notifications when certain actions occurred, such as creating a report or adding a new Employee. These notifications were designed to provide real-time updates to users, ensuring they stayed informed about important events without needing to manually check for updates.

0

Development

The Alawe system was developed using a robust and scalable tech stack, including Next.js, MongoDB, Tailwind CSS, and Pusher. Next.js was used for both the frontend and backend, offering features like server-side rendering and dynamic routing. MongoDB provided a flexible NoSQL database structure, enabling efficient data aggregation and retrieval across multiple branches. Key components of the system included a centralized dashboard for internal operations and a customer-facing online store. Real-time capabilities, such as notifications and data synchronization, were powered by Pusher, while authentication was handled seamlessly using NextAuth. AI functionality was integrated with Botpress, providing automated customer support on the website. The system architecture focused on modularity and scalability. Business logic was decoupled from user interfaces, allowing new features or user roles to be added with minimal effort. Tailwind CSS was used for styling, ensuring consistent and maintainable design elements. Overall, the development process emphasized performance, usability, and scalability to meet the company’s immediate and future needs.

Project Challenges

Dev Parody

The initial real-time implementation worked flawlessly in development. After thorough testing in the development environment, it was deployed, and focus shifted to building additional features without retesting the real-time functionality in production. Much later in the development stage, it became clear that the real-time feature wasn’t working as expected. After a quick investigation, the issue was traced to Vercel’s serverless architecture and its timeout constraints, which prevented real-time connections from functioning in production. Pusher was introduced to address this limitation, but its integration required modifying existing workflows to ensure smooth functionality, adding extra complexity to the process.

Client Cold Feet

At the beginning of the project, the client was hesitant and viewed the system as more of an experimental endeavor than a serious solution. This skepticism made gathering initial information for research challenging, as their input was limited and unstructured. However, as the project progressed and the system began to take shape, the client became more engaged and cooperative, providing clearer insights and feedback that significantly improved the later stages of development.

Take Aways

The Power of Preparation

This project showed how important it is to research deployment environments early. Missing production-specific details, like Vercel’s timeout limits, led to issues that could have been avoided with better planning and testing.

Patience is Key

Working with a client who wasn’t fully on board at first taught a lot about building trust. Over time, they became more engaged, and their feedback made the project better.

Iterate and Optimize

Balancing speed and quality was an ongoing challenge, especially under a tight timeline. There wasn’t time to perfect everything upfront. Designing and tweaking as the project moved forward turned out to be a practical way to keep things on track without compromising too much.

Outcomes

The project was a partial success. While I wasn’t able to deliver 100% of the promised features, I managed to complete over 80% of the system. Despite falling short of full delivery, the project was a huge learning experience. One of the biggest lessons was understanding the danger of underestimating a project’s complexity. I based my initial estimates on my confidence in building individual features, but I didn’t account for how much harder it gets as a project grows. Each new feature added more complexity, making the next step harder and more time-consuming. This overpromising taught me the importance of thoughtful planning and realistic goal setting to avoid similar pitfalls in the future.