We Built a Trade Show App in One Day. Here's What It Actually Took.

in-cosmetics Global is the largest trade show in the personal care ingredients industry. 983 exhibitors across three levels of Paris Expo Hall 7. Three days. Thousands of visitors walking in circles because the official floor plan is a PDF and the exhibitor list is alphabetical.

We built a route planner that fixes this. No signup. No login. Pick your must-visit exhibitors, get the shortest walking route across all three levels. It runs offline, installs like a native app, and works on any phone.

The build took one day. 31 commits. Here's what that day looked like and why it matters for anyone thinking about building useful tools fast.

The problem nobody solves

Every trade show has the same problem. You arrive with a list of 30 booths to visit. The floor plan gives you an alphabetical list and a static map. By lunch, your legs hurt and you've crossed off maybe 8 names.

The official in-cosmetics app lists exhibitors. It doesn't route you between them. Nobody at any trade show I've attended in 15 years has solved this properly. Not because it's impossible. Because the build cost never justified a tool that's useful for three days.

That calculation changed.

What we built

The route planner at incos.corial.app does three things.

First, it finds walkable paths. The app has the real floor plan data for all three levels. Every booth has coordinates. The pathfinding algorithm knows where you can walk and where booths block the path. Pick two points, and it finds the actual walking route between them.

Second, it optimizes the order. If you're visiting 15 booths, the app figures out which sequence minimizes your walking distance. This is the Traveling Salesman Problem, one of the classic optimization challenges in computer science. Our solver uses a nearest-neighbor heuristic plus a 2-opt optimizer that swaps route segments to find shorter paths, running up to 50 iterations.

Third, it handles level changes. Escalators and staircases are in specific locations at Paris Expo Hall 7. The router knows where they are and factors in the distance-equivalent of a level change (about 60 meters) so it picks the right escalator instead of sending you to the far end of the building.

The whole thing runs client-side in the browser. No server. No API calls. Install it on your phone and it works without internet. Three days of conference, zero dependence on venue wifi.

The part that isn't about engineering

Smart mode finds the shortest route. That's the obvious feature. Every route planner does some version of this.

Fitness mode finds the longest route.

Same algorithmic framework, opposite objective. Instead of nearest-neighbor, it uses farthest-neighbor heuristic. Instead of optimizing route segments to be shorter, the 2-opt runs in reverse, swapping segments to lengthen the route. The app tracks kilometers, calories burned, and step count.

I built an algorithm to deliberately make your route worse. People are using it unironically.

This feature didn't come from a spec. It came from knowing the audience. Trade show attendees in cosmetics and biotech talk about their step counts. It's a running joke. "I did 22,000 steps yesterday." "Only 22? Amateur."

Fitness mode turned a utility into something people screenshot and share. That kind of product decision doesn't come from code. It comes from spending 15 years walking those halls.

The build: one day, 31 commits

Here's the honest breakdown of what AI-assisted development looked like on this project.

Claude Code wrote the A* pathfinding algorithm. It wrote the TSP solver. It handled the floor plan rendering, the coordinate mapping, the responsive layout. I didn't write pathfinding from scratch. I described the problem, reviewed the output, tested on my phone, and corrected course.

What I did: every product decision. Which three routing modes to build. How cross-level routing should work. The fitness mode concept. The UI priorities. What to cut. When to ship.

That split is the whole story. AI handles implementation velocity. The human handles domain knowledge and product judgment. Neither works alone.

Two years ago, a project like this would need a developer for a week minimum. Frontend, pathfinding logic, PWA configuration, responsive testing, offline support. Call it 40-60 hours of work. Today it takes one person with domain knowledge and AI tools one focused day.

That's not a marginal improvement. That changes what's worth building.

The stack

For anyone curious about the technical choices.

Astro plus Svelte for the framework. Astro handles static site generation and routing. Svelte handles the interactive components, the map rendering, the route calculation UI. Fast, lightweight, no unnecessary JavaScript.

TailwindCSS for styling. TypeScript throughout. The app is a Progressive Web App, installable from the browser with full offline support via service workers.

A* pathfinding runs on a walkability grid derived from real booth coordinate data. The floor plan gets divided into cells. Booth cells are blocked with a small margin. The pathfinder navigates walkable cells to connect any two points.

Everything runs in the browser. No backend. No database. No API keys. Deploy it, forget about it.

What this proves

The route planner works. People use it. But the real point is what the build says about speed.

A useful tool for a specific audience. Technically solid, not a prototype. Shipped in one day. No ongoing maintenance cost.

If you're a niche B2B company thinking about tools for your customers, your trade show, your community, the math has changed. The question used to be "can we afford to build this?" Now the question is "what problem do we know well enough to solve?"

That second question is where domain expertise becomes the bottleneck, not development time. We spend our days in that gap. Knowing industries deeply enough to build what they actually need.