The dispatcher's side hustle: real stories of coolwave members who turned operations insight into community transit apps

Every day, dispatchers and operations analysts solve complex transit puzzles: balancing on-time performance with limited resources, predicting delays, and communicating changes to riders. These skills are highly specialized—and increasingly, a handful of coolwave members have realized they can apply them outside their day jobs. By building community transit apps, they create tools that fill gaps left by official systems, often for neighborhoods or route types that are underserved.

This guide draws on anonymized, composite experiences from several operations professionals who launched side projects. We'll walk through the common motivations, the step-by-step process, the tools and economics, the growth challenges, and the risks. Our goal is to give you a realistic, actionable framework—not a formula for guaranteed success, but a map of the terrain so you can decide if this side hustle fits your skills and circumstances.

Why operations professionals build community transit apps

The spark often comes from a simple frustration: the official transit app doesn't show real-time crowding, or the schedule data for a local bus line is consistently inaccurate. For a dispatcher, this isn't just an annoyance—it's a puzzle they know how to solve. Many coolwave members started by scraping publicly available GTFS feeds and combining them with crowd-sourced data to produce a more useful interface.

The gap between official data and rider needs

Public transit agencies typically release data in standard formats like GTFS (General Transit Feed Specification) for schedules and GTFS-RT for real-time updates. However, these feeds often lack granularity: they might not show which trains are wheelchair-accessible, or they update too slowly to reflect sudden detours. Riders want information that is timely, accurate, and tailored to their specific commute. A dispatcher who has spent years reading these feeds can spot the gaps immediately and knows how to fill them without reinventing the wheel.

A composite example: The bus crowding app

One coolwave member, whom we'll call Alex, worked as a rail dispatcher for a regional transit authority. On his commute, he noticed that the bus he took home was often full, forcing him to wait for the next one. The official app showed only scheduled arrival times, not occupancy. Over a few weekends, Alex built a simple web app that used historical GTFS-RT data and a lightweight prediction model to estimate crowding levels. He shared it on a local subreddit, and within a month, hundreds of riders were using it. The project never made money, but it saved commuters time and gave Alex a sense of purpose beyond his day job.

Why not just complain to the agency?

Many operations professionals try internal channels first, but government agencies move slowly. A side project allows for rapid iteration and direct user feedback. Plus, the skills learned—data processing, API integration, user interface design—can enhance a dispatcher's career, opening doors to roles in transit technology or data analysis.

Core concepts: What you need to know before starting

Building a community transit app requires understanding three interconnected layers: data sources, technical stack, and user experience. Each layer has its own constraints and trade-offs. We'll break them down so you can assess your starting point.

Data sources and licensing

The foundation of any transit app is data. Most public transit agencies provide GTFS and GTFS-RT feeds under open licenses, but you must check the terms. Some require attribution, others prohibit commercial use. If you plan to monetize—even through donations—you need to ensure compliance. Additionally, real-time feeds often have rate limits or require an API key. A dispatcher's familiarity with these feeds gives them an edge: they know which fields are reliable and which are often stale.

Technical stack choices

You don't need to be a professional developer to launch a side project. Many coolwave members started with no-code or low-code tools: Airtable for data storage, Zapier for automation, and a static site generator like Hugo for the front end. Others, with some programming background, used Python with Flask or FastAPI for the backend, and React or Vue for the interface. The key is to choose tools that match your current skills and the app's complexity. A simple arrival-time board can be built in a weekend with JavaScript and a hosted GTFS parser. A full-featured trip planner with real-time rerouting is a multi-month project.

User experience pitfalls

Riders expect a polished, mobile-friendly interface. A common mistake is focusing on the backend logic while neglecting the front end. Test your app on actual phones, not just desktop browsers. Also consider accessibility: color contrast, screen reader compatibility, and support for multiple languages if your community is diverse. One composite scenario involved a dispatcher who built a robust prediction engine but used a dark theme with low contrast, making it unreadable outdoors. After a few complaints, he redesigned it with input from actual users.

Execution: A repeatable process for building your first app

