Straight answers, no sales talk

Three connected things. I implement ERP and automation systems for growing businesses; I integrate the tools a business already runs so they behave as one system; and I train business owners so the capability stays in-house after I leave. Where it makes sense, I also build and operate aggregation structures that give groups of small businesses shared leverage.

Mostly businesses between roughly 10 and 500 people — large enough that spreadsheets and WhatsApp have genuinely broken down, small enough that the owner is still close to operations. Below that, the honest answer is usually a cheaper off-the-shelf tool, and I will tell you so.

With a free 30-minute call to understand the problem, followed by a paid discovery sprint if it looks like a fit. Discovery produces a written blueprint, a platform recommendation and an honest budget — and it is deliberately structured so you can take that document to any implementer, including one who is not me.

Both. Discovery and go-live benefit enormously from being physically present in the operation. Build, review and advisory work runs well remotely. Most engagements mix the two, and I say up front which phases need me in the building.

For an SME covering sales, purchase, inventory and accounts, the realistic total — licences, implementation, migration and training — usually lands in the low-to-mid six figures in rupees for open-source platforms, and materially higher for proprietary suites with per-user licensing. Anyone quoting a firm number before discovery is guessing. Discovery exists precisely to replace that guess with a figure you can budget against.

Discovery is a fixed fee. Implementation is milestone-based against the blueprint. Training and advisory are either per-session or retained monthly. I do not bill open-ended hourly time for delivery work — that arrangement rewards the wrong things.

Typically platform licences or hosting, a support arrangement, and a budget for the phase-two work you will inevitably want once people are using the system. I model all three during discovery so the year-two number is not a surprise.

Primarily ERPNext and Odoo, plus Zoho for sales-led businesses and custom builds where a business's core process genuinely has no packaged equivalent. I am deliberately not a reseller for any of them, which is what lets the selection scorecard be honest.

Usually yes, and often that is the right call. Replacing a working ERP is expensive and disruptive. A large share of my projects add an integration, automation or reporting layer around an existing system rather than replacing it.

Completely. Repositories sit under your account, infrastructure runs on your cloud accounts, and all credentials are yours. Handover includes documentation written for a developer who has never spoken to me. You are never locked in.

Concrete examples from documented projects: a month-end close reduced from 11 days to 2, marketplace overselling cut from 4% to 0.1%, 1,900 hours a year of manual work removed at a manufacturer, and 9–14% better procurement pricing for a 60-store retail network. The case studies set out the method behind each.

Over the last several years I have run owner intensives, team system training and ongoing advisory for more than a hundred business owners across manufacturing, distribution, retail, D2C and services. Some were full implementation clients; many were owners who needed the literacy to make a decision well and then execute it with their own team.

Discovery is deliberately a small, self-contained commitment that produces a document useful to you regardless of who implements it. Implementation runs in milestones with review gates, so you can stop at a gate rather than discovering a failure at the end. I would rather lose a project at gate two than deliver a system nobody uses.

That is the real risk, not the software. Adoption is designed in: role-based training on your own data, written guides at each desk, named internal champions, and a firm date when the old spreadsheet stops being an option. Leaving the old path open is the most common reason ERP projects quietly fail.

It gets cleaned before it gets moved. Duplicate items, inconsistent customer records and opening balances that do not reconcile are fixed first, then migrated with a verification report your accountant can sign off. Migrating a mess just makes the mess faster to query.

Yes, and I usually recommend it. A phased rollout — sales and inventory first, then purchase, then manufacturing — means you get value from the first module while the last is still being built, and each phase teaches you something that improves the next.

A focused SME rollout covering sales, purchase, inventory and accounts typically runs 8–14 weeks from discovery to go-live. Manufacturing, multi-location or multi-entity setups usually run 4–7 months. I phase the work so you get value from the first module before the last one ships.

There is no universal best. ERPNext suits businesses that want low licence cost and deep customisation. Odoo suits teams that want a broad app ecosystem and polished UX. Zoho suits sales-led businesses already in that ecosystem. The decision should follow your process complexity, internal IT capability and five-year plan — which is exactly what the selection scorecard measures.

