From messy inputs to useful outputs

The challenge

Supermarket product listings use different names, formats and price conventions. Comparing a basket across stores requires collecting those listings regularly and keeping products, prices and sale information organised.

What we built

• Separate scrapers for Naivas, Carrefour and Greenspoon, with CSV import for manually collected prices.
• Small scheduled collection batches designed to fit serverless runtime limits.
• A PostgreSQL data model that records product, store, price, sale flag, source and last-checked time.
• A public interface for comparing products and basket costs, including mixed-store baskets.

Design choices

Store-specific collection logic keeps source quirks isolated. A shared product and price structure supports comparisons, while timestamps and source fields make freshness visible and help investigate unexpected values.

What this demonstrates

A complete path from source collection to a user-facing product, including the practical need to handle changing pages and incomplete source coverage. This is a live public product; availability and collected prices can change.

The question

Given customer account history and usage behaviour, can a model rank customers by likelihood of leaving so a retention team can investigate who may need attention?

Approach

• Compared a neural network with XGBoost using cross-validation.
• Handled class imbalance because churn cases are less common than retained customers.
• Reviewed calibration and feature importance alongside standard classification metrics.
• Reported ROC-AUC 0.967, accuracy 0.894 and F1 0.844 for the evaluated dataset.

How to read the results

Those metrics describe performance on the dataset and evaluation setup used for this portfolio model. They do not guarantee performance on another organisation’s data. Before real use, a model would need validation on representative, current data, review for bias and operational impact, and monitoring after deployment.

What this demonstrates

Prediction quality is more than a single accuracy figure. Comparing models, checking calibration and explaining influential features are all part of deciding whether a score is useful enough to support a business action.

The challenge

Stock spreadsheets can vary in column names, formats and completeness. Loading them without checks risks silently mixing inconsistent values or losing records that need review.

What we built

• CSV ingestion and validation into standard fields such as medicine name, generic name, manufacturer, batch, expiry, dosage, quantity and price.
• Rejected rows are written separately instead of disappearing from the run.
• Outputs can be written to PostgreSQL, CSV, or both.
• Each run reports missing values, numeric summaries and common categories; Docker-backed PostgreSQL and a small desktop interface support operation.

Design choices

Validation makes data issues visible at the boundary. Keeping rejected records with the run gives a reviewer a way to correct source files and rerun without losing the original problem rows.

What this demonstrates

A practical, auditable ingestion pattern for structured files. This public repository is a demonstration project; it is not presented as a deployment in a clinical or pharmacy environment.