Just in Time | Devpost

Loading Screen
Home Page

Inspiration

Every interface in existence was designed once, for an imagined "normal" user, and then frozen forever. If your eyes don't work the way that imagined user's did, if you need higher contrast, larger targets, or no interface at all and just a voice that understands you, you're not using a slightly worse version of the product. You're locked out of it. We started with the people the current model of software fails the hardest: people who are blind or have low vision, for whom "just use the app" is often not true at all. But the deeper idea isn't a feature for one group, it's that a UI built around one fixed shape was always going to fail someone. An interface that rebuilds itself around whoever's using it, in the moment, doesn't just serve blind users better. It's a better idea for everyone: the person cooking with wet hands, the person who's exhausted, the person overwhelmed by an app with forty buttons when they needed three. We built for the hardest case first, because if it works there, it works everywhere.

What it does

You talk to it. Out loud, hands free, no screen required. A physical device: touchscreen, four buttons, a slider, and a microphone that's actually listening hears what you need and builds the exact interface for that moment, live. Ask it to walk you through a recipe and it reads each step aloud, confirms where you are, and adapts the second something goes wrong, too much sugar in the bowl, and it diagnoses the mistake and offers a fix out loud, no screen-reading required. Every interface it generates is checked against real WCAG AA contrast requirements before it's ever allowed to render, a hard gate, not a guideline: fail the check, and a certified, legible fallback takes over instead, automatically, every time. That same guarantee that makes this reliable for someone with low vision is exactly what makes it effortless for someone who's just tired, distracted, or has their hands full. Accessibility isn't the edge case here. It's the whole design principle, and it happens to make the product better for literally everyone who touches it.

How we built it

A TypeScript monorepo, four packages doing four distinct jobs: schema is the validated contract every other package codes against; tokens holds the palettes, the contrast math, and a hard rule that nothing generated is ever allowed to paint a light background onto our dark shell; renderer turns a live-generated JSON spec into real, accessible components on the fly, no fixed per-screen layouts, ever; server runs the actual AI orchestration, taking a spoken request all the way from voice to a validated, on-screen (or read-aloud) response.

At the center of that pipeline is Jev: a small, purpose-built model we trained specifically to make the fast, structural decisions a UI needs instantly, what layout fits this request, what style it should take, what the next screen even is. Where most AI-generated interfaces route every decision through a large, slow, general-purpose model, Jev is deliberately tiny and constrained to a fixed set of typed outputs, it never freehands a layout, it selects from a known, certified vocabulary in milliseconds. That's what makes real-time voice-to-interface possible at all: you can't wait several seconds for a giant model to think before a screen appears. A heavier generative pass still runs afterward for anything more expressive, but it's layered on top of an already-fast, already-valid interface, never a blocking dependency. We think that split, a fast specialized model for structure, a slower generative one for polish, is the actual architecture real-time generative UI needs, not a single model trying to do both badly.

Challenges we ran into

The real one: two people editing the same files at 2 a.m. under a deadline is where things quietly break. An automated fix, made in good faith, silently deleted a teammate's in-progress work while patching something unrelated, we caught it by stopping and reading the actual diff instead of trusting a green checkmark, and rebuilt every line of it correctly. Separately, we found a badge that failed accessibility contrast in our default theme, not some edge case, the theme every user sees first, invisible until someone actually ran the math instead of trusting the color looked fine. That one stung, because it's exactly the group we set out to build for, and it's why we now run that check automatically on every single generated screen instead of trusting a human to catch it. We also found buttons that lied, a "Back" control that moved you forward, and rebuilt the input layer so every control does exactly what it claims, every time.

Accomplishments that we're proud of

We shipped a device that actually listens, actually generates a real interface in response, and actually enforces its own accessibility, end to end, no fallback to a script. Jev alone is something we're proud of on its own terms: a working, purpose-trained model making real UI decisions fast enough for a live conversation, instead of leaning on a slow general-purpose model and calling it "AI-generated UI." Our design system compounds that: every palette checked against real contrast math, not approved by eye, and that check runs automatically off whatever Jev and the generative pass just produced, so an entire category of accessibility bug can't quietly come back, because there's no manual step left to forget. That's not a small thing for a product whose entire premise is trust: someone who can't see the screen has to be able to trust that we got it right every single time, not most of the time. We also recovered a teammate's lost work mid-hackathon by going back to source and rebuilding it right, instead of shipping around the gap.

What we learned

That tests passing and nothing being broken are two different claims, and the gap between them shows up exactly when you're moving fastest and least inclined to check. We also learned, more than anything, that designing for the hardest case first doesn't narrow a product, it sharpens it. Every decision we made for someone who can't see a screen: voice-first control, a mandatory contrast gate, an interface simple enough to describe out loud, turned out to be the same decision we'd want for anyone. Real accessibility work isn't a checklist bolted onto the end. It's a better definition of the product, for everyone, discovered by taking the hardest user seriously first.

What's next for Just in Time

We don't think this stops at one device, or one kitchen. The same model, a fast, specialized decision-maker like Jev paired with a contrast-certified rendering layer, applies anywhere software currently assumes a "normal" user: a car dashboard, a hospital kiosk, a classroom, a public terminal. We want to take Jev further too: more templates in its trained vocabulary, more languages, and eventually a version specialized enough to run fully on-device, so the fast path never depends on a network connection at all. We want to take this beyond cooking into other domains entirely and get real hardware into the hands of people who'd benefit most, starting with partnerships with organizations already working in blind and low-vision accessibility. Long term, we think "accessible" should stop being a compliance checkbox chased after a product ships, and start being the only way an interface is allowed to exist in the first place, decided instantly, by a model built for exactly that job. We think that's where every interface eventually has to go. We're just building the first one that already works that way.