Web development
Business websites, web applications, client portals, internal systems, dashboards and workflow tools.
Technology division
Technology and application development
An in-house development team building web, desktop and mobile applications to client requirements — specified by people who understand how a business actually runs its finances.
What this looks like in practice
Accountants who write the software
The difference is not that we can code. It is that the person specifying the logic already knows what a wrong answer looks like.
A developer given “reconcile these two files” will match on invoice number and call it done. Someone who has chased input tax credit knows the invoice number is the least reliable field in the comparison, and that a rupee of rounding is not a mismatch worth chasing.
That is the whole argument for having both disciplines in one firm.
reconcile_2b.py
Python
1def reconcile(purchases, gstr2b, tolerance=1.00):
2 """Match the purchase register against what vendors actually filed."""
3 filed = {(r.gstin, r.invoice_no): r for r in gstr2b}
4 matched, missing, mismatched = [], [], []
5
6 for bill in purchases:
7 entry = filed.get((bill.gstin, bill.invoice_no))
8
9 if entry is None:
10 missing.append(bill) # vendor has not filed it
11 elif abs(entry.tax - bill.tax) > tolerance:
12 mismatched.append((bill, entry)) # value disagrees
13 else:
14 matched.append(bill)
15
16 return Reconciliation(matched, missing, mismatched)Where software fits
Four layers, and knowing which one your problem is in
- Your systemsBilling, point of sale, CRM or spreadsheets — wherever transactions actually originate.
- IntegrationAPIs and scheduled jobs move data across, with validation and an audit trail at each step.
- AccountingZoho Books or your existing ledger, kept current rather than rebuilt at year end.
- ReportingDashboards and MIS the owner can read without opening a ledger.
Built around the business, not around a demo
Most business software fails for unglamorous reasons. It was chosen from a feature list rather than a process map. It does one thing well and forces three workarounds. Or it holds the data but nobody can get a report out of it without exporting to a spreadsheet.
Our technology practice exists because we kept meeting that problem while doing accounting work. When a packaged product genuinely fits, we will tell you to buy it — configuring an existing tool is almost always cheaper than building one. When it does not fit, we build what does: a portal your clients log into, an internal system that enforces your approval rules, a dashboard that reads from your accounting data, or an integration that stops your team re-keying the same numbers twice.
Every engagement starts with written requirements. That document is what we build against and what you hold us to.
Typical builds
- Client and customer portals
- Internal business and operations systems
- Approval and workflow applications
- Management dashboards over live data
- Accounting and business utilities
- Field and workforce mobile applications
- Integrations between existing systems
- Modernisation of ageing internal software
Capabilities
What we build
Mobile development
Android, iOS and cross-platform applications for customers and for internal teams in the field.
Desktop development
Custom desktop software, business utilities and modernisation of legacy internal systems.
Custom business software
Requirements analysis, UI/UX, architecture, databases, APIs, testing, deployment and maintenance.
Method
How a build runs
- RequirementsWhat the software must do, who uses it, what it connects to, and what is explicitly out of scope.
- DesignScreens, data model and architecture, reviewed with you before development starts.
- Build & reviewDevelopment in reviewable increments, so you see working software early and can course-correct.
- Deploy & supportTesting, deployment, handover documentation, user training and an agreed maintenance arrangement.
Technology decisions — languages, frameworks, hosting and infrastructure — are chosen per project against your requirements, existing systems and long-term maintenance. We will set out the proposed stack and the reasoning in writing before development begins.
Questions
Technology questions
Why does a CA firm develop software?
Because so many finance problems are process problems. Once you have redesigned a client's invoicing or approval workflow, the next constraint is usually the software. Having a development team in-house means we can build the missing piece instead of recommending a compromise — and the people writing the finance logic are Chartered Accountants.
Can custom software be developed for a business?
Yes. We build web, desktop and mobile applications to client requirements — client portals, internal business systems, dashboards, workflow tools, and integrations between existing systems. The starting point is a written requirements document, not a demo.
Do you work with businesses that are not accounting clients?
Yes. Technology engagements are independent of our accounting services, though clients who use both get the benefit of a team that already understands their processes.
How do projects get priced?
After a requirements phase, so both sides know what is being built. Fixed-scope projects are quoted as a fixed fee with a payment schedule tied to milestones. Ongoing work and maintenance are quoted separately. We do not quote a build price before the requirement is written down.
Who owns the code?
Ownership and licensing are set out in the engagement agreement before work begins, along with source code handover, documentation and any ongoing maintenance arrangement.
Have a requirement no product seems to fit?
Describe the process and where it breaks. We will tell you whether it needs configuration of something you already own, an integration, or a build — and roughly what each would involve.