Three reasons, in order: processes were never documented, so the software encoded chaos; no one owned adoption, so staff kept their spreadsheets; and the project was treated as an IT purchase rather than an operating change. Every engagement I run is designed against those three failure modes.

Yes — a meaningful share of my work is recovery. I start with an independent audit of configuration, data integrity and adoption, then give you a straight answer on whether to fix, re-implement or migrate, with the cost of each path.

For the top-ranked items on the list, usually within a few months. Reporting and reconciliation automations tend to pay back fastest because they are cheap to build and replace hours that recur every single week.

Then the automation should change too, which is why I build workflows your team can adjust rather than sealed custom code. Anything genuinely likely to change gets built to be edited, and I show your people how.

Often not. A great deal of automation is connecting tools you already pay for so information moves once. New software gets recommended when there is a genuine gap, not as a default.

By hours saved per rupee spent. I time each repetitive task, multiply by frequency and loaded staff cost, then weigh that against build effort. The ranked list usually surprises owners — the most annoying task is rarely the most expensive one.

In practice, almost never. In the businesses I work with, automation absorbs the growth that would otherwise have required three more hires, and moves existing staff onto work that needs judgement. That is also why adoption goes smoothly — nobody is automating themselves out of a job.

No. Automation often delivers faster payback than a full ERP, and a well-run automation project produces exactly the process documentation an ERP rollout needs later. For many businesses it is the right first step.

Usually within the first month of automated checking, because the validations run against historical data as well as new transactions. Businesses with manual pricing or scheme handling almost always surface something in that first pass.

No — everything runs alongside the existing process first, so the team keeps working exactly as they do while the automated results are compared against theirs. Only once the numbers agree consistently does anything switch over.

That is common and it is a reasonable starting point. Getting current is part of the work: the reconciliation engine is run over the backlog first, which both catches up the books and demonstrates the pattern of what has been slipping.

It varies hugely by industry, but the pattern is consistent: businesses with manual pricing, scheme or settlement handling almost always find something in the first month of automated checking. The point is not the percentage — it is that these losses are invisible without a system looking for them, and entirely recoverable when caught early.

Usually not. Most of this work sits alongside your existing accounting system, feeding it clean entries and checking its output. Replacing accounting software is disruptive and rarely the actual fix.

Your auditor samples, once a year, after the fact. This checks every transaction, every day, while there is still time to recover the money. The two are complements, not substitutes — and clean automated controls make the audit itself much cheaper.

It will, occasionally — so nothing consequential happens without a check. Low-confidence results route to a person, actions that touch money or stock need approval, and everything is logged. AI is used where a mistake is cheap and catchable, not where it is expensive.

That is the only sensible way. One workflow, built end to end, measured against how the task runs today. If it does not clearly beat the current process, we stop — and you have spent very little finding that out.

Almost never. Existing models plus your own data and good engineering around them covers nearly every business use case. Training a custom model is expensive, slow, and rarely the actual constraint.

For some tasks, yes — reading documents, drafting, classifying, answering questions from your own data. For others, a plain rule-based workflow is more reliable and far cheaper. The skill is knowing which is which, and building guardrails and human checkpoints wherever a mistake would be costly.

Only if you choose that, and only where it is appropriate. Where data sensitivity requires it, workflows can be built so that confidential data never leaves your systems. We decide this deliberately, before anything is built.

For connecting tools and automating workflows, n8n is faster to build, easier for your team to understand, and much easier to change later. I write custom code where the logic genuinely needs it — but reaching for code first usually just makes the automation harder to maintain.

A BI tool draws charts from whatever you feed it. If the underlying data is inconsistent, you get beautiful charts that disagree with each other. This work is the layer underneath — making sure the numbers arriving at the tool are correct, consistent and defined once.

You hear about it immediately rather than discovering it in a report three weeks later. Every job logs what it did, alerts on failure, and where possible retries safely. Silent failure is the thing these pipelines are specifically designed to prevent.

Yes, and usually that is the right answer. Most businesses do not need a new platform — they need their existing database modelled properly, with scheduled jobs and validation around it.

Almost always because the same word means different things in different places — one team counts an order when it is placed, another when it is dispatched. The fix is not a better dashboard, it is agreeing the definitions once and building every report from one modelled source.