Based on the experiences of several coolwave members, we've distilled a seven-step process that balances speed with quality. This is not a rigid formula, but a starting point that you can adapt.

Step 1: Identify a specific, narrow problem

Don't try to replace Google Maps. Instead, focus on a pain point that affects a defined group: riders on a single bus route, or users of a particular station. For example, one member created an app that sent push notifications when a specific train line was delayed more than 10 minutes—something the official app didn't offer. The narrower the scope, the faster you can launch and iterate.

Step 2: Validate the need before coding

Talk to potential users—fellow commuters, local transit advocates, even drivers. Ask open-ended questions: 'What information do you wish you had before leaving home?' 'What frustrates you about the current apps?' This step prevents building something nobody wants. One dispatcher spent a week interviewing 20 riders at a bus stop, which led him to prioritize real-time crowding data over schedule accuracy.

Step 3: Choose the simplest technical path

Start with a static prototype that uses sample data. For example, hard-code a few routes and arrival times in a spreadsheet, then build a basic HTML page that displays them. Show it to users for feedback. Only after you confirm the concept should you invest in a backend, database, and real-time feeds. This approach reduces wasted effort and keeps the project fun.

Step 4: Build a minimal viable product (MVP)

An MVP should do one thing well. For a transit app, that might be showing the next three departures for a specific stop, updated every 30 seconds. Don't add maps, trip planning, or social features yet. Launch it on a simple domain (e.g., bustracker.example.com) and share it in relevant local forums. Measure usage with a privacy-respecting analytics tool like Plausible or Matomo.

Step 5: Iterate based on real usage

Watch how people use the app. Are they checking it at certain times? Do they refresh frequently? Add features one at a time: first, a 'favorites' list; then, push notifications; later, a simple map. Each addition should solve a problem users have voiced. Avoid feature creep—every new feature increases maintenance burden.

Step 6: Handle growth gracefully

If your app gains traction, you'll face scaling issues: API rate limits, server costs, and support requests. Plan for this by using caching, choosing a scalable hosting provider (like Vercel or Railway), and setting up automated alerts for downtime. One member's app crashed on a snow day when usage spiked 20x; he learned to implement queue-based processing and a simple loading screen.

Step 7: Decide on sustainability

Side projects can fizzle out if they become a chore. Set boundaries: how many hours per week can you realistically spend? Will you accept donations, run ads, or keep it free? Many coolwave members chose to keep their apps free and non-commercial, treating them as public service. Others covered hosting costs through a 'Buy Me a Coffee' link. Few made significant money, but the non-monetary rewards—recognition, skill building, community impact—were substantial.

Tools, stack, economics, and maintenance realities

Choosing the right tools and understanding the ongoing costs can make or break a side project. Here we compare common approaches and their trade-offs.

Comparison of technical approaches

Cost breakdown

Most side projects can run on less than $20 per month. A typical stack: domain name ($12/year), static hosting (free or $5/month), a small VPS for backend ($5–10/month), and a free tier of a database service (like Supabase or Firebase). Real-time data feeds may incur API costs if you exceed free limits; caching aggressively can keep costs down. One member's app served 5,000 monthly active users on a $7/month VPS by using aggressive caching and only fetching real-time data every 30 seconds.

Maintenance burden

Apps require ongoing attention: GTFS feeds change quarterly, APIs get deprecated, and users report bugs. Plan to spend at least 1–2 hours per month on maintenance. Set up automated tests (e.g., a weekly script that checks if the feed still parses correctly). If you lose interest, consider open-sourcing the code so others can take over—several coolwave projects have been adopted by community volunteers.

Growth mechanics: Building an audience and sustaining momentum

Even a great app needs users. Growth for community transit apps is hyperlocal and word-of-mouth driven. Paid advertising rarely makes sense; instead, focus on grassroots channels.

Distribution channels that work

The most effective channels are neighborhood social media groups (Nextdoor, Facebook groups, local subreddits), flyers at bus stops (with permission), and partnerships with local transit advocacy organizations. One member got a mention in a local newspaper after a reporter used the app and wrote a short piece. Another created a simple referral program: users who shared the app got a 'premium' feature (like push notifications) for free.

