Projects
Case studies
Every case follows the same six fields — context, my role, constraints,
what I did, outcome, tools — so they can be compared rather than just read.
Clients are identified by industry and country only; client-confidential
detail is left out on purpose.
Client deliveries at MoEngage.
- Context
- The client's onboarding onto our platform had been delayed for roughly two years with no single cause: requirements were ambiguous and scattered across chat, email and calls, decisions had no clear owner, and none of the teams involved was accountable for the whole. The client's marketing team was waiting on a platform they couldn't yet use.
- My role
- Took over as the single owner of the integration — project manager, solution architect, support engineer and QA in one. Owned requirements, the plan, and the escalation route into engineering and product.
- Constraints
- Already two years stalled on arrival·a regulated banking environment with slow change approval·multiple stakeholder teams with no clear decision maker·a fragmented communication history
- What I did
-
- Met stakeholders face to face to find the actual decision makers, then gathered requirements from the right people — architecture, use cases, and what they genuinely wanted to achieve.
- Consolidated every scattered requirement into one project plan and had the client confirm it in writing, so ambiguity had to surface early.
- Built a detailed tracker as the only status that counted, retiring parallel updates, and established a RACI so ownership stopped being implicit.
- Ran weekly alignments with a fixed agenda: decisions, blockers, next commitments.
- Escalated technical blockers the moment they appeared — not after they became delays — and personally resolved support issues and QA'd deliverables.
- Outcome
- A project stale for two years was restarted, brought under control, and delivered within eight months. The client named the change in clarity and pace unprompted.
- Tools
- One consolidated requirements document, chosen to replace chat as the record·a tracker so every blocker had an owner and an age·RACI, so ownership could be argued in writing rather than in meetings
- Context
- Sales had committed to migrating the client's marketing campaigns without realizing they were built on developer-grade templating logic, not drag-and-drop content. The commitment was made, the timeline was fixed, and the skills didn't yet exist in the team.
- My role
- Project manager, developer and QA on the migration — and the person who closed the skills gap.
- Constraints
- A deadline already promised to the client·complex legacy campaign logic in one templating language (Liquid) that had to land in another (Jinja)·multiple markets live in parallel·marketing and engineering to coordinate in each market
- What I did
-
- Learned Jinja to the depth the campaigns required, fast.
- Built internal tooling to convert the legacy Liquid campaign code to Jinja rather than hand-porting each campaign, using AI-assisted workflows to compress both the learning curve and the porting effort.
- Rebuilt and tested every campaign to confirm behavior matched the original across markets.
- Documented the approach and trained the team as the internal SME for this client's campaign architecture, so the knowledge didn't stay with one person.
- Outcome
- All P0 campaigns delivered on the promised timeline, with consistent behavior across markets and a team that could now maintain them.
- Tools
- Jinja and Liquid templating·an internally built conversion tool·AI coding assistants — chosen because the deadline allowed neither a slow learning curve nor manual porting
- Context
- Migrating push tokens for a user base in the tens of millions carries a real risk of silently losing reachable users. That risk had been under-explained, so the client's CXO escalated and put the whole engagement in question — they were openly weighing whether to build the capability in-house instead.
- My role
- Owned the de-escalation end to end: the written response, the internal alignment behind it, and the call with the CXO.
- Constraints
- A C-level audience with a technical objection·tens of millions of tokens with no acceptable data loss·trust already damaged·an internally sensitive build-vs-buy question that had to be answered honestly
- What I did
-
- Sent a complete written clarification the same day — speed of response was itself part of the fix.
- Aligned internally with senior leadership, engineering and product first, so the client heard one position rather than three.
- Laid out the actual migration risk and its mitigation step by step, instead of reassuring.
- Hosted a structured call on the in-house-versus-platform trade-off, including where the platform is the weaker choice — the part that made the rest credible.
- Outcome
- Escalation closed within a week, expectations reset, and the project continued with the CXO's confidence restored — no re-platforming.
- Tools
- A written technical brief rather than a deck (a CXO reads before they meet)·SDK and push-delivery documentation as the shared technical reference·internal alignment in writing first, so nothing was improvised live
- Context
- Six months of POC and contract cycles had produced a signed deal and no plan. Pre-sales had made commitments nobody wrote down, and the client's person-in-charge resigned before handover. The scope covered a portfolio of brands across dozens of mobile apps and web properties, against a hard December go-live.
- My role
- Wore every hat on our side — solution architecture, project plan, support engineering and QA — on the first portfolio-scale engagement of its kind for us in Southeast Asia.
- Constraints
- A hard go-live date·uncommitted pre-sales promises to reconcile·institutional knowledge lost with the PIC's resignation·legacy systems across many brands·a scope too large for any sequential approach to make the date
- What I did
-
- Built the solution architecture across the brand portfolio and negotiated feature scope with management stakeholders until the committed set was actually deliverable.
- Built a full project plan with Gantt, RACI and scope trackers, and ran daily standups.
- Escalated gaps to leadership early rather than absorbing them, and realigned expectations — client-side and internal — about what the pre-sales promises could and couldn't mean.
- Organized a one-week onsite to resolve the major cross-team blockers in person.
- Outcome
- Major gaps closed within two weeks of taking over. Go-live landed one month behind the original date — by agreement: the client accepted the reconciled scope with documented notes and proceeded confidently with the platform.
- Tools
- Gantt-based plan, RACI and scope trackers·daily standups·a deliberately chosen onsite week — because the blockers were cross-team and political, not technical, and those don't resolve over tickets
- Context
- The client had just built a data lake that still carried significant inconsistencies, ran its newsletters on a legacy system, and had no unified profile per customer — the same reader looked like different people across publications and channels.
- My role
- Project manager, QA and support engineer for the migration onto our platform.
- Constraints
- Legacy newsletter infrastructure·a young, inconsistent data lake as the source of truth·multiple publications, apps and dashboards that all had to behave consistently·a small team relative to the surface area
- What I did
-
- Designed the solution directly with stakeholders, face to face — the data-lake inconsistencies made intermediated written requirements unreliable.
- Held the delivery timeline across workstreams.
- Ran manual QA across the client's apps, dashboards and email output, gating release on everything matching the approved designs.
- Outcome
- The launch phase landed on time across publications, apps and dashboards, with post-launch issues closed within days. The unified-profile workstream is ongoing — design and testing complete.
- Tools
- Face-to-face solutioning (chosen over written requirements, given the data-lake state)·structured timeline tracking·manual cross-surface QA against design as the release gate
Things I built myself, written up with the stack and the reasoning.
Side project2026
Check-in, a real attendee database, and the returning-vs-new split my community could never work out. Next.js, Supabase, Recharts, on Vercel.
Next.jsSupabaseRecharts Read the case study →