Custom software development
Most custom software fails in the same place. Six months in, the thing everyone agreed was simple turns out to encode a rule nobody ever wrote down. We start by finding those rules, because they decide the architecture and nothing else does.
The problem we usually get called about
Usually it is the second attempt. There is a system that half works, a vendor who has stopped answering, and a set of business rules that live in one person’s head and in a spreadsheet they maintain at night. The brief you are handed describes the software. The actual problem is the spreadsheet.
We do not quote against a feature list for that reason. A feature list written before anyone has found the spreadsheet is a fiction with a number attached to it, and both sides discover this at the same time — around month four, when the number stops being true.
The other common version: the system works, but only because two people know which fields to leave blank. That is not a training problem. It is a modelling problem that has been absorbed by staff, and it gets more expensive every month it is left alone.
What we actually build
We write the parts that are specific to your business and buy the parts that aren’t. Authentication, payments, search infrastructure, file storage, admin scaffolding — these are solved problems, and building them again spends your budget on something a competitor rents for forty dollars a month.
What we do build is the model: the entities, the states they move between, and the rules that govern the transitions. On a marketplace that is the routing and settlement logic. On an ERP it is the approval chain. On a logistics platform it is what counts as delivered, and who is allowed to say so. Get that wrong and no amount of front-end work rescues it; get it right and everything downstream becomes legible.
TypeScript end to end, PostgreSQL unless there is a specific reason not to, and deliberately boring infrastructure. We are not going to put your pre-launch product on Kubernetes.
How we keep the estimate honest
Discovery is paid and separate. At the end of it you have a written model of your domain, a build order, and a number — and you own all three whether or not you continue with us. That is the point: an estimate you cannot take to another firm is not an estimate, it is a lock-in.
After that we build in slices. Each slice is a working, deployed, usable piece of the system rather than a layer of it. You are never looking at a database schema and taking our word for what it will become. If the budget stops, you stop with something that runs.
What this actually covers
Domain modelling
Entities, states and transitions written down before any code exists. This is the deliverable that survives us.
Marketplace platforms
Multi-sided systems with routing, settlement and dispute flows — the parts that are never in the brief.
SaaS products
Multi-tenancy, plan gating, usage metering and the billing edge cases that decide your churn rate.
System integration
Making your new system talk to Tally, an ERP, a payment gateway and a courier API without a nightly CSV.
Rebuilds and rescues
Taking over a codebase that a previous team left. Archaeology first, then a strangler migration, never a rewrite from zero.
Data migration
Getting fifteen years of records out of the old system with the exceptions intact, which is the part that takes the time.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Discovery — paid, two to three weeks
We sit with the people who do the work, not only the people who commissioned it. Output is a written model of the domain, a build order and a real number, yours to keep whether or not you continue with us.
Shape
Screens and data model together, because one always breaks the other. Design system first, screens second — building screens first produces forty-four slightly different buttons.
Build in slices
Each slice is a working, deployed, usable piece of the system rather than a layer of it. Two-week cadence, demoed against real data, so you are never accepting a promise.
Harden
Load testing against realistic volumes, an access-control review, and the failure paths — what the system does when the payment gateway is down, not only when it is up.
Handover
Documentation, a recorded walkthrough, and a support window at a defined rate. If you want to take it in-house, we help you hire for it. That is a normal ending, not a failure.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- A written domain model — entities, states, transitions and the rules behind them
- Source code in your repository, under your organisation, from the first commit
- Infrastructure described in code, so the environment can be rebuilt without us
- A deployed staging environment you can use before anything reaches production
- API documentation generated from the code, not maintained separately
- A handover session recorded, plus a runbook for the things that break at 2am
Typically built with
- TypeScript
- Node.js
- React
- Next.js
- PostgreSQL
- Redis
- Docker
- AWS
- Terraform
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
Custom Software, answered
The things people ask on the first call, written down so you do not have to.
How much does custom software cost?
The honest answer is that nobody can tell you before discovery, and anyone who quotes a firm number from a one-page brief is quoting a number they intend to revise. What we can tell you is the shape: discovery is a fixed fee in the low five figures (INR) and takes two to three weeks. It ends with a real number for the build, based on a model of your domain rather than a guess about it. If that number is wrong for you, you have lost the discovery fee and gained a specification you can take anywhere.
How long does a custom software project take?
A focused first release is usually three to six months from the end of discovery. Anything quoted at six weeks is either much smaller than it sounds or is going to arrive without the parts that make it usable — permissions, audit trails, error handling, data import. We would rather cut scope than compress a schedule, because a compressed schedule is paid back later at interest.
Who owns the code and the intellectual property?
You do, from the first commit. Work is done in your repository under your organisation account, not in ours. There is no escrow arrangement, no licence-back clause and no per-seat fee on something you paid to have built. If you stop working with us tomorrow, everything keeps running and any competent team can pick it up.
Can you take over software another company built?
Frequently, and it is a normal way for us to start. The first two weeks are archaeology rather than development: reading the code, mapping what it actually does against what everyone believes it does, and finding out which parts are load-bearing. We give you a written assessment before we suggest any changes, and sometimes that assessment says the right move is a targeted rebuild of one area rather than us taking on the whole thing.
Do you work with clients outside India?
Yes — we work with clients in the United States, the United Kingdom and Australia alongside Indian clients. Our working hours overlap comfortably with UK mornings and Australian afternoons; US calls are scheduled early or late by arrangement. Async written updates are the default rather than a concession, which is what makes the time difference workable.
What happens if the requirements change mid-project?
They will, and the build-in-slices model exists to absorb that. Because each slice is a working piece of the system rather than a layer of it, changing direction costs you the current slice rather than the whole plan. What we push back on is a change that contradicts the domain model, because that is the expensive kind — we will show you what it costs before you decide, rather than absorbing it quietly and running late.
What usually comes with this
- BuildWeb Application DevelopmentDashboards, portals and internal tools that hold up under real data volumes — not a prototype that falls over at ten thousand rows.Read more
- RunERP SolutionsImplementation, plus the custom modules the implementation always turns out to need in month four.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
- GrowUI/UX DesignProduct design and design systems. Usually the first thing that turns out to be wrong, and the cheapest thing to fix.Read more
Thinking about custom software?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.