HAILIE

AI for Better Housing Hackathon Pilot: Attendee Guide

Event details

  • Date: Thursday, 26 February 2026
  • Time: 09:00–14:00
  • Location: 2 St Peter’s Square, Manchester M2 3AA
  • Problem statement: “How can we use generative AI to reshape social housing?”
  • Fee: £20.00 (used to compensate social housing tenants for their time and valuable insights)

What this is

A focused, high-impact session where 30 attendees form small groups to rapidly develop Proof-of-Concepts (PoCs)—what we’re calling “vibe-coded” solutions—to illustrate innovative ideas.

Why you’ve been invited

We’ve hand-picked this first cohort (sector experts, tech leaders, and tenants) with a view to potentially scaling this format. We have also partnered with RISE UP to give their customers the opportunity to gain insight into Housing, Data and Technology and create new contacts within the sector.

Register

https://www.gravitasgroup.co.uk/events/connected-communities-ai-for-better-housing-hackathon
(We’ll send payment details after you sign up.)

What you’ll do on the day

  1. Form a small team and pick one problem slice to tackle.
  2. Build a tiny demo or prototype that shows the idea working.
  3. Create a simple 1-page README (assumptions, data needed, risks/guardrails, next steps).
  4. Deliver a 2–3 minute demo/pitch.

Ground rules (important)

  • No personal data: do not paste tenant identifiers, case notes, or anything confidential into AI tools. Use synthetic/anonymised examples.
  • Keep it small: one thin user journey that works beats a big idea that doesn’t.
  • Centre lived experience: solutions should reflect tenant needs and real constraints.
  • Be explicit about risk: include safety/ethics/operations guardrails in your README.

What to bring

  • Laptop + charger
  • Optional: GitHub account (to share a repo) or Google/Microsoft account (to share a doc or use Gen AI)
  • Optional: VS Code or any editor you like

AI quickstart (practical, not theory)

A simple prompt structure that works (copy/paste)

  1. Goal: What are we trying to achieve?
  2. Context: Who is the user, what’s the housing setting, what constraints matter?
  3. Inputs: What can we provide (synthetic examples are fine)?
  4. Output format: What should the answer look like (table, checklist, JSON, user stories, minimal app)?
  5. Guardrails: What should it not do (no personal data, explain assumptions, list risks, include tests)?

Reusable prompt patterns (copy/paste)

  • Option sprint: “Give 5 PoC ideas ranked by impact vs effort for this problem. For each: target user, workflow, data needed, risks/guardrails, and a 90-minute build plan.”
  • Scope lock: “Propose a PoC we can demo in 90 minutes. List what we will NOT do.”
  • UI-first: “Create a one-page mock user journey: screen 1 → screen 2 → output. Use placeholder/synthetic data.”
  • Build in small steps: “Make the smallest working version first. Then add one feature at a time. Output only the changes each step.”
  • Testing: “Write 6 acceptance tests in plain English + 3 edge cases.”
  • Risk check: “List the top 10 failure modes (privacy, bias, hallucination, safeguarding, misuse). Propose mitigations and what should be disclosed to users.”

“Vibe coding” workflow (fast and safe)

  • Choose one user flow (one screen if possible).
  • Build the smallest working slice first; test as you go.
  • Keep AI outputs constrained and check them—avoid big code dumps.
  • Use clearly-labelled synthetic data (e.g., “FAKE”, “DEMO”) or clearly-labelled open data (e.g. government publications).
  • Capture assumptions and risks in the README as you build.

Learning links (hands-on)

License

This page is licensed under CC BY-SA 4.0 (you may share and adapt with attribution and the same license): https://creativecommons.org/licenses/by-sa/4.0/