// De Occidente
A route finder that actually finds your route
Concept redesign of the website of a passenger transport cooperative in Valle del Cauca, Colombia. Fewer platforms to maintain, a core service that makes sense at first glance, and a far simpler infrastructure: from a WordPress with 9 plugins to a static site with no server of its own, no database and no AI APIs.
114 → 22
requests to load the home page, current site vs. the concept
185
routes across 46 towns, with fares, intermediate stops and transfers
0
servers or databases to maintain
1
single data source: routes, timetables and offices feed every screen
// context
Where it started
Cooperativa de Transportadores de Occidente connects some 46 towns across Valle del Cauca and Colombia's coffee region. Reviewing their current site (October 2026), this is what I found:
The core service is hard to look up. To learn what a trip costs you type the origin into a text box and open one page per route (101 pages, each edited separately). You cannot pick origin and destination, nor find out what to do when there is no direct route.
Two platforms to maintain. The blog's last post is from August 2022, while the cooperative's social media is updated often. Keeping the same content in two places is costly, and the website is the one left behind.
Visual problems. In the footer, the logo, the Supertransporte seal and the developer credit fail to load, and the contact page logs at least 6 broken resources.
Heavy infrastructure. WordPress with a Divi-based theme and 9 plugins. Loading the home page takes 114 requests and 67 scripts. Every plugin is something to update and watch.
The contact form gets stuck on “loading” when submitted, with no confirmation and no error.
// problem → solution
Problems I solved
What I foundTwo platforms to maintain. The blog has not been updated since 2022; social media has.
Replaced the blog with a “Latest from our social media” section pulling live Facebook posts: it updates itself whenever the cooperative posts, with nobody editing the site.
What I foundBroken images, stray icons and a dated style.
A clean, modern design. Every referenced image exists and loads; photos and videos are optimized.
What I foundWordPress, 9 plugins, 114 requests and 67 scripts for the home page.
Static site: 22 requests and 1 script. No database or plugins to update; it deploys from GitHub to Vercel in minutes.
What I foundFares spread across 101 pages, edited one by one.
A single data source. Change one fare and it updates in the finder, the tables, the “from” cards, the map and the assistant.
What I foundThe core service, travelling, was the hardest thing to look up.
An origin–destination finder that only offers reachable places, an interactive network map and a fare calculator with transfers.
What I foundPhone numbers and offices scattered around.
A directory of 20 service points with search and filters, cross-checked against the “Offices” stories on their Instagram.
What I foundA form that gets stuck on “loading”.
A working form, with confirmation on submit.
// what I built
What I built
A finder that thinks like the passenger
- Once you pick an origin, the destination only offers reachable places, split into “direct route” and “with transfer”.
- Tolerates accents and typos: “tulua”, “la union”, “roldanilo” all work.
- Three-stop routes are treated as one route that also serves its intermediate stop.
- Every search lives in the URL, so it can be shared.
A network map and fares with transfers
Tap a town and the map highlights the places you can reach directly and those that need a transfer. When there is no direct route, the engine finds the best combination (up to two transfers) and adds up the fares.
A route assistant, without generative AI
A chat that runs entirely in the browser. It recognizes towns inside a sentence, remembers context (“and the way back?”) and answers with routes, fares, timetables and office phone numbers. When it does not understand, it offers suggestion buttons instead of making things up.
Timetables you can actually check
I transcribed 19 timetable blocks from the cooperative's Instagram stories, and each route card shows the “next departure” based on Colombia's local time.
Performance and detail
Compared with the current site, the concept's home page goes from 114 to 22 requests, from 67 scripts to 1, from 101 fare pages to a single data source and from 9 plugins to none. My first version of the redesign weighed 58 MB in images and video; today it weighs 4 MB. Entrance animations respect the “reduce motion” setting.
// judgment
The decisions that matter most
Rules instead of a language model
The universe is small and every question has exactly one correct answer. A model would have added cost per query, latency and the risk of inventing a fare. With rules, the answer is the same every time, works without any API and costs nothing per use. Not every problem calls for AI, and knowing when not to use it is part of the job.
Honesty with the data
I reconciled my fare survey with the public pages: 74 routes had different fares, and I found errors such as a misspelled town and a route with two contradictory prices. Of the 185 routes, 99 are confirmed against the official site and 86 are not. The interface says so: “Fare to be confirmed at the ticket office”. I would rather have a site that admits what it does not know than one that fakes certainty.
Simple infrastructure
A WordPress needs a server with PHP and a database, and lives off updating plugins and themes. A static site is just files: deployed from GitHub to Vercel, with nothing to patch. And the route engine is independent of the interface, so the same code could power a WhatsApp bot or an app tomorrow.
// next step
What I would do with real access
This concept was built from public information. With the cooperative as a client, I would continue here:
- 01An admin panel so the cooperative can edit fares and timetables without touching code.
- 02Real SEO: pre-render every route as its own page (“bus Cali Cartago fare”), with title, description and share image.
- 03Integrated parcel tracking, using the provider's API with their authorization.
- 04Personal-data consent and a working complaints channel, as Colombian regulation requires.
- 05The same assistant on WhatsApp, reusing the route engine.
Stack
React 18, TypeScript, Vite, Tailwind CSS, Motion. Code on GitHub, deployed on Vercel. The contact form uses EmailJS.
Disclaimer
This project is a redesign concept I made on my own initiative. It is not the official website and has no affiliation with Cooperativa de Transportadores de Occidente; their brand and content belong to their owners. The information comes from their public pages and social media. The contact form works, but messages reach me, not the cooperative.
Are your customers looking for information that already lives in your own data?
Tell me about your case and I'll propose how to solve it.