Services · 02
Business systemsOne system for customers, orders and the work in between
The CRM, the ERP and the small pieces nothing off the shelf sells, connected to the tools you already run so the retyping stops.
Connect what you already run. Build only what nothing sells.
Most businesses we meet already own every tool they need: a billing system, a shop on Shopify or Amazon, WhatsApp for orders, a spreadsheet for stock, Tally for the accounts. The problem is that none of them talk to each other. Somebody types the same order three times, the stock sheet is wrong by lunchtime, and the owner finds out what happened yesterday from a phone call.
This is the work of connecting what you already run, and building only the small pieces that nothing off the shelf does: the customer record that holds every enquiry, the order that carries its own history, the approval that used to be a phone call. The measures are agreed before we start: how many things get retyped in a day, how long the evening reconciliation takes, how often a customer is promised stock that is already gone. Then we make those numbers move, and show you the count.
- Team
- The named owners, for the whole engagement
- Runs in
- Your own accounts, from day one
- Pricing
- Fixed price, billed by milestone; a fixed itemised quote follows the first call
- Enquiries landing in four places and followed up from memory
- Orders arriving from more places than the team can retype
- Software the business has outgrown, or never fitted it
- Working software your team is trained on while we are in the room
- One record per customer and per order, from first enquiry to closed
- A written decision log and tests the next engineer can pick up
- A weekly note in plain words: built, decided, why
Four gates. You accept each one before the next starts.
The same four as every engagement, as they look for this work.
Diagnose
We sit where the retyping happens: the order desk, the billing counter, the WhatsApp group. Every hand-off between two systems is written down, with who does it and how often. The findings document lists them in order of pain, and you keep it whoever builds.
Prove
The first connection goes live on real orders: usually the shop into the billing system, or WhatsApp orders into one queue. The count we agreed is measured before and after, on your data, and the running cost of the connection is written down.
Build
The rest of the connections, fortnightly, in your own accounts. The owner’s page appears early and grows: sold, shipped, returned, running low, money due. Every decision is written in a note your team can read later.
Hand over
Your team runs it for two weeks while we are still on call. A guide for each connection, a who-to-call list, and a written review: what moved, what did not, and what the next piece would be.
Every lead in one pipeline, from portal enquiry to booking.
A residential developer with nine projects and sixty sales staff. Leads from portals, brokers and walk-ins sat in separate sheets, followed up from memory.
Leads with a logged first response inside a day
of every lead arriving from a portal, a broker or a walk-in

- Leads that went cold with no follow-up loggedan enquiry that reached nobody and was never worked again
- Site visit to booking paperworkfrom the visit a buyer decided on to a completed booking record
What owners ask before they call.
Can Tally, Shopify and WhatsApp be connected without retyping?
Yes, and that is most of the work. Each tool keeps its job: Shopify takes the order, Tally keeps the books, WhatsApp is where the customer talks. What changes is that an order placed in one appears in the others without anyone typing it again, and the stock count moves with it. Where a tool has no proper door (a supplier who only sends PDF invoices, a marketplace that only exports a sheet), a small reading step does the typing instead. The first thing we agree is the list of things that must never be retyped, and the count of how many still are, measured before and after.
Do we throw away the ERP we already paid for?
Almost never. Replacing software your team already knows is a last resort: it costs twice, once in money and once in the months your people spend relearning their own jobs. The usual answer is that the system you bought does two-thirds of the job well and is being worked around for the other third, so we connect it properly and build only that third. We will say plainly when a system genuinely cannot be carried forward, and what the move would involve, but we will not sell you a replacement to make our own work simpler.
Our leads come from portals, brokers and walk-ins. Can one system hold them all?
Yes, and it is the usual first piece. Every source lands in one pipeline with the source recorded, each lead is assigned to a named person the moment it arrives, and follow-ups are reminded rather than remembered. Nothing depends on which salesperson checks which inbox. The residential developer had leads from portals, brokers and walk-ins in separate sheets and sixty salespeople working from memory; one pipeline from enquiry to booking was the whole change.
What does the owner’s one screen actually show?
The day, in the order you would ask about it: what was sold, what was shipped, what came back, what is running low, what money is due in and out, and what needs a decision from you. Every number on it comes from the systems your team already uses; nobody types into the page, so it cannot drift from reality the way a hand-updated sheet does. It opens on a phone, because that is where owners look at nine in the evening.
Will our staff have to learn new software?
Mostly no, and where yes, it is designed in rather than hoped for. Your billing clerk keeps billing in the tool she knows; what disappears is the second and third place she had to type the same thing. Where a new screen is unavoidable, the system suggests and a person approves, so nobody is fought by their own tools. Training happens in your workplace while we are still in the room, one person at a time, and adoption is one of the measures we agree up front rather than an afterthought.
What happens when a connected tool changes or breaks?
Every connection is watched, and a failure goes to a named person rather than into silence: the order that did not reach billing shows up in a queue with a reason, not as a missing invoice found at month end. When a tool changes its door, as Shopify and the marketplaces do a few times a year, the connection is built so that one piece changes rather than the whole thing. The handover includes the guide for each connection, a founder replies within one working day, and a monthly care plan is available, never required.
For your technical adviser
Domain-modelled applications and the integration layer around them: typed, tested, documented. Fortnightly increments and an architecture decision log your team owns after handover.
- Working software in fortnightly increments
- Architecture decision log in your repository
- Integration contracts with retries, dead letters and alerting
- Test suite and CI pipeline that your team owns
Stack TypeScript · Python · PostgreSQL · REST and webhooks · Tally · Zoho · Shopify
Replace the software you run, or connect it?
The three tests a system has to fail before replacing it is the honest answer.
Write a paragraph. A founder replies within one working day.
A 30-minute call with both founders follows. No deck and no proposal template, just a first read of whether we are the right shape for the problem.
Or by phone or WhatsApp: +91 94330 54299 · WhatsApp (opens in new tab)