Direckt.

Direckt originated during the Mayo Business Plan Competition at TCNJ, a multi-round university venture competition where student teams validate a business model, pitch to alumni judges, and compete for seed funding. More than 80 ventures applied; Direckt placed 3rd and was awarded $10,000. The product idea came from a specific friction: accessibility information existed, but was scattered across PDFs, unofficial notes, and word-of-mouth—making “is this route accessible right now?” hard to answer in the moment.

The work was split across two founders. Yarden Merin owned the financial model (pricing, TAM, and plan structure). I owned product vision, brand and interface design, and the build for the marketing site and interactive prototype.

The competition itself shaped what was possible. The required submission was a 20–25 page business plan plus mandatory LinkedIn learning modules on building a business and developing a business plan. Everything else—slides, prototype depth, and how the story was told—was optional. After advancing from written rounds into semis, there was roughly a month to prepare for finals. Instead of a static deck-only pitch, the focus became demonstrating a believable user flow without institutional data partnerships or a full backend.

The identity work started with hand sketches and early logo directions before moving into vector refinement. Several concepts established direction, but they did not hold up equally across small UI contexts, monochrome states, and horizontal layouts. I returned to sketching, isolated the arrow-in-motion concept, and rebuilt the mark and wordmark as scalable vectors.

Building a vector brand system before writing core UI code reduced downstream rework. It gave us stable assets for navigation, app icons, and marketing surfaces while preserving consistency across breakpoints and export targets. Typography followed the same process: multiple font families were tested for readability and tone, then narrowed to Rubik for headings and Atkinson Hyperlegible for body copy to support clarity and accessibility. The blue palette was chosen for clear contrast and familiar trust signaling in institutional contexts, not for decoration.

UX work started with flow definition before visual polish. The prototype needed to be usable on a phone and legible to non-technical judges, so core journeys were mapped first, then translated into wireframes to remove ambiguity around states and navigation:

One flow anchored the demo: scan a QR code and land on a physical accessibility asset page (elevator, ramp, or door) showing what it is, where it is, and whether it’s currently usable. From there, the interface supported browsing the same information via a map or a list view, intentionally keeping the list view simple for mobile adoption and accessibility needs, including a more predictable reading order for screen readers.

A Figma component system was established before frontend implementation: shared spacing rules, type scale, semantic color tokens, and reusable components for cards, forms, dialogs, and navigation elements. This made it possible to iterate on structure and interaction patterns in design files instead of rewriting React components during every product discussion.

You can interact with the prototype here: direcktaccess.com/example-campus.

The frontend stack is React, TypeScript, Vite, and Tailwind. React provided predictable component composition for multi-surface flows (marketing pages plus the in-app prototype views). Tailwind enabled fast, consistent implementation against design tokens without maintaining large custom CSS abstractions early.

Vite was chosen over Create React App for practical reasons: faster cold starts, faster hot-module replacement, and leaner production output with less bundler overhead. TypeScript was enforced across the codebase to make component contracts explicit, catch prop/data mismatches early, and keep route-level state transitions auditable as the project expanded.

We used Radix UI primitives as the baseline for accessible interactions, then adapted styling and behavior to our layouts. The difficult part was not rendering components; it was preserving keyboard and screen-reader behavior in complex states.

One repeated hurdle was coordinating map interactions with dialogs and detail panels. Opening a dialog from a map marker could easily break focus order, trap keyboard users in nested regions, or produce unclear announcements for screen readers. The solution required explicit trigger labeling, controlled focus return on close, and strict testing of tab/shift-tab escape paths across overlays. That work was iterative and often required rolling back visually correct implementations that failed interaction audits.

For the competition build, the experience was intentionally demoable without a live backend: most data was mocked so flows could be clicked through reliably on stage. Supabase was selected as the future backend boundary (auth + data) and was partially explored, but the priority was proving the UX: QR-to-asset lookup, map vs list browsing, and a dashboard concept for how updates would be managed.

Deployment was structured as a repeatable workflow: GitHub as source of truth, branch previews on Vercel, review before merge, then production promotion to direcktaccess.com. The goal was not a one-time launch; it was a reliable CI/CD loop where every change could be tested in isolation and shipped with low operational risk.

Direckt placed 3rd out of 80+ ventures and was awarded $10,000. Finals were delivered on one of the biggest stages on campus with a live Zoom broadcast, using the prototype to make the experience tangible beyond the business plan.

The most important outcome wasn’t just funding—it was directional clarity. Judge feedback pushed the product to think bigger than a single university and consider how a standard for accessibility information could extend to public buildings and transportation hubs.

Building Direckt under competition constraints reinforced a practical lesson: adoption depends on reducing effort in the “in-between” moments. Mobile-first decisions, a simple list alternative to a dense map interface, and a QR-driven entry point all came from the same question—what would someone actually do while moving through campus?

Personally, pitching this idea in front of a judge panel reshaped how I think about product communication. A well-designed interface helped, but clarity came from making trade-offs explicit and using the prototype to show intent without over-promising implementation.

• The earlier write-up implied a more complete backend/admin/auth system than what was demoed. For finals, the strength was an interactive, reliable prototype—not production data.
• The shipped prototype flows (QR → asset page, map vs list browsing, dashboard concept) were under-described, which made the story feel more abstract than the product actually was.
• Competition stakes and constraints (80+ ventures, multi-round judging, one-month sprint) weren’t emphasized enough relative to the amount of work accomplished.
• If revisiting the project, the next steps would be structured usability sessions (including people with disabilities), a baseline accessibility audit, and lightweight instrumentation around key flows like QR scans and asset status checks.

Learn more about the experience on my LinkedIn.