Our Women Coding Community Team Takes 3rd Place at the GNEC Fall Hackathon
+“Nourish Together” team: Silke Nodwell, Ainan Ihsan, Tammy Sisodiya, Nino Godoradze
+What does it take to win a hackathon? For our team of four from Women Coding Community, the answer is a combination of persistence, experimentation, and the resilience to tackle each new challenge together.
+This fall, we competed in the Global NGO Executive Committee (GNEC) Hackathon, which focused on the UN Sustainable Development Goals of No Poverty and Zero Hunger. Our team, Nourish Together, placed 3rd out of more than 150 teams. Over eight weeks of evening meetings, trial-and-error, and bursts of productivity, we built a working prototype we’re really proud of. Here’s how it came together.
+In August, Tammy put a message in the WCC Slack about the GNEC hackathon, asking whether anyone was interested in joining a team. Within a couple of hours, we had a full team. We met virtually a few days later and quickly realised how international our group was: four people across three countries and time zones, spanning the US, Sweden and the UK.
+At first, we struggled. “Poverty” and “hunger” are enormous, complex issues, and none of us worked directly in those domains. Coming up with a focused idea felt daunting.
+Eventually, we realised that instead of trying to design for communities we didn’t know well, we could design for a group whose needs we did understand: donors. Donors have both the resources and the technology to use an app, and, crucially, we felt equipped to empathise with their decision-making process.
+So we framed our problem simply:
+How might we help donors confidently identify charities aligned with their values?
+Our initial concept was intentionally broad: a website that could help donors explore both financial and non-financial ways to contribute. As part of this, we imagined an “impact tracker” that visualised how each donated dollar translated into tangible outcomes.
+Around this time, I had seen an impressive prototype built with Lovable at work and suggested we try it for our UI. Lovable turned out to be ideal. It enabled us to quickly build a polished mock impact tracker that displayed the journey of each donation and showed how many families could be helped through that contribution.
+After the impact tracker was in place, Tammy added an embedded food bank map. It connected directly to Google Maps so users could instantly find their nearest food bank if they preferred donating food rather than money.
+With the core website established, we began exploring how to make the platform more intelligent. That was when the idea of a charity recommender emerged. At first, we approached it as a conventional machine learning problem. At the same time, I was reading Prompt Engineering with LLMs with the WCC book club, which sparked the question:
+Instead of building a traditional machine-learning recommender, what if we built an LLM-powered one?
+In true hackathon fashion, we opted for the simplest approach that could work. Rather than running a full large language model, we implemented a recommender using a Sentence Transformer, a smaller and more efficient model designed to convert text into vector embeddings, or numeric representations that capture meaning.
+We generated embeddings for each charity’s description and stored them in a FAISS index, which is optimised for fast similarity search across large collections of vectors. This setup is similar to a Retrieval-Augmented Generation (RAG) system, where relevant items are retrieved based on semantic similarity rather than exact keyword matches.
+When a user entered a query, it was embedded in the same way and compared it against the stored charity embeddings using cosine similarity, a common metric for measuring how close two vectors are in high-dimensional space. The nearest matches became our recommendations. The result was an intuitive, natural-language experience for our ‘Find Your Perfect Charity’ feature.
+In the beginning, we tried assigning fixed roles. This approach collapsed almost immediately because volunteer schedules are unpredictable. Some weeks one of us had time to take on multiple tasks, while other weeks we were barely available. We switched to leaving tasks unassigned; anyone could pick up an item from the list as long as they kept the group updated on their progress.
+Working fully online added its own challenges. During one evening sync call, we realised that we needed uninterrupted time together if we were going to deliver something cohesive. So we all agreed to take a full day off work to focus on the project. This became a turning point. It aligned our codebase, resolved repository issues and built crucial momentum.
+What followed was a very determined weekend sprint.
+Integrating the FAISS index into our Lovable website was more complicated than expected. After several failed attempts, we switched to a new plan. We deployed the recommender on Railway as a standalone Cloud API and connected this API to our Lovable front end.
+This approach worked, but not without challenges. On Saturday night, Ainan stayed up late resolving dependency issues. Early on Sunday morning, I picked up where she left off and finally got the API communicating with the UI.
+Meanwhile, Nino, who lives in the United States and has the most video-editing experience, logged in at 1 pm UK time. She edited a beautifully polished demo video, only to discover that it was thirty seconds too short for the submission requirements. To fix this, we recorded a quick Teams call introducing ourselves and added it to the final cut. It ended up fitting perfectly.
+We had eight weeks to complete the project, yet we still submitted with only thirty minutes to spare. Hackathon law, surely!
+Lovable for creating a clean, engaging UI
+Railway for hosting our FAISS-based recommender as an API
+Gamma for transforming plain text into polished slides
+This project was not only about building an intelligent website for donors. It was also about learning how to collaborate flexibly, make practical technical decisions and sustain momentum even when the path forward was unclear.
+If there is one lesson we are taking forward, it is this:
+A hackathon team succeeds when it stays adaptable.
+Not when roles are perfectly assigned, or when the plan unfolds neatly, but when everyone leans in however and whenever they can.
+We are proud of our 3rd-place finish, proud of the product we built and even prouder of how we worked together. Above all, we are grateful for Women Coding Community, which brought this team together and made this experience possible.
+Building portfolio projects for Data Engineering can be challenging outside enterprise environments due to limited access to realistic data, missing business context, and cloud costs.
+Below are four practical portfolio projects that aspiring data engineers can build to showcase real-world skills. Each project focuses on a commonly used data engineering pattern and can be implemented using open-source tools or managed cloud services
+A Finance team requires an audit-ready daily sales report delivered every morning by 8:00 AM, based on the previous day’s completed orders. This is a classic batch data engineering scenario where data must be processed on a fixed schedule with strong guarantees around correctness, reproducibility, and scalability.
+| Environment | +Storage | +Processing | +Scheduling | +
|---|---|---|---|
| Local / Open-Source | +MinIO | +Spark Docker | +Airflow | +
| AWS | +Amazon S3 | +AWS Glue | +Glue Triggers | +
| GCP | +GCS | +Cloud Dataflow | +Cloud Scheduler | +
A Customer Support team needs immediate visibility into stuck orders (e.g., payment complete but products not shipped) to intervene before customers churn. This is a classic real-time operational use case, where events must be processed as they occur with guarantees for correctness and timeliness.
+| Environment | +Event Capture / CDC | +Stream Processing | +Storage / Query | +Alerting / Monitoring | +
|---|---|---|---|---|
| Local / Open-Source | +Debezium + Kafka | +Spark Structured Streaming | +MinIO + DuckDB | +Python / Spark triggers, Prometheus + Grafana | +
| AWS | +DMS + Kinesis | +AWS Glue Streaming | +S3 + Athena | +CloudWatch / SNS | +
| GCP | +Datastream + Pub/Sub (CDC) | +Cloud Dataflow | +GCS + BigQuery | +Cloud Monitoring + Pub/Sub alerts | +
A Marketing team runs campaigns across Google Ads, Meta, and Email. They need a single source of truth to consistently analyse total spend, conversions, and campaign performance across channels. This is a classic analytics engineering use case, where raw ingestion data is transformed into curated, analysis-ready models.
+| Environment | +Storage | +Processing | +Data Warehouse / Product Layer | +
|---|---|---|---|
| Local / Open-Source | +DuckDB / MinIO | +Spark Docker | +DuckDB | +
| AWS | +S3 | +AWS Glue | +Redshift | +
| GCP | +GCS | +Cloud Dataflow | +BigQuery | +
A factory floor needs to monitor high-frequency IoT sensor data to detect overheating machines or abnormal energy usage before equipment fails. This is a stateful streaming use case, where it is critical to compute averages, trends, and anomalies in real time.
+| Environment | +Ingestion | +Stream Processing | +Storage / Query | +Monitoring & Alerting | +
|---|---|---|---|---|
| Local / Open-Source | +Kafka | +Apache Flink | +InfluxDB | +Grafana / Python triggers | +
| AWS | +Kinesis | +Managed Service Apache Flink | +Timestream | +CloudWatch / SNS | +
| GCP | +Pub/Sub | +Dataproc for Apache Flink | +Cloud Bigtable | +Cloud Monitoring / Pub/Sub alerts | +