Compare / vs. building it in-house
Transit OS vs. building it yourself
In-house wins on fit and on independence, and it is a real option if you have a developer on staff who is not leaving. It fails on maintenance — not on the build, which usually goes fine, but on year three, when the person who wrote it has moved on and nobody can safely change it.
Where building it in-house genuinely wins
- Perfect fit. It does exactly what you do, including the parts nobody else's software understands.
- No recurring licence, and no vendor who can raise a price or discontinue a product.
- Your data is unambiguously yours, in a database you control.
- Institutional pride and capability that stays in the building.
Where we win
- Somebody else carries the maintenance, the security patching and the spec changes.
- GTFS, GTFS-Realtime and reporting formats move; keeping up with them is our job, not your evenings.
- It is already built, so the comparison is next week versus next year.
- When your developer leaves, the software does not become unmaintainable.
| building it in-house | Transit OS | |
|---|---|---|
| Fit to your process | Exact | Close, with edges we will name honestly |
| Up-front cost | Staff time — commonly underestimated by half | $149–$899/month |
| Time to working | Months to a year | An afternoon |
| Ongoing maintenance | Yours, forever | Ours |
| Keeping up with GTFS spec changes | Yours | Ours |
| Security patching | Yours | Ours |
| Survives the developer leaving | Usually not | Yes |
| Independence | Total | Partial — mitigated by full open export |
The in-house build is more common in this sector than vendors admit, and it is often good. Somebody in the office was capable, understood the operation better than any vendor would, and built something that fits perfectly.
How it actually ends
Almost never in a failed build. The build usually works. It ends in year three: the person who wrote it has changed jobs, the framework is three major versions behind, nobody remembers which of the two database columns is authoritative, and a one-line change now carries risk nobody can quantify. So the change does not get made, and the system slowly stops describing reality — which is exactly the spreadsheet failure, in a more expensive costume.
The build is not the cost. The tenth year is the cost.
When to build anyway
- You have a developer on staff as a permanent role, not a temporarily available person.
- Your operation is genuinely unlike anything else, in ways you can name specifically.
- You have a plan for who maintains it in five years, and that plan is a job description rather than a name.
If all three are true, build it. And publish it — the sector is full of agencies with your exact problem and no budget, and that would be a real contribution.
Questions
Could we build on top of your API instead?
Yes, and some agencies should. The API and webhooks are on the higher tiers, and the export is open on every tier. Using us as the system of record and building your own surface on top is a legitimate architecture, not a workaround.