LineLens

About the project

Inspiration

Small businesses often learn that a service experience failed only after a customer has already left and written a review about a long line. A neighborhood café or retailer rarely has access to the operations tools used by large companies, and even a simple average wait time can hide the people most harmed by an unpredictable visit.

We wanted to make operational experimentation understandable and accessible: a business should be able to ask, “What changes if I move one person to prep during the rush?” before testing that change with real customers.

What it does

LineLens is an explainable operational digital twin for a neighborhood business. It models a two-hour rush as virtual customer journeys through order, prep, and handoff stations. The app identifies the bottleneck, estimates modeled walkout risk and at-risk revenue, then lets an owner compare practical changes such as a rush-hour flex barista, mobile pre-order, or batching high-volume drinks.

The key feature is the time-budget fairness guardrail. LineLens separately evaluates commuters, caregivers, and regulars with different documented time budgets. A scenario is not called a win just because the average improves while a time-constrained group still faces a high modeled abandonment rate.

How we built it

We built LineLens as a privacy-first static web application with vanilla JavaScript, HTML, and CSS.

The simulation engine is original, deterministic code. It:

1. Generates rush-hour customer arrivals from a reproducible seed.
2. Assigns each virtual customer a time budget from a transparent persona mix.
3. Routes customers through multi-server order, prep, and handoff queues.
4. Samples triangular service-time distributions using minimum, likely, and maximum service times.
5. Flags journeys that exceed their time budget as modeled walkouts.
6. Re-runs the exact same arrivals and random stream after a scenario change, so the comparison measures the system change rather than a different sample.

The codebase separates representative configuration, the pure simulation engine, state orchestration, accessible UI views, and client-side CSV export. The app also includes automated tests for reproducibility, distribution bounds, queue capacity, surge behavior, comparison calculations, and recommendation guardrails.

Challenges we ran into

The hardest problem was avoiding a misleading simulation. It would have been easy to show an attractive number without explaining where it came from. We addressed that by keeping every assumption visible, using deterministic seeds, and comparing the baseline and scenario against the same virtual demand.

We also had to avoid treating a lower average wait as automatically fair. The equity lens was added because a commuter with a nine-minute budget and a regular with an eighteen-minute budget experience the same queue very differently.

Finally, we tuned the interface to make a systems model understandable in seconds. The Twin view now leads with the constrained station, the business consequence, and the next experiment instead of burying the decision in a dashboard.

Accomplishments that we're proud of

• Built a working, reproducible queue simulation instead of an AI-generated advice interface.
• Made counterfactual comparisons fair by holding arrival patterns and service-time randomness constant.
• Added a time-budget fairness guardrail so efficiency gains do not hide access failures.
• Created an accessible, responsive interface with keyboard-operable controls, visible focus states, semantic structure, labels, and high contrast.
• Wrote ten automated tests for the simulation’s core behavior and edge cases.
• Kept the prototype private by design: it runs locally with representative data and no account, API key, or customer data.

What we learned

We learned that explainability is a product feature, not just a technical detail. A business owner needs to understand why a recommendation exists before acting on it.

We also learned that “better on average” is not enough. Modeling time budgets made it possible to see when a proposed change still leaves a real customer journey behind.

What's next for LineLens

Next, we want to let a business safely import anonymized point-of-sale or ordering events, learn service-time distributions from those events, and run scenario batches in a tenant-scoped background worker. We also want to add experiment tracking so an owner can compare the simulation’s forecast with the actual outcome after a two-week test.

Built With

• apis
• browser
• css3
• github
• html5
• javascript
• node.js
• node:test