Situation
The operating context the client was working inside before anything changed.
Each project covers the problem inherited, the decision that changed direction, and what the system delivered, measured rather than estimated.
7 projects / 2023-2026
Serious software is judged after handoff. These case files show the operating problem, the choice that changed the system, and the evidence we expect to hold after launch.
The client problem, the decision made, and the measured result for every project in the current record.
The client needed a full commerce ecosystem, not a single storefront — a customer-facing web platform, a native mobile app, and a complete administrative system to run the business behind it. There was no existing platform to extend; this was architecture through launch, end to end.
Built a full admin dashboard supporting 19 distinct roles and permission sets, in-house Live Stream and Shorts features instead of third-party integration, and structured DEV → QA → UAT cycle with consistent client status reporting.
Corporate training needed to run at scale across very different roles, each requiring a different level of access and responsibility. A single generic interface couldn't accommodate the operational differences between administrators, trainers, managers, and learners.
Replace one generic interface with five function-specific access tiers, each built for exactly what that role needs to do, backed by full UAT and training documentation.
Astrology consultation was still offline and appointment-based, with no way for users to connect with astrologers on demand. The service had no digital equivalent for real-time consultation.
Build a two-sided platform — consumer app plus a dedicated astrologer dashboard — so both sides of the marketplace could actually operate, delivered through sprint-based cycles to 2.0 beta.
Silver prices move by the minute, and customers had no live, trustworthy reference to trade against. A stale rate on screen erodes trust immediately for price-sensitive buyers.
Engineer real-time pricing as the platform's core reliability requirement, not a bolt-on feature, with live market rates and secure transactions buyers could act on instantly.
Generic PM tools don't adapt to how PM, Developer, QA, and Client roles actually make decisions. Status updates and task handoffs were eating up time that should have gone into actual project work.
Build role-specific portals with an integrated LLM automation layer handling task routing, status, and reporting directly inside the workflow.
Nepal's first UGC-QAA certified engineering college needed a website that actually reflected that credibility. The existing site didn't communicate the college's unique positioning or program differentiation.
Structure the site around real program differentiation — including Nepal's only Biomedical Engineering program — instead of a generic college template, built as a CMS the college can maintain.
A recruitment firm positioning itself as a strategic partner, not a staffing agency, needed a site serving two distinct audiences — employers and candidates — without diluting either message.
Split employer and candidate journeys at the top level, backed by a visible 4-step methodology and real placement metrics displayed directly on the page.
Every case is documented through four questions: what was happening, what was breaking, what decision changed the system, and what improved after launch.
The operating context the client was working inside before anything changed.
The specific failure, constraint, or risk that made the status quo unsustainable.
The call we made, technical or structural, and why we made it over the alternatives.
What changed after launch, documented in metrics the client can verify.
Tell us what is breaking, what is unclear, or what needs to scale. We will tell you honestly whether we can help.