What TARANSIT is.

A commuter on the Kolkata suburban rail network makes the same decision every day: which train do I take, and is it on time. TARANSIT answers that question in seconds, on the platform, with or without signal.

The full timetable lives on the phone. A commuter standing in a dead zone still gets complete connection search, because the app never needs the network to answer the basic question.

The live layer is crowdsourced. A rider on the train slides “I am on board”, and their phone becomes an anonymous beacon: their position updates the train’s live delay for every other rider watching that train. Pin the trip, and the delay follows you to the lock screen.

TARANSIT is free, and it is pre-revenue by choice. Ads are intentionally off while the product doubles as our growth lab: we would rather run a clean product and own an exact dataset than squeeze a banner. That is a decision, not an accident.

The job. Which train do I take, and is it on time.
Offline-first. The full timetable is on the device, so search works with zero signal.
On-Board live tracking. One rider’s “I am on board” turns their phone into an anonymous beacon that updates the delay for everyone.
Pinned trips. Live delay for your train, on the lock screen.
The build. An Android app built with Kotlin Multiplatform.
The territory. The suburban rail network of West Bengal, around Kolkata.

TARANSIT on Google Play

Why we run it as a growth lab.

Client work comes with redactions. Numbers get rounded, names get cut, and the method stays behind an NDA. TARANSIT is the product where none of that applies: we own the data, the code, and the mistakes, so we can publish the work down to the SQL.

That is why every number on this site is exact. 16,531 users, not “thousands”. 63.2 percent, not “most”. When a prospect asks how we got a number, we open the query. No client engagement allows that, and no slide can fake it.

Case study

Which users drive a transit app, and what we did about it.

The full record of the segmentation and activation analysis we ran on our own product, including the passes that failed.

The problem.

The analysis sample: 16,531 users, 160,000 connection searches, 90 days of behavior. On top of it sat one blended retention number, and it hid everything that mattered.

Inside that single number, the strongest group of users retained at 92.6 percent on day 30 and the weakest at 18.1 percent: a 74.5 point gap between people the blend treated as identical. The average user is an average of opposites.

Every decision made against the average was a decision made for a user who does not exist. Before anything could be fixed, the groups had to be found.

Ten passes before the groups separated.

This is the part most case studies leave out. The method did not work on the first try, and the record says so.

We built a priority-ordered SQL decision tree over 90 days of connections_found events: search frequency, active days, route consistency, weekday concentration, and route variety.
The first pass failed. 44 percent of users landed in one meaningless bucket, which is a segmentation that segments nothing.
We iterated in BigQuery against production data, rewriting thresholds until the buckets stopped overlapping. It took 10 passes before the groups separated.
We validated the survivors against everything else we track: retention curves, trip distance, screen navigation, session quality.
We ruled things out on the record. Timetable coverage, the assumed villain, was not the day-0 blocker.
What came out: 7 mutually exclusive groups, every user in exactly one, reproducible as SQL rather than a black box.

The dead ends stayed in the record, because a result you cannot audit is a result you cannot trust.

The seven groups.

Seven groups, from 566 Committed Commuters to 6,132 one-time Trial Users. The top three, 22 percent of the sample, drive 61 percent of all trips and hold 80 to 93 percent day-30 retention.

The largest group is the mirror image. Trial Users are 37.1 percent of the base and retain at 18.1 percent, against 92.6 percent for Committed Commuters. That is the 74.5 point gap the blended number hid, now with names, sizes, and SQL definitions attached.

Once the groups exist, strategy stops being abstract. You know who the product must never break (the 22 percent), who is worth converting (the middle), and who was never going to stay.

TARANSIT behavior segments from a clean sample of 16,531 users. The top three segments, 22 percent of users, generate 61 percent of all trips.
Segment	Users	Share of users	Day-30 retention
Committed Commuter	566	3.4%	92.6%
Light Commuter	1,035	6.3%	82.3%
Power Explorer	2,011	12.2%	80.0%
Weekend Traveler	754	4.6%	76.2%
Engaged User	1,290	7.8%	72.8%
Casual User	4,743	28.7%	35.2%
Trial User	6,132	37.1%	18.1%

We find these groups in your data

The single screen that decides who stays.

Activation came down to one screen: Connection Detail, where a searched trip becomes a plan. 63.2 percent of 6,132 trial users never reached it in their first session.

The failure modes have names and sizes. Results Ignored, 27.9 percent: users who searched and never tapped a result. Search Abandoned, 23.7 percent: users who started a search and stopped. Pure Bounce, 11.6 percent: users who opened the app and left.

The other side of the cliff is just as sharp. 95.4 percent of trial users who reach Connection Detail in their second session return the next day. And the first search matters: users who start with a long-haul trip retain at 34.3 percent against 55.1 percent for local-first users, a 20.8 point gap set in the first session.

We find the screen where you lose users

Segments move.

A one-off analysis treats segments as fixed. They are not. Each month, 27.5 percent of Trial Users upgrade to Casual. Each week, 10.6 percent of Casual Users upgrade to Committed, and 35.1 percent of Committed Commuters slip back to Casual, pushed by holidays and timetable gaps.

A segmentation you run once is a photograph of a moving object. The value is in watching the flows: which group is growing, which is leaking, and whether last month’s fix changed the direction.

We keep segments current, every month

What the work produced.

7 segment definitions as mutually exclusive SQL, rerunnable on any date range.
A ranked backlog of 7 activation and retention experiments, each sized XS to M.
The full iteration record, all 10 passes, dead ends included.
The event-tracking fixes underneath, so the next analysis starts from data you can trust.

That is the deliverable shape every client gets: the model, the plan, and the record. Not a slide.

Ship with agents

The other system behind TARANSIT.

The case study above is one half of how we run this product. The other half is who ships it: TARANSIT is delivered end to end by a 15-agent system we built and run ourselves, spanning product, engineering, growth, and knowledge work.

The delivery shape: a product lead agent writes the spec, an orchestrator routes it through a system architect, an implementation plan, and a developer, and a verify loop of test plus code review checks the result, with up to 3 revise rounds before anything ships. Every handoff is a written artifact, every phase ends at a human approval gate, and the whole system is grounded in an ontology of 16 enforced entity types that acts as the spec the agents build against.

This is capability proof, not a client outcome. The client outcome numbers are not in yet, and we will not pretend otherwise.

We teach engineering teams the method we actually use, not a method we read about.

Ship with agents

Run this on your product.

The same analysis, in your data. Three ways to start, depending on where you are.

Product Growth

You keep everything we build.

Book a 30-minute call.

We will tell you whether your product has a segmentation gap and whether we are the right people to close it. No pitch deck.

Book a call

or email hello@famaneo.com

TARANSIT