beCorp
Shipping beCorporate’s enterprise ride-hailing platform on a deadline.
beCorp
3 mo
From kickoff to a beCorporate MVP running in production, on a deadline tied to be's broader 2018 launch and no room to slip.
1st
Shipping on the original date helped be become Vietnam's first homegrown ride-hailing service — a market until then carried by foreign super-apps.
be is a Vietnamese ride-hailing super-app — launched in 2018 by BE GROUP with four signature yellow services: beBike, beCar, beDelivery, and beRental. With more than $40M in early funding and a 2018 launch window, be had six months to put all four products in front of users.
beCorporate is be’s enterprise vertical — a ride-hailing service tailored for companies to schedule, book, and manage transport for their employees, individually or as a group, all through the beApp. The deadline didn’t move, but be’s engineering team was absorbed by the consumer launch, and an in-house Golang team was hard to staff in Vietnam in 2018.
We joined as an embedded squad of six, working alongside be’s ten engineers as one team of sixteen. We took on the beCorporate build end to end — the architecture, the Go services, the integrations into be’s cloud — and shipped the MVP within three months.
The first weeks were spent on architecture, not code. We drew beCorp twice — once as a standalone enterprise system, once as a service inside be's existing cloud, talking to its API gateway and monitoring stack. The first diagram protected our approach to enterprise-grade reliability; the second made sure everyone — be's platform engineers, our squad, the product side — saw the same interfaces, the same integrations, and the same boundary lines. The diagrams became the contract.
With the architecture confirmed, we built a deliberately empty version of beCorp — a "dummy" service that connected to be's existing infrastructure end to end. Logging, monitoring, crash reporting, and the CI pipeline went in before any business logic. By the time we wrote the first real feature, the operational scaffolding was already proven. Bi-weekly release iterations kept the build observable from kickoff, not retroactively.
We worked as part of be's team, not at arm's length from it. Sprint planning kept the work in lockstep with be's roadmap; technical knowledge-sharing sessions let us debate decisions with the platform team rather than around them. By the time the MVP shipped three months in, the engineers carrying it forward — ours and be's — were aligned on the same architecture, the same interfaces, and the same way of working.
“The deadline wasn’t a stretch goal. It was the constraint we built the architecture around.”
A few sentences about your team and what you're building is usually enough. We reply within three working days.