Software product engineering

Expert software product engineering services to buildscalable, market-ready digital products

We have spent two and a half years on one UK telecom billing platform, and the work continues. We are also building a multi-tenant EMR towards a pilot planned for mid-2027. This page is for companies whose software is the product and who need an engineering partner for years, not a single delivery.

What long product work has taught us

Six habits, each traced to a product we have built or still work on.

  • Money has to reconcile

    On the telecom billing platform, published invoices are locked and corrections become credit notes. Every movement posts to a ledger, and nightly balance checks run alongside Stripe, Direct Debit and accounting sync.

  • Tests are what make long projects safe

    That platform has an automated test suite in the thousands of checks, which runs on every change. It is what lets a live financial system keep changing.

  • Controls go in from the start

    The EMR is designed and built to HIPAA Security Rule requirements. Encryption, an append-only audit log, role-based access and MFA exist in the code now, rather than being retrofitted before the first sale.

  • Isolate outside systems

    On the advertising platform, each network has its own adapter and background queue, so an outage on one never blocks the others. Each customer's tokens are encrypted and held per tenant.

  • Products outlive their first technology

    A Qatar manpower company's system has gone from C#/.NET to Electron and is now being scoped for the web, with us throughout. Decisions have to allow for the next generation.

  • Getting customers is part of the job

    On Shabash we run SEO, a programmatic salon directory and distribution as well as the software, because a product no one can find has not finished its job.

How we work on a product

The rhythm matters more than any single phase, because the work does not end at launch.

  1. Learn the domain

    CDR rating, IRDAI reporting and rental contracts all have rules a developer will not guess. We start by learning how the business really runs and writing that down.

  2. Agree the roadmap, then the next slice

    We keep sight of where the product is going, but commit in small pieces that can each be demonstrated, reviewed and shipped.

  3. Ship with tests and weekly demos on most projects

    Demos are weekly on most projects, and some projects have daily check-ins. Documentation is written for the next developer, and automated tests grow with the product so that older features stay protected.

  4. Keep improving in production

    Production feedback sets the next round of work, whether that is a new integration, a migration of opening balances or a change to a tax rule.

What a product engagement looks like

Sizes and durations from our own projects.

The advertising platform was about a year with six people. The garage-booking SaaS was about a year across API, web and mobile. The telecom billing platform is a long-term engineering partnership that is still running.

New products often start smaller; see MVP development. If you already have a technical lead and only need capacity, hire developers instead. Time-based work starts from $20/h in USD, invoiced in USD, GBP, EUR or INR. We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment.

Products we have engineered

Most of our work is delivered under NDA, so many projects cannot be named.

Questions about product engineering

The differences that matter before you pick a model.

How is this different from hiring developers?
With hired developers, you direct the work day to day. With product engineering, we take responsibility for delivery and technical decisions alongside you. The Dubai team is an example of the first model, and the telecom billing platform of the second.
Which technologies do you build products on?
Most often a Laravel back end with a Next.js front end and React Native for mobile. We have also shipped a React front end, Node.js, C#/.NET and Electron where the product called for them.
Can you take over a product another team built?
Yes, after a code review. Our cabinet-manufacturer project began with an audit of a legacy codebase and schema before any rebuild, and we would start a take-over the same way.

Tell us where your product is now

An idea, a live system or a rebuild: send what you have and where you want it in a year. We will tell you how we would staff it.

We reply within one business day (IST).