Work

Products we built, launched and still run.

These are ours. We defined them, designed them, built them, put them into production and support them — which means we've had to live with the architecture decisions rather than hand them over.

Client work is covered by confidentiality unless we're given permission to write about it. Rather than describe it vaguely, we'd rather show you something we can talk about in full detail.

MainteNex logo
Mobile · Community finance

MainteNex

Problem

An apartment community's maintenance accounts usually live in a spreadsheet one person owns, with payment proofs scattered across a WhatsApp group. The records are shared money, argued over at general body meetings, and nobody can answer who paid what, where it went, or how the corpus fund reached its current balance.

What we built

One mobile app that opens onto different products depending on who signs in — a resident, a community admin, or a guard at the gate — over an API that owns every money rule. Published on Google Play, with iOS to follow.

Key capabilities

  • Append-only corpus fund ledger
  • Scheduled invoicing that cannot double-bill
  • Pro-rata and equal expense splitting
  • Payment verification with part payments
  • Visitor pre-approval and gate log
  • English, Hindi and Telugu

Technology

Flutter with GetX and on-device PDF generation · NestJS 11 on Node.js 22 · PostgreSQL with Prisma, transactions and advisory locks · Firebase Cloud Messaging · Containerised deployment

TraceOn dashboard showing attendance and field activity for a workforce
Enterprise · Workforce operations

TraceOn

Problem

Attendance and field activity for staff who work away from an office. The network can't be assumed, the operating system fights any long-running background task, a GPS reading can't be trusted at face value, and a real organisation has a reporting structure that determines who is allowed to see whom.

What we built

Three surfaces over one core: a mobile app for field staff, an admin portal for managers and administrators, and the API and data layer both depend on.

Key capabilities

  • Offline attendance capture with later sync
  • Battery-aware background location tracking
  • Confidence recorded alongside every reading
  • Permission model following the org chart
  • Live dashboard, maps and movement trails
  • Analytics, time-slot reports and PDF export

Technology

Flutter with native platform channels · React 18, TypeScript, Vite · NestJS 11 on Node.js 22 · PostgreSQL with Prisma · Leaflet and React Flow · Docker on AWS with CI on merge

BookMyPuja mobile app interface for booking ritual services
Consumer · Two-sided marketplace

BookMyPuja

Visit product arrow_forward

Problem

Arranging traditional ritual services meant phone calls, word of mouth and personal referrals, with no reliable way to compare options, confirm a booking or coordinate the details in advance.

What we built

A two-sided marketplace with a separate application for each side: a customer app for discovering and booking services, and a business app for the providers who fulfil them. Both are published on Google Play and the App Store under Appseed Technologies.

Key capabilities

  • Service discovery and booking
  • Separate provider-side application
  • Booking lifecycle across both sides
  • Account and identity shared across apps

Technology

Flutter mobile applications · NestJS and Node.js backend · PostgreSQL · Deployed on AWS

DigiQ logo
SaaS · Queue management

DigiQ

Visit product arrow_forward

Problem

Physical queues cost customers time they resent spending, and give the business running them almost no visibility into where the delay actually comes from.

What we built

A queue management platform covering all three sides of the problem: the customer waiting, the staff serving, and the operator who needs to understand what happened afterwards.

Key capabilities

  • Digital queue join and status
  • Staff-side queue operations
  • Multi-location support
  • Operational reporting

Technology

React and TypeScript · NestJS and Node.js · PostgreSQL · Deployed on AWS

On client work

We're deliberately not filling this page with anonymised summaries or borrowed statistics. Where a client agrees to it, we'll publish a proper case study here — the problem, the constraints, the approach, the architecture, what was hard, and outcomes we can actually stand behind.

Until then, ask us on a call. We can talk through relevant work in more detail than a webpage allows.

Have something you want built?

Tell us the problem. We'll help work out what should be built and what it takes.

WhatsApp Us