Custom software goes wrong in three familiar ways: scoped from a requirements document, built at a distance, priced before anyone understood the work. Each stage below exists to prevent one of them.
It starts with a discovery call — video, not a fixed hour, as long as it takes. Usually that's the operations manager, or whoever owns the problem. We learn how the operation runs and identify the modules it needs.
Shape and price
02You see the shape and the price
The call becomes two documents. The proposal carries the estimate — most work lands between ₹15L and ₹20L — along with the timeline and payment terms; the approach document sets out what gets built, what it connects to, and which problems it solves.
What gets built
Quotes · Contracts · Payments · Activity
Connections
Tally · Documents
Sign
03You sign, and the real work begins
Contract signed, first milestone paid. Nothing starts before this — no build on a handshake.
Interviews
04We talk to everyone who'll use it
Two to three weeks of individual interviews with team leads and their teams, plus written questionnaires. The same person who took your first call runs every interview and stays with the build. Remote by default, on-site where that's easier.
Operations managerDiscovery call
Management, data and IT
What report do you personally look at to know how the business is doing, and who prepares it?
Follow-up: how long does preparing it take, and how much of that is copying from one place to another?
When two people give you different numbers for the same thing, how do you decide which is right?
Whoever owns the problemDiscovery call
The five that reveal hidden losses
Which charges beyond the monthly amount are billable in theory, and roughly what proportion of them actually get billed?
Between the quote the customer agreed and the final supplier invoice, who checks the two still match — and what happens if they do not?
How long after a delivery does the first invoice go out, and who would notice if it never did?
Team leadsIndividual interviews
Pricing and quotation
Someone has to turn a customer requirement into a number. Who is that person, and what do they open to do it — a spreadsheet, a template, something someone built?
Where does the vehicle price in that calculation come from, and how old is it by the time it is used?
Which numbers in a quote are fixed by policy, and which ones can a person change on their own judgement?
Their teamsIndividual interviews
Sales and enquiry
An enquiry arrives on a Tuesday morning. Walk me through the next four hours — who touches it, in what order, and where does it get written down?
How does an enquiry reach you at all — reference, website, someone's personal contact, an existing customer's colleague? Which of those closes best?
When someone calls asking about leasing, how do you find out whether they are even allowed to lease a car under their employer's policy?
Written questionnaireIn writing
Contracts and documentation
How many different agreement templates exist, and what decides which one a deal gets?
Who fills them in, and what do they copy the details from?
Follow-up: if the same customer detail appears in three documents, is it typed three times?
Two to three weeks · Remote by default · On-site where that's easier
Scope lock
05You approve exactly what gets built
The interview notes become the detailed scope, and you sign it off before anything is built. The final fixed price is set here, in writing — and it doesn't move unless you add something outside that scope.
Weekly reviews
06You see it every week
The build runs against weekly reviews: what's built, how it works, what's coming next. Your feedback lands while modules are still open — not after everything is welded shut.
Reviewed
What's built · How it works · What's coming next
Shape what's left
07You shape what's left
At the halfway review, half the system is working. How the remaining modules work — screens, fields, flows, approvals, reports — is still yours to shape. Which modules exist is not: that was fixed in the scope.
Handover
08We come to you and train your teams
Handover happens at your office. The system goes onto your machines, every team is trained in person on their part of it, and you get written documentation of the full system.
Real use
09You run on it for 45 days, and we make the changes real use reveals
For 45 days after go-live, we're available for changes.
Our demo system · Sample data · Not the client's platform
Why the 45 days exist
Ninety percent of a system can be built from what people tell you. The last ten percent only shows up on a real Tuesday, when someone tries to do their actual job at 4pm.
That's why the 45 days exist — not because we ran out of time, but because that ten percent cannot be found any other way.
For 45 days after go-live, we're available for changes. Your team uses the system on real work, tells us what doesn't fit, and we adjust it.
Bugs are free forever, separately and always — if something doesn't do what we agreed it would, we fix it, no time limit.
We keep it running
10We keep it running
The annual maintenance contract begins — hosting, updates, staff changes, and someone to call. Every system we hand over runs under one.
If your operation is common, there's a faster way.
Finished systems cover operations that run the way most in their industry do — live in under a week, at a fraction of a custom build. See the catalogue.