Custom Software
When do you actually need custom software?
When the hard part of the problem is the system itself: the data model, the business logic, the calculations and rules no packaged product gets right. Not a nicer screen over an existing tool, but the engine underneath. We build that engine, choosing the stack to fit the problem rather than the other way round.
Most software you can buy. A CRM, an accounting package, an ERP. The reason to build instead is narrow and worth being honest about: you build when the thing that makes your business yours is a process no product models, and bending a packaged tool to fit it costs more over time than building the right thing once.
We spend the first conversation making sure that is actually true, because sometimes it is not.
The engine, not the interface
-
Calculation and pricing engines
The logic that works out what something costs, what someone earns, what gets charged. Rules with edge cases, tiers, and exceptions that a spreadsheet used to hold and can no longer be trusted with.
-
Payout and ledger systems
Money moving with rules attached: balances, disbursements, who gets paid what and when. The kind of logic where a rounding error is not a cosmetic bug.
-
Reconciliation and processing systems
The software that takes data from several places and works out the truth: what matches, what does not, what needs a human. Usually invisible, always the thing that breaks quietly if it is built badly.
-
Bespoke workflow systems
A process specific enough to your business that no workflow tool models it, built as its own system with the rules encoded rather than configured around.
Where this work needs a screen people log into, that front end is web app development; where it is custom engineering inside Odoo, that is Odoo development. This page is about the system underneath, where the logic is the hard part.
Custom software, or one of its neighbours?
“Custom software” is broad enough to mean nothing, so here is the specific line. It comes down to where the hard part sits, and whether the thing lives inside a platform or stands on its own.
- The system, logic, and data model, on its own stack
- Custom Software (this page)
- Custom modules or features inside Odoo
- Odoo development
- A screen people log into and work in
- Web app development
- An app installed from a store
- Mobile app development
- Rolling out and configuring a packaged ERP
- Odoo implementation
The line we hold most carefully is the one with Odoo development. If the thing you need is a custom module on a system already running Odoo, that is Odoo development and it belongs there. Custom software is for when the answer is not an Odoo module at all, but its own system with its own stack. We will tell you which one you are actually asking for, even when it is the cheaper one.
Systems we built
The custom software worth pointing at is usually the part of a larger engagement that had no off-the-shelf answer.
The Endurance payout engine
Underneath the Endurance DSA network is a payout system we built: balances, disbursement rules, and the logic that decides who is owed what across a network that grew from 50 agents to 395. The app and the ERP are the visible parts. The payout engine is the part that has to be right to the rupee.
read the Endurance story →The Cemseal rewards logic
Behind the MAAN loyalty app is a rewards engine: a scanned QR code credits an account, rules decide what it is worth, and a redemption runs through to a real bank payout. The scan is the easy part. The logic that turns a scan into money owed, and money owed into money paid, is the software.
A wallet and payout system on a custom platform
Built recently for a business moving off a packaged ERP: a wallet carrying a running profit balance, and payout handling with rules the old system could not express. This was the part of that engagement with no product to buy, so we built it.
And three we built for ourselves
VisaCRM, Protowrit, and Law Firm Management are custom systems we built and now run as products. The clearest proof we can offer is software we live with the consequences of.
Custom software is a commitment, not a delivery
Buying software makes the vendor responsible for keeping it working. Building it moves that responsibility to whoever built it, and that is the part most custom-software projects underprice. The bill does not arrive at launch. It arrives the first time a rule changes, a volume triples, or an edge case nobody imagined shows up in production.
So we build custom software assuming we will still be responsible for it. The data model gets designed to be extended, not just to pass the first test. The logic gets written to be read by whoever changes it next. This is the same reason the Product Engineering pillar exists: software that runs a business needs an owner past go-live, and a custom system needs it most, because there is no vendor to fall back on.
The market is full of teams who will build you a system and move on. When it breaks, the person who understood it is already gone, and you are paying someone new to relearn your own software.
How a custom build runs
-
01
Check it should be built at all
The first job is confirming that buying will not do. We would rather tell you a packaged tool fits than build you something you did not need. If custom is the answer, we establish exactly which part has to be custom and which does not.
-
02
Model the data before the features
The data model comes first, because it is the thing you cannot cheaply change later. A custom system built feature-first ends up with a data model fighting every rule added after launch.
-
03
Encode the rules where they can be seen
The business logic gets written to be found and changed, not buried. The rules that make the system yours are the rules most likely to change, so they are built to be changed.
-
04
Build against real conditions
Real data, real volume, real edge cases, before real use. Custom software fails at the edges, so the edges are where the testing goes.
-
05
Own it past go-live
Standing responsibility for the system once it runs the business. How that is structured is set out on engagement models.
When should we build custom software instead of buying a product?
When the hard part of the problem is a process or rule no product models, and working around a packaged tool would cost more over time than building the right thing once. If a product fits, we will tell you to buy it.
How is this different from Odoo development?
Odoo development is custom code inside Odoo: modules, features, extensions on a system already running Odoo. Custom software is a system on its own stack, not an Odoo module. If you are on Odoo and need something built into it, that is Odoo development.
What do you build custom software with?
We choose the stack to fit the problem rather than committing every project to the same tools. The right choice depends on what the system has to do, what it connects to, and who has to run it afterwards.
Do you build the interface too, or just the system?
Both, when the project needs it. Where the point of the thing is a screen people work in, that is web app development; this page is about the engagements where the system underneath is the hard part.
Who maintains custom software after it is built?
We can, and we build assuming we will. A custom system has no vendor to fall back on, so standing responsibility for it matters more than with packaged software.
Can custom software talk to our existing systems?
Yes. Connecting it to what you already run is integration work, and it is usually part of the build rather than an afterthought.
Tell us what the system has to do
The rule that no product gets right, the calculation that has to be exact, the process that is yours alone. If a product would do, we will say so. If not, we will build it.