Both, and I pick per job rather than by habit. R is excellent for analysis, statistics and reporting pipelines; Python suits general engineering, APIs and anything heading towards machine learning. Plenty of my production pipelines are R talking to PostgreSQL on a schedule.

Probably not yet. A well-modelled schema in the database you already run, plus scheduled jobs and proper validation, covers most businesses for a long time. I would rather make your existing database trustworthy than sell you a platform you do not need.

Usually yes. Scheduled file exchange, direct database reads, or in the worst case automating the interface itself will all beat manual re-entry. It is less elegant and needs more careful monitoring, but in twelve years I have found genuinely un-integrable systems perhaps twice.

A straightforward connection between two systems with decent APIs is usually a few weeks including testing. Complexity comes from edge cases — partial failures, duplicates, systems that disagree about what already happened — which is exactly where careless integrations break.

Connectors are built to fail loudly rather than silently, so a breaking change surfaces immediately through monitoring. The runbook handed over tells whoever is on duty what to check, and the design isolates each connector so one vendor's change cannot take down everything.

You do. It runs on your infrastructure with your credentials, and handover includes documentation written for a developer who has never spoken to me. Ongoing support is available but never required.

Rarely. Most modern platforms expose an API, a webhook, a scheduled export or at minimum a database view. Where none exists, a middleware layer with file or RPA-based exchange still beats manual re-entry. In twelve years I have found genuinely un-integrable systems perhaps twice.

It queues and retries rather than losing data, monitoring alerts on the failure, and the runbook tells whoever is on duty what to check. Designing for failure is the difference between an integration and a script.

By breaking it into pieces small enough to be estimated honestly, and being explicit about which parts carry genuine uncertainty. Anything unknown gets a time-boxed spike to reduce the unknown before it is priced, rather than a padded guess that helps neither of us.

You see working software every two weeks on a staging environment you can click through yourself. Progress is measured by what actually runs, not by a percentage on a status report.

Expected, and handled through the milestone structure — changes get scoped, priced and slotted rather than absorbed silently or refused. What I avoid is the pattern where scope grows quietly until nobody can say what was agreed.

A support arrangement sized to how critical the system is, from occasional help through to active monitoring and maintenance. Or nothing at all, if your team is ready to take it on — the handover is designed to make that a real option.

Yes, entirely. Code lives in your repository under your account, infrastructure runs on your cloud accounts, and every credential is yours. Handover includes documentation written for a developer who has never met me.

Far less than most owners expect. A typical business web application runs on managed serverless hosting and a managed Postgres database for a modest monthly figure at low traffic, scaling with use. I state projected infrastructure cost as part of the architecture decision, before you commit.

For a substantial ERP, typically several weeks of focused work on the database and the live system, plus interviews with the people who use it daily. It is slower than everyone hopes and it is the foundation everything else depends on.

Yes, and you should. The new system is built module by module alongside the old one, with data flowing between them during the transition. Nobody should be betting the business on a single switch-over weekend.

That is the usual situation, and it does not block the work. The database schema, the running behaviour and the daily users collectively hold the knowledge. Recovering it into a written blueprint is precisely the deliverable.

It is the normal situation, and it is exactly the work. The database, the screens and the people who use it every day hold the answers between them. Recovering that into a written blueprint is usually the single most valuable part of the project — you own your own business logic again, whatever you decide to do next.

It can be, if it is done as a clean-room rebuild: copy the requirements — what each module does and what data it needs — and never the code, schema names, screens or wording. That distinction matters, so I work to it strictly and recommend you confirm the position with your own counsel before shipping.

Yes, and you should. The rebuild runs module by module alongside the existing system, with data flowing between them during the transition. Nobody has to bet the business on one switch-over weekend.

Enough to observe: logs, a read replica or database access, and ideally a staging environment where the failure can be reproduced. Read access is usually plenty — the goal is to understand the system, not to change it until the cause is proven.

You get everything I found and a written assessment at the end of the time-box, including what has been ruled out. That has real value on its own, because it stops your team re-searching the same ground. And you have not signed an open-ended engagement.

