ReStockly

• 

  DemandDock

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for ReStockly

Hyper-Local Supply Chain Predictor This project was inspired by a very practical problem: small corner shops often lose money not because demand is low, but because they cannot react fast enough to changing demand patterns. I wanted to build something lightweight and useful that could help a shop owner make better daily stocking decisions without needing an expensive ERP system. What inspired me I noticed that many small retailers still depend on intuition, handwritten ledgers, or memory to manage inventory. That approach works only until demand shifts because of rain, a local festival, a sports match, or a sudden neighborhood event. I was especially interested in solving a problem where simple data could create an immediate business impact. The idea became more compelling because the same item can behave very differently depending on context. For example, bottled water, snacks, and umbrellas may all spike on rainy days, while cold drinks and ice cream may spike during heatwaves. I wanted to combine those signals into one system that could warn shop owners before they ran out of stock. What I learned While building this project, I learned how much value comes from combining internal and external data sources. Sales history alone is useful, but it becomes far more predictive when enriched with weather, calendar events, and local context. I also learned that in real-world retail, the best model is not always the most complex one; often, a simple and interpretable forecasting approach is more useful because owners need to trust the recommendation. I also learned how to convert predictions into action. A forecast is only helpful if it leads to a clear next step, so I focused on generating daily alerts and supplier order drafts that could be sent quickly. That shifted the project from being a pure analytics exercise into an operational tool. How I built it I built the system around three main data streams: historical sales, local weather data, and community event information. The pipeline ingests these inputs daily, cleans them, aligns them by date, and creates features such as recent sales trends, temperature changes, rainfall, and event indicators. From there, the predictor estimates the expected demand for each item and suggests reorder quantities. The reorder logic uses a simple inventory rule based on predicted demand and safety stock. In mathematical form, I treated the daily reorder need as: R=max(0,D ˆ+S-I) where R is the reorder quantity, D ˆ is predicted demand, S is safety stock, and I is current inventory. This made the output easy to explain to non-technical users. After generating the stock recommendations, the system prepares two actions: a text alert for the shop owner and a draft purchase order for the supplier. I designed it to stay lightweight so it could run without heavy enterprise software, which kept the workflow practical for small businesses. Challenges I faced One challenge was data quality. Small retailers rarely have perfectly structured records, so missing values, inconsistent item names, and irregular sales logs had to be handled carefully. Another challenge was noisy external data, because weather and event signals can help demand forecasting but do not always map cleanly to every product category. A second challenge was balancing accuracy with simplicity. A more advanced model might capture complex patterns, but it would also be harder to explain and maintain. I had to design the system so the recommendations were easy to trust, because a shop owner is more likely to act on a clear explanation than on a black-box prediction. Another difficulty was making the output actionable. It was not enough to say “demand may rise”; the system needed to translate that into item-level quantities, alerts, and supplier-ready drafts. Solving that last-mile problem made the project much more realistic and valuable. Project impact This project helped me think beyond prediction and toward decision support. It showed me how data engineering, forecasting, and automation can work together to solve a real operational problem. More importantly, it reinforced the idea that good systems are not just accurate — they are simple enough to adopt and useful enough to change behavior.

Built With

• a-practical-stack-for-this-solution-would-be-python-+-fastapi-for-the-backend
• alerts
• and-aws-lambda-or-containers-for-lightweight-deployment.-for-sms-alerts-and-supplier-messages
• and-drafted-purchase-orders.-?-redis-for-caching-weather-responses
• and-orchestration-scripts.-?-fastapi-for-exposing-endpoints-such-as-inventory-upload
• and-order-drafting
• apache-airflow-for-scheduled-daily-data-pulls-and-reorder-jobs
• api-integration
• but-python-is-the-more-natural-choice-for-the-analytics-heavy-parts.-data-and-storage-?-postgresql-to-store-shop-profiles
• docker-for-packaging
• event-lookups
• forecast-generation
• forecasting-logic
• go-could-also-be-used
• historical-sales
• postgresql-for-inventory-and-sales-history
• production-ready-apis.-?-optional-sql-for-reporting-queries-and-reorder-analytics.-?-if-the-system-needs-a-small-worker-service
• redis-for-caching-short-lived-forecasts
• since-it-is-designed-for-fast
• sku-master-data
• supplier-details
• twilio-is-a-natural-fit-because-its-programmable-messaging-api-is-designed-for-sending-and-receiving-texts-programmatically.-languages-and-framework-?-python-for-data-ingestion