# Hike Developer Console

**Developer platform · Hike Messenger · 50M users · 2017–2018 · Arunkumar Alagarsamy**

> Every team shipping into the platform had built its own way to release — which
> siloed the teams and slowed every mini-app down.

The tool internal teams used to build and publish mini apps inside the messenger —
and the same console third-party companies later used to publish theirs.

## The problem

Teams across Hike Messenger were building mini apps into a platform with
**50 million users**. It started as internal tooling and later became the
third-party developer platform — without a redesign.

- **Teams worked in silos.** Each had invented its own way to push an app, and the
  process lived in people's heads.
- **Scattered information.** Not an absence of process — competing versions of it,
  no agreement between them, no structured path from build to release, and no shared
  vocabulary for what state an app was in.
- **Developer terminology was a wall.** My first design role — I had to learn what
  each term meant to a developer before I could design a flow around it.
- **Aligning teams and stakeholders** on a single process was the biggest hurdle.
- **The cost was real.** Publishing slowed to a crawl, and buggy apps reached users
  because nothing was consistently reviewed first.

## Getting everyone to one way

- **Interviewed the developers pushing mini apps.** Mapped what each team actually
  did, step by step — not what a process doc claimed.
- **Competitive analysis across six consoles** — Google, Apple, Facebook, Amazon,
  Opera, Kik — to find which modules all of them had, and why.
- **Then got the teams in a room.** I facilitated the sessions where the dev teams
  worked through the flows together and agreed on how publishing should actually go.
- **Iterated fast, in front of them.** Agreement came from seeing their own input
  land, not from a document circulated for sign-off.

## Two users, two weeks

| Publishing — first-time experience | Maintenance — long-term experience |
|---|---|
| Onboarding · App details · App release · Distribution · Manage testers · Feedback | Applications list · Analytics · Send notification |

Two different users on two different weeks. This split became the console's
structure — and it's why the same product later worked for third-party developers
without a redesign.

## Version management

States: **Draft → Under Review → In Testing → Testing Complete → Review Failed / Review Success**

- **A horizontal process across teams.** Development and testing move a version
  through a chain of states, and each state has its own call to action.
- A vocabulary, not a status badge. Everyone finally meant the same thing by "ready".
- **Review Failed carries the reviewer's feedback**, opened from the same screen.
  A gate that only rejects teaches nothing.
- Only a finalized version enters release.

### Design decisions

- **Verbose over minimal.** The process is genuinely complicated — so the screen
  spells things out rather than hiding detail behind a clean surface.
- **A timeline down the side** so a developer can see the whole flow, where their
  version is now, and the next action to take.

## Release management

| Stage | Exposure |
|---|---|
| Alpha | Inside the company first. |
| Beta | A percentage of real users. |
| Production | Chosen segments, by percentage. |

- Nobody ships to 50 million in one move. The interface makes the safe path the
  default path.
- Same shape as scoping what an agent may touch, and widening it as confidence builds.
- Each version targeted at named segments — Bangalore and Mumbai, Chennai and Trichy,
  Gujarat. Chosen, not assumed.

## Design system — UI

- Full state coverage across every flow: empty, filtered, loading, no results,
  expired OTP, error.
- Redlined type scale, hex with opacity, button and content-width rules.
- **Every form component specced through default, focused, typing, filled and error** —
  including visible focus states and inline error text.

## What it changed

One structured way to publish that every team had agreed to. The silos went, and
teams shipped faster than when each ran its own process — with a review and testing
stage that caught problems before users saw them.