Yes, though the fix is usually the small part. Once the cause is proven the change is often a few lines. What matters more is adding the test or alert that catches it next time, which is included.

Usually because a fresh pair of eyes has no attachment to the theory everyone has been chasing. Long-running bugs tend to survive because an early assumption was wrong and never revisited. I start by questioning the assumptions, not by reading the code everyone has already read ten times.

Yes — that is the normal case, and it is a lot like reverse engineering. The database, the logs and the running system will tell you what is happening if you read them carefully enough. Access and a reproducible example matter far more than prior familiarity.

A fixed-fee time-boxed investigation. You get everything I have found and a written assessment at the end of the box, whether or not the cause was pinned down. That caps your risk and keeps me honest about progress.

Better than most people expect, but it has to be tested in your actual room rather than trusted from published figures. Microphone choice and placement usually matter more than which model is used, which is why prototyping happens on site.

Depends on how it is built, and that is a design decision made up front. Processing can run entirely on local hardware so the system keeps working offline, or on a central server if that suits better. Either way, connectivity failure should degrade the system, not stop it.

It is practical where hands are genuinely busy and the vocabulary is bounded — a warehouse, a counter, a workshop. It is a poor fit for open-ended conversation or noisy environments with complex commands. I will tell you which situation you are in before you spend anything.

Three reasons: cost stops scaling with usage, your audio never leaves your network, and the system keeps working when the internet does not. Open-source models are now good enough that the trade-off usually favours self-hosting — though for low volumes a cloud API is simpler, and I will say so.

Less than people expect. A Raspberry Pi with a decent microphone works well as a listening endpoint, with the heavier models running on one central server or a modest cloud VM. Total hardware cost per location is genuinely small.

Reasonably well, and it is exactly the thing to test before committing. I always prototype with your actual staff in your actual environment, because published accuracy figures and real shop-floor accuracy are very different numbers.

Often more so, not less. An IT person handles the technology; the gap is usually the owner's ability to judge investments and the team's ability to use systems fully. Training both sides makes your existing IT person considerably more effective, because the requests they receive start making sense.

Owner sessions work well as a short series of focused meetings over a few weeks. Team system training is usually a concentrated first round in person, then shorter reinforcement sessions once people have hit real problems in daily use.

That is the normal case and it is not a barrier. None of this requires reading code. It requires understanding how your own processes map onto a system, how to judge a proposal, and how to read your own numbers — all learnable by anyone who knows the business.

Yes. Written procedures for each role, recorded walkthroughs, and the scorecards and checklists used in the sessions. They stay with you and become the induction material for your next hire.

Yes, and it is a frequent request. Working out what an existing system actually does and teaching your team to use it fully is closely related to the reverse-engineering work — usually people are using a fraction of what they already paid for.

Both, in separate tracks. Owners need decision literacy: budgeting, vendor evaluation, reading the numbers. Staff need operational depth in the system they use daily. Mixing the two in one room serves neither group well.

Both work. Owner intensives run well over video in short focused sessions. Team system training lands better in person for the first round, then continues online for reinforcement.

Settled in writing before anything is built, because it is the question that surfaces at the worst possible moment otherwise. Depending on the structure it may be jointly owned by the members, held by a separate entity, or licensed to the group — but it is never left ambiguous.

Fewer than people assume for a pilot — a committed dozen is enough to prove whether the economics are real. Scale matters for negotiating power later, but proving the model with a small group first is what stops expensive mistakes.

Settlement disputes, almost always — not pricing. Somebody pays late, somebody feels short-changed, and with no agreed process the group fractures. That is why governance and the dispute process get written down before onboarding rather than after the first argument.

No, and building it first is a common error. Run the model manually with a small group until it demonstrably works. The manual pilot reveals what the real constraint is, and that shapes what the platform should actually do.

An aggregator brings independent businesses together so they benefit from scale they could not reach alone — shared procurement, shared technology, shared distribution or a shared brand. My role is designing that structure, proving its economics, building the platform that runs it, and setting up governance so it holds together as it grows.

It depends on the structure. Some engagements are straightforward consulting; others are longer partnerships with shared upside where I am operationally involved. We settle that explicitly before work starts.