Skip to main content
Anil MauryaSoftware · AI · Automation

About us

An engineering-led software practice

We build custom software, websites and AI automation for businesses across India — 46 services spanning websites, operational software, AI, automation, backend engineering and data. The approach is deliberately conservative: understand the problem properly, build the smallest thing that solves it, and make sure somebody else could maintain it.

Why this practice exists

Indian businesses are not short of software vendors. They are short of vendors who will tell them when software is not the answer, who scope a project so it can actually finish, and who leave behind something another developer can pick up.

Most operational software in small and medium businesses fails for the same handful of reasons: the scope was too large to deliver, nobody inside the business owned the project, the people expected to use it were never consulted, or the vendor built something that worked in a demo and became unmaintainable within a year. Very little of that is a technical problem.

So the way we work is shaped around those failure modes rather than around a technology stack. A written specification before development. A first phase narrow enough to be finished. Prototypes tested with the counter clerk or the field salesperson who will live with the result. Tests and documentation so the system outlives the engagement.

The same applies to AI, which is where expectations are currently furthest from reality. AI genuinely changes what is automatable — reading unstructured documents, answering questions from your own content, handling the mechanical middle of a workflow. It does not fix a process nobody has defined, and automating an undefined process simply produces errors faster. We measure before we promise.

What we will not claim about ourselves

Anything on this list would be easy to fabricate and hard for you to verify. So it is not here.

  • We do not publish a client count, a project count or a years-of-experience figure
  • We do not display client logos or testimonials without written permission
  • We have no awards or certifications to list, so we list none
  • We do not quote accuracy or performance figures we have not measured on your data
  • We do not claim deployments we have not made — every project is labelled demo or concept

How we think about building software

Six principles we actually apply

These are not values on a wall. Each one has a visible consequence in how a project runs.

The cheapest solution we can honestly recommend

A good number of enquiries are better served by software you can buy for a few thousand rupees a month than by anything we would build. We say so, because a client who trusts our judgement is worth more than a project we talked them into.

Narrow first, then expand

The single strongest predictor of a failed software project is how much was specified at the start. We deliberately scope a first phase small enough to be finished, deployed and actually used — then plan the next phase from what real usage teaches, which is never what the initial specification assumed.

Engineering practice, not just working output

Input validation at the boundary, automated tests over business rules, versioned database migrations, structured logging, documentation. None of this is visible in a demo. All of it decides whether the software is still maintainable in two years, and whether another developer can take it over.

You own everything

Source code, database and documentation are yours, running on infrastructure in your own accounts with billing in your name. No per-seat licence that reprices as you grow, and no situation where you need our permission to access your own data.

Honest about AI

AI is genuinely transformative for document processing, question answering over your own content and the mechanical parts of a defined workflow. It is not a general answer to disorganised operations. We measure accuracy on your real data before you commit, build human approval into anything consequential, and name the limitations on every page.

Designed for the person who has to use it

Counter staff, field salespeople and shop-floor supervisors are the real users of operational software. If a screen is slower than the phone call it replaces, it will be abandoned — so we prototype those screens with the people who will use them before building the rest.

Delivery process

What working with us actually looks like

Six phases, each with something you receive at the end of it. You can stop between phases.

  1. 1

    Understand the problem

    A conversation about what is actually costing you time or money. We ask about your current process, not your preferred technology. If an off-the-shelf product would serve you better, this is where we say so.

    You receive: A written summary of the problem, scope options and an indicative budget range

  2. 2

    Specify before building

    We map the process, agree what the first phase includes and excludes, and write it down. Scope disagreements are far cheaper to resolve in a document than in built software.

    You receive: A specification with process maps, screen list, data model outline and fixed phase-one scope

  3. 3

    Build in increments

    Development proceeds in short cycles with something reviewable at the end of each. You see progress continuously rather than receiving a finished system you have never used.

    You receive: A working staging environment, updated through the project for you to test

  4. 4

    Test with real data

    We test against your actual data and edge cases, not a tidy demo set. For AI features this includes measuring accuracy on real historical cases and reporting the number.

    You receive: Test results, measured accuracy where applicable, and a list of known limitations

  5. 5

    Deploy and train

    We deploy to infrastructure in your own accounts, train the people who will use it, and stay close during the first operating cycle when real usage surfaces what testing did not.

    You receive: Live system, trained staff, recorded training and operational runbook

  6. 6

    Support and improve

    Fixes, dependency and security updates, and changes as your process evolves — under a monthly arrangement, or handed over to your own team with documentation.

    You receive: Source code, documentation and either an agreed support plan or a clean handover

Technical capability

What we work with

Conventional, current, well-documented technology. Nothing here is chosen to be interesting — it is chosen because your next developer will already know it.

Frontend

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Progressive web apps

Backend

  • Python
  • FastAPI
  • Java
  • Spring Boot
  • Node.js
  • REST APIs

Data

  • PostgreSQL
  • MongoDB
  • Redis
  • pgvector
  • Supabase

AI

  • Claude API
  • Retrieval-augmented generation
  • Embeddings
  • Tool-using agents
  • OCR

Automation

  • n8n
  • WhatsApp Business API
  • Celery
  • Webhooks
  • Scheduled pipelines

Infrastructure

  • Cloudflare
  • AWS
  • DigitalOcean
  • Docker
  • Terraform
  • GitHub Actions

Commitments

What you can hold us to

  • We will tell you not to build it

    If a product you can buy solves your problem for less, we say so. We have advised businesses against custom development where it genuinely was not worth the cost, and we would rather lose a project than deliver one you regret.

  • Engineering practices, not just output

    Input validation, automated tests over business rules, versioned database migrations, structured logging and documentation. The things that decide whether software is still maintainable in two years.

  • You own everything

    Source code, database and documentation are yours, running on infrastructure in your own accounts. No per-seat licence that reprices as you grow, and no dependency on us for access to your own systems.

  • Honest about AI

    We measure accuracy on your real data before launch, build human approval into anything consequential, and name the limitations plainly. AI is genuinely useful for a specific set of problems — and not for every problem.

  • Phased, so you can stop

    Larger projects are delivered in phases with separate sign-off. You see working software early and decide what comes next from real usage, rather than committing the full budget up front.

  • Built for the people using it

    Counter staff, field salespeople and shop-floor supervisors are the real users of operational software. If the screen is slower than the phone call it replaces, it will not be used — so we design for that constraint first.

Let's find out whether we are a good fit

The first conversation costs nothing and often ends with us telling you to buy something off the shelf instead. That is a perfectly good outcome.