# When the grant ends, the platform does not

> How a grant-funded mobility pilot survives the day the funding ends, built on an open-core layer the agency owns instead of a bespoke one-off.

Grant-funded pilots usually die when the funding does. Build the integration on Veodyn's open-core layer and it becomes something the agency owns and keeps running.

## The setup

An agency wins a federal grant to build something genuinely useful. A complete-trip pilot, say: a rider with a mobility need can plan and book a journey that crosses paratransit, fixed-route transit, and a regional connector, with real-time updates the whole way. A contractor wires it together. It demos well. The agency wins an award for it.

Then the grant ends.

## The data problem

The integration that made the pilot work was bespoke. A contractor stitched a handful of agency feeds together for the duration of the grant, on the contractor's own tooling, on a timeline that ended when the money did.

When the grant closes, there is no budget to keep the contractor. The code that holds the integration together belongs to the contractor, not the agency. When one of the underlying feeds changes, nothing updates, because nobody is left who knows how it was wired. The pilot degrades quietly over a few months and then stops working. The award goes on the wall and the system goes dark.

This is the pilot cliff, and it is where a large share of grant-funded mobility projects end up. The problem was never the idea. It was that the integration was a one-off that could not outlive its funding.

## The Veodyn architecture

Build the same integration on Veodyn, and the part that used to be bespoke becomes the product.

Each agency in the pilot runs a node. The normalization across paratransit, fixed-route, and connector feeds is something Veodyn already does, not something a contractor hand-builds for this grant. The complete-trip experience reads from one normalized, open layer:

- **Schedules and stop geometry** (GTFS) across every participating service
- **Real-time arrivals and vehicle positions** (GTFS-RT) so the trip stays accurate as conditions change
- **Shared-mobility availability** (GBFS) where a bikeshare or scooter completes the trip
- **One open API** that the booking and rider-facing apps build on

The difference shows up the day the grant ends. The node code is the agency's, under an open-core license. The Community edition keeps running at no license cost. If the agency wants support, the Managed edition is there. When a feed changes, the normalization layer handles it the same way it always did, because it is a maintained product, not a frozen one-off.

> **Diagram.** Paratransit, fixed-route, and connector nodes feed an open-core hub that serves the booking and rider apps.

## What survives the grant

| What used to die at the cliff | Why it survives on Veodyn |
| --- | --- |
| **The integration code** - locked with the contractor | Open-core: the node code is the agency's to keep and run. |
| **Ongoing operation** - no budget for the contractor | Community edition runs at no license cost; Managed if you want support. |
| **Feed maintenance** - nobody left to re-wire it | Normalization is a maintained product, not a bespoke build. |
| **The rider-facing experience** | Keeps reading from the same open API it launched on. |

## What open-core doesn't fix

Open-core is not magic, and pretending otherwise would be the same overpromise that puts projects on the cliff in the first place.

Someone still has to run the node. The Community edition is free to license, but it is not free to operate: it needs a server and a person who keeps an eye on it, which is exactly why the Managed edition exists for agencies without that capacity. What open-core removes is the specific failure mode that kills grant pilots, the one where the code is locked with a contractor who is gone and the integration cannot be touched. It does not remove the need to operate the thing. It makes operating it possible on an agency budget instead of impossible without a grant.

## What happens after the grant

A grant buys a beginning. Whether the project has a middle depends on what happens when the funding stops. Because the data layer is open and the node belongs to the agency, the work the grant paid for becomes an asset the agency owns rather than a dependency that expires. Add an agency to the pilot, it joins the same layer. Renew or replace a vendor, the data stays put. That is the difference between an award on the wall and a service that is still running three years later.

## See it on your network

Tell us what your pilot has to connect and when the grant ends, and we will map the fit. [Book a call](https://cal.veodyn.com/sawinyh/30min).

## More solutions

Other programs Veodyn makes possible, walked end to end. Or browse [all solutions](https://veodyn.com/solutions/).

- [Regional coalition · multimodal - Regional rewards - One rewards program across a dozen operators](https://veodyn.com/case-studies/regional-rewards/)
- [State DOT · traffic management - Statewide traffic ops - One operating picture across every TMC](https://veodyn.com/case-studies/statewide-tmc-hub/)
- [State DOT · transit data - Statewide transit feed - One current GTFS feed for the whole state](https://veodyn.com/case-studies/gtfs-clearinghouse/)
- [State DOT · multi-jurisdiction - Local federation - Cities join without giving up their data](https://veodyn.com/case-studies/local-federation/)

---

Source: https://veodyn.com/case-studies/pilot-cliff/
This is the plain-Markdown twin of that page. Every page on this site has one at the same URL with ".md" appended, or by sending `Accept: text/markdown`. Site index: https://veodyn.com/llms.txt