Prototype Development

Working functionality is a quarter of Lock 3

Twenty-five of Lock 3’s hundred points sit on "working functionality" — the single largest criterion anywhere in Foundry. It means an evaluator can open your link, perform your core loop and see real output from real logic. Screens with hard-coded responses are detectable and score as what they are.

Build order that survives reality

Teams that invert this order — polish first, integration last — are the ones whose demos break. Integration is where the unknown unknowns live; meet them early.

• Week one: the core loop end to end, ugly — real input, real model, real output
• Then: the failure states — unsure model, bad input, offline
• Then: the impact-metric instrumentation, so your demo produces evidence
• Then: polish, in the time that honestly remains

Choose boring, deployable technology

Your stack should be the one your team already knows, deployed on free tiers that stay up during evaluation. A plain web app that works on a mid-range phone beats a native app that needs sideloading. Evaluators access your prototype cold — no setup call, no "it works on our laptop". Test your live link from a different device, network and account before submitting.

Honesty about limitations scores points

Lock 3 explicitly asks for known limitations. This is not a trap. "Diagnosis accuracy drops on photos taken in shade; we display low-confidence warnings below 0.7" demonstrates engineering maturity. Claiming none signals either dishonesty or not testing — both worse.