Measuring success beyond downloads

Don't obsess over download numbers. Focus on retention: are people using the app weekly? Do they return after the first try? An app with 500 loyal users who rely on it daily is more valuable than one with 10,000 one-time downloads. Set up simple cohort analysis using a spreadsheet or a free analytics tool. Also track qualitative feedback—emails or comments that say 'this saved me 30 minutes today' are worth more than any metric.

When to say no to growth

Rapid growth can overwhelm a side project. If you're spending more time on support than development, consider scaling back features or adding a waitlist. One member capped his user base at 2,000 by requiring a free account, which also gave him a way to communicate changes. He deliberately kept the app small to maintain quality and his own sanity.

Risks, pitfalls, and common mistakes

No side hustle is without risks. Here are the most common issues coolwave members encountered, along with practical mitigations.

Burnout and overcommitment

The biggest risk is turning a passion project into a second job. Set a strict time budget (e.g., 5 hours per week) and stick to it. Use a project board (Trello or a simple checklist) to track tasks and avoid scope creep. If you feel resentment when working on the app, take a break—it's supposed to be a side hustle, not a grind.

Data reliability and liability

Your app may display incorrect information due to feed errors or bugs. This can lead to missed buses or frustrated users. Mitigate this by displaying a disclaimer: 'Data provided by [agency] and may be delayed. Always check official sources for critical decisions.' Also implement a 'report an error' button. One member faced a legal threat from a user who missed a train because the app showed an incorrect departure time; he quickly added a prominent disclaimer and fixed the data parsing bug.

Conflict with employer

Check your employment contract for clauses about side projects, especially if you use similar data or tools. Some agencies have strict policies about using internal data for external apps. Even if you use public feeds, the perception of a conflict can be problematic. Be transparent: many coolwave members informed their managers and received support, as the projects often improved community relations. If your employer objects, you may need to choose between the project and the job.

Technical debt and abandonment

As you add features, code quality can degrade. If you stop maintaining the app, users will be left with a broken tool. Plan for an exit: document the architecture, open-source the code under a permissive license, and announce a deprecation timeline if you decide to shut down. A few coolwave projects have been forked and continued by other developers.

Frequently asked questions

Do I need to know how to code?

Not necessarily. No-code tools can handle many simple use cases. However, some coding knowledge (even just HTML/CSS and basic JavaScript) gives you more flexibility and control. Many dispatchers picked up coding through online courses like freeCodeCamp or The Odin Project while building their apps.

How do I handle real-time data if I'm not a developer?

Services like Transitland or OpenTripPlanner offer APIs that abstract away some complexity. You can also use Google Sheets with a script to fetch and display data, though this is not suitable for high-traffic apps. For a low-volume app, a simple Python script running on a free tier of PythonAnywhere can fetch and serve data.

Can I make money from this?

Yes, but it's challenging. Donations, small ads, or a 'premium' tier (e.g., ad-free experience or advanced filters) can cover costs. A few members earned a few hundred dollars per month, but none replaced their full-time income. If your goal is profit, consider building a niche app for a specific underserved route, then licensing the technology to other communities.

What if my app gets popular and I can't keep up?

This is a good problem to have. You can recruit volunteers from the user community, or apply for a small grant from a local transit foundation. Some projects have transitioned to a cooperative model where users contribute to development. If you're overwhelmed, it's okay to scale back features or put the app in maintenance mode.

Next steps: Turning insight into action

If you're a dispatcher or operations professional considering a community transit app, start small. Pick one route, one data gap, and one weekend to build a prototype. Talk to riders before you write a line of code. Choose tools that match your current skills, and don't be afraid to launch a rough version.

Remember that your operational insight is a genuine asset: you understand the data, the constraints, and the real-world needs in a way that outside developers often miss. That perspective can make your app more useful and more trusted by the community.

Finally, be kind to yourself. Side projects should energize you, not drain you. If at any point the app feels like a burden, step back. The transit system will survive without your app, but your well-being won't. The coolwave community is full of people who have built something meaningful—and then moved on when the time was right. Your next project could be just as valuable.