What you are building
A local-first listing board for one neighborhood where a resident can find, create, save, contact, or close listings and requests.
Lab 1 homework - due July 25
Build the first slice of your hyperlocal system.
Use the next two weeks to turn the MAL product brief into a runnable local-first app. Your stack is your choice. The review focuses on product clarity, architecture, accessibility, security, local AI, and delivery.
Outcome
A small app with serious architectural signals.
Payments, delivery, chat, KYC, moderation dashboards, and backend infrastructure are intentionally out of scope. The first useful local loop is the priority.
Who it serves
A resident of a Mumbai neighborhood who wants a lightweight way to discover, request, lend, sell, or share nearby goods and services.
How it is reviewed
Organizers review a runnable project, useful docs, a three-minute demo, and evidence that Lab 1 learnings shaped the implementation.
Required implementation
Six parts to make visible.
Choose your own stack, but keep boundaries visible. Reviewers should be able to see what belongs to product, storage, UI, security, accessibility, and local AI.
Product loop
- View listings or requests for one neighborhood.
- Create a listing with title, category, description, approximate area, and contact preference.
- Open listing details and mark a listing saved, contacted, or closed.
- Add one small product feature from your own product angle.
Accessibility
- Clear labels for tappable controls.
- Readable listing cards for screen readers or platform accessibility tooling.
- Visible form errors, not only color changes.
- Usable tap targets and text scaling.
Security and privacy
- Keep secrets and API keys out of the shared project.
- Avoid exact home addresses and precise live location.
- Input validation before saving listings.
- Data reset or deletion for local app data.
Local AI
- Choose listing helper, search helper, or safety helper.
- Put AI behavior behind a
LocalAiServiceor equivalent boundary. - Provide deterministic fallback that works without a model.
- Use a local model or deterministic fallback for the expected AI flow.
Architecture
- Write
docs/adr/0001-local-first-marketplace-slice.md. - Explain local-first choice, storage boundary, product logic, AI isolation, and future change points.
- Keep local storage behind a repository or data source interface.
Documentation
docs/product-slice.mddocs/success-metrics.mddocs/accessibility-check.mddocs/security-baseline.mdanddocs/local-ai-note.md
Success metrics
Define success before you build too much.
Create docs/success-metrics.md on Day 1. Each metric should be testable during review without real users or production deployment.
| Area | Metric | Example target | How reviewers check |
|---|---|---|---|
| Product | Main workflow completion | Create and find a listing in under 3 minutes | Run the demo script |
| Activation | First useful action | Create first listing without help | Manual demo or usability check |
| Local-first | Offline/local persistence | Listing survives refresh, restart, or relaunch | Create, close, reopen |
| Accessibility | Core flow accessibility | Feed and create form work with accessibility tooling | Review accessibility notes and UI |
| Security | Data minimization | Avoids exact address, precise location, secrets, and hosted AI keys | Review data model and repo |
| Local AI | Helpful action with fallback | Editable AI output works without network access | Disable network or model path |
| Architecture | Clear boundaries | UI, storage, product logic, and AI can change independently | Review ADR and code structure |
| Reliability | Main flow stability | No crash across feed, create, persist, reopen, details | Run demo twice |
Two-week plan
One hour per day. No heroic scope.
The sequence is intentionally narrow: define, build the core local loop, apply Lab 1 themes, then harden the demo.
Day 01
Product slice
Define workflow, categories, out-of-scope items, and success metrics.
Day 02
App skeleton
Set up chosen stack, first screen, theme, and run instructions.
Day 03
Domain model
Add neighborhood, listing, category, status, and contact preference.
Day 04
Listing feed
Show neighborhood listings with readable cards and empty state.
Day 05
Details
Open listing details and update saved, contacted, or closed state.
Day 06
Create form
Add form fields, validation, visible errors, and keyboard flow.
Day 07
Persistence
Save locally through a repository or data source boundary.
Day 08
Accessibility
Audit core screens, fix labels, focus order, tap targets, and errors.
Day 09
Security
Document data, tighten validation, avoid precise location, add reset.
Day 10
AI boundary
Create local AI interface and deterministic fallback checks.
Day 11
AI workflow
Integrate AI helper into listing, search, or safety review.
Day 12
ADR
Write the local-first architecture decision and future change points.
Day 13
Demo hardening
Polish seed data, states, and three-minute manual test script.
Day 14
Final review
Package the project, list known gaps, and verify fresh-run instructions.
Sharing
What to share.
Share one project repository or packaged project folder. The project does not need to be publicly deployed, but it should run locally or on your target platform from the instructions you provide.
A project folder or repository that contains the app.
README.md with setup, run, and demo instructions.Language, framework, and local storage approach documented.
Product, success metrics, accessibility, security, local AI, and ADR docs included.
Shared project keeps secrets, dependency folders, and generated build outputs out.
Listing feed, create listing, local persistence, and AI fallback work.
Three-minute demo script or recording ready.
GitHub readiness
Make the project understandable from the repo home page.
Organizers should be able to open the repository, understand the stack, run the app, and find the evidence documents without needing private context.
A helpful README includes
- Project name and one-sentence product summary.
- Platform, language, framework, and local storage choice.
- Setup command, run command, and test command if available.
- Three-minute demo script and known gaps.
- Links to all required files in
docs/.
Keep out of the shared project
- API keys, tokens, secrets, or personal contact details.
- Dependency folders such as
node_modules. - Generated build folders, simulator artifacts, or dependency caches.
- Large model files unless they are essential, license-safe, and documented.
- Real personal data or exact addresses.
Organizer review
How organizers can review.
Each review can take 10-15 minutes. The review recognizes a working, explainable slice that applies Lab 1 themes, not the largest feature set.
Step 01
Review readiness
Check that the project opens, run instructions exist, platform is documented, useful docs exist, repo hygiene is clean, and known gaps are listed.
Step 02
Demo validation
Run or watch the demo: first screen, neighborhood, feed, create flow, persistence, status, AI helper, accessibility, and security decisions.
Step 03
Evidence check
Review docs and code boundaries for product, success metrics, accessibility, security, local AI, and ADR claims.
Step 04
Risk checks
Call out backend-dependent core flow, hosted AI API use, precise location, committed secrets, no persistence, or missing ADR.
| Area | Points | What good looks like |
|---|---|---|
| Product | 3 | Clear user, problem, scoped workflow, and one small personal product addition. |
| Core workflow | 4 | Feed, create listing/request, details/status, and local persistence work. |
| Accessibility | 3 | Implemented in UI, not only documented. |
| Security | 3 | Data minimization and local storage risks are addressed. |
| Local AI | 3 | AI feature has a fallback and does not require hosted APIs. |
| Architecture | 2 | Feature boundaries are visible, storage and AI are isolated, ADR is clear. |
| Metrics | 1 | Metrics are testable and include one project-specific metric. |
| Delivery | 1 | Runs from a fresh checkout or copy and demos in three minutes. |
Keep scope sharp