Software built around how your business actually works.
Off-the-shelf tools force your process into someone else's assumptions. We build the system your operation already needs — the one your team stops working around instead of working in.
Custom software development is building an application specifically for one organisation's process rather than adapting a licensed product. Canopus designs, builds and operates web platforms, internal business systems and workflow automation — scoped from your real operation, delivered in two-week sprints, and handed over with full source code and IP ownership.
What we build
Five shapes cover most of the custom work we take on. Yours is probably one of them, or two of them joined together.
Operations platforms that replace the spreadsheet layer
The system your team runs the business in — jobs, orders, cases, sites, assets, whatever your unit of work is. Role-based permissions so a branch manager sees their branch and a director sees all of them, an approval chain that matches your real authority limits, and an audit trail that answers "who changed this price on the fourteenth" without anyone guessing.
Customer and partner portals
An external surface onto internal data — order status, documents, tickets, invoices, statements — without giving outsiders a login to your core system. Usually the piece that removes the most inbound phone calls, and usually underestimated, because the permission model is harder than the screens.
Workflow and business process automation
The work that exists only because two systems don't talk: re-keying orders, reconciling exports, chasing approvals by email. We model the rules, wire the systems together through API integration, and leave humans handling the exceptions rather than the routine.
MVPs and first products for new ventures
The smallest thing that proves the idea with real users and real money — not a demo. Built on foundations that survive success, because the most expensive MVP is the one that has to be thrown away the month it works. If your route is subscription revenue, start at SaaS product development instead.
Legacy modernisation and rescue work
A system whose rules nobody can restate and whose tests do not exist — the behaviour lives in the code and in one person's memory. We start by writing down what it actually does, then rebuild it a workflow at a time so the old and the new can be compared on real inputs before either is switched off. Deeper platform work sits under cloud and DevOps.
When custom software is the wrong answer
A development company telling you to build custom software is not news. Here is the test we actually apply before quoting.
Don't build it if…
- A mainstream product already does 80% of it and the missing 20% is preference, not economics. Xero, HubSpot, Shopify and Jira exist for good reasons.
- The process changes every quarter and nobody can describe the current version. Custom software freezes a process — freeze the wrong one and you have paid to make it permanent.
- Nobody internally will own it. Software without an owner rots faster than the licence you were avoiding.
- The budget only covers the build. A system with no maintenance line is a system with a shelf life of about eighteen months.
Build it when…
- The process is the competitive advantage — your dispatch logic, your pricing rules, your underwriting steps. Handing that to a generic tool flattens the thing you're good at.
- Licence costs scale with headcount and headcount is growing. The maths turns at a surprisingly small team size.
- Your people spend hours moving data between systems that should already agree.
- You need a specific integration nobody's product supports — an EDI feed, a legacy device protocol, a national health or tax gateway.
- Compliance requires an audit trail and data residency you can't get from a shared-tenant SaaS product.
We have talked clients out of builds. It costs us a project and earns a working relationship — and the ones who came back later came back with the right problem.
How a custom build actually runs
Named stages, who is involved, how long each takes, and what you hold at the end of it.
Discovery and specification
A technical lead and a business analyst sit with the people who do the work — not only the people who commissioned it. We map the current process, find the exceptions everyone forgot to mention, and write the specification against which the fixed estimate is set.
You receive: written functional specification, data model sketch, integration inventory, risk list and a fixed-price estimate. It's yours — if you take it to another vendor, that's a legitimate outcome.
Design and architecture decisions
User flows and a clickable prototype for the screens people will live in daily, plus architecture decision records covering the choices that are expensive to reverse: database shape, authentication model, tenancy, queueing, hosting region.
You receive: clickable prototype, architecture decision records, environment plan and a sprint-by-sprint delivery schedule.
Build, demo, adjust
Every sprint ends with working software on a staging environment and a demo you attend. Automated tests and code review gate every merge. You reprioritise the backlog at each demo — inside the agreed scope, reordering costs nothing.
You receive: a working staging deploy every two weeks, sprint notes, and an updated burn-down against the fixed estimate.
Hardening and go-live
Load testing against realistic data volumes, security review, monitoring and alerting wired up, migration rehearsed on a copy of production, and a written rollback plan. Where the system replaces something live, we run both in parallel until the numbers agree.
You receive: production deployment, runbook, monitoring dashboards, rollback plan and a recorded handover session.
Defect window and support
Thirty days in which defects traceable to our build are fixed at no charge. After that, an AMC retainer with severity-tiered response times, or a clean exit with full documentation if you're taking it in-house.
You receive: full repository and infrastructure access, credentials, architecture documentation and knowledge-transfer sessions for your own engineers.
What usually goes wrong on custom builds
Four failure modes account for most late, over-budget software projects — including ones we have been on. Here is how we handle each.
The requirement nobody mentioned
Six weeks in, someone says "of course, month-end runs differently." It is the single most common cause of overrun, and it is never malice — the exception is so normal to the people doing it that it doesn't register as a requirement.
How we handle it: discovery interviews the operators, not only the sponsors, and explicitly asks what happens at month-end, at year-end, on a bank holiday, and when the usual person is on leave.
Waiting on the other side's system
Your ERP vendor takes five weeks to provision a sandbox. Your bank's API team answers monthly. None of it is inside our control, and all of it lands on our schedule.
How we handle it: every external dependency gets an owner and a date in week one, and we build against a mocked contract so that side of the work isn't blocked while access is negotiated.
Data migration underestimated by everyone
Fifteen years of records with three different address formats, duplicate customers, and a field that means two things depending on when it was entered. Migration is routinely quoted as a week and routinely takes four.
How we handle it: we profile a real extract during discovery — not a sample — and price migration as its own line item so it can't quietly consume the build budget.
Nobody uses it after launch
The software works and the team keeps using the old spreadsheet. Almost always because the new system is slower for the ninety-per-cent case, even if it's better for reporting.
How we handle it: the most frequent task gets designed first and measured in clicks and seconds against the current method. If ours is slower, we redesign it before launch, not after adoption fails.
What we build with, and why
The stack is chosen for what you can hire for and maintain after handover — not for what is interesting to us this year.
| Layer | Our default | We switch when |
|---|---|---|
| Backend | Node.js / TypeScript, or Laravel (PHP 8.3) where the team already runs PHP | You have in-house .NET, Python or Java engineers — we extend your stack rather than adding a second one |
| Frontend | React with TypeScript; Next.js when the pages need to be indexable | The app is entirely behind a login and a lighter SPA build is cheaper to run |
| Database | PostgreSQL | MySQL for continuity with an existing estate; MongoDB only where the data genuinely has no stable shape |
| Background work | Redis-backed queues with retry and dead-letter handling | Volume or ordering guarantees justify Kafka or a managed cloud queue |
| Hosting | Containers on AWS ECS or a managed platform, infrastructure as code | Data residency, procurement policy or an existing Azure/GCP commitment says otherwise |
| Authentication | Application-owned auth with MFA, or Microsoft Entra ID / Google Workspace SSO | Enterprise buyers require SAML — we add it rather than retrofitting identity later |
| Testing & CI | Automated tests on every merge, GitHub Actions pipeline, staging that mirrors production | Never. This one is not negotiable, and it's why the AMC costs what it costs. |
Scroll the table sideways for the full comparison.
Commonly integrated in these builds
Cost, timeline, team and ownership
How do you price a custom software build?
Cost is driven by how many roles and permission rules the system carries, how many external systems it has to talk to, and how messy the data being migrated turns out to be — not by a screen count. A paid discovery of one to three weeks produces the written specification, the integration inventory and a fixed estimate. We don't quote from a phone call, and the specification is yours to take elsewhere.
How long does a custom software project take?
Ten to twenty weeks for a first production release. Discovery takes 1–3 weeks, design 2–4, and build runs in two-week sprints from there. Integration with an ERP, a hospital system or an EDI feed adds three to six weeks — and we flag that during scoping, not afterwards.
Who owns the source code and IP?
You do. IP assignment is written into the contract and transfers on payment — repository, CI configuration, infrastructure-as-code, credentials and documentation. We retain no licence and build on no proprietary framework of ours that you'd have to keep paying for.
How do you choose the technology stack?
By what your team can hire for and maintain after handover. If you already run Laravel and MySQL, we extend that rather than introducing a second stack. With no in-house team, we default to TypeScript with Node or Next.js, PostgreSQL and a managed container runtime — that combination has the deepest hiring pool in every market we deliver into.
What team do we actually get?
A technical lead, engineers, a QA engineer part-time and a designer for the first half — the mix is set by what the specification asks for, and the names are written into the proposal. The lead who scopes your project stays through launch, with no reassignment in month three, and you talk to that team directly rather than through an account manager.
Can you take over software another company built?
Yes, and roughly a third of our engagements start that way. We run a two-week audit first — architecture, dependency health, test coverage, security exposure, deployment risk — and hand you a written takeover plan before touching production. Sometimes that plan says the right answer is to keep it and fix three things, not rewrite it.
What happens if requirements change mid-build?
They will, and the two-week demo is where you find out. Seeing the thing working is what turns “that is roughly right” into “actually, approvals need a second step”, and that is the point of demoing every cycle rather than at the end. In practice most changes are a reshuffle of what is already agreed rather than new work; how that is priced depends on which engagement model you are on, and the rules are published there. What never happens is a scope change arriving as a surprise line on an invoice.
Do you sign NDAs and work with our procurement process?
Yes — NDA, MSA and SOW are standard, and we're used to security questionnaires and data processing agreements. Our security and compliance page answers most of what your reviewers will ask before they ask it.
Related services
Describe the process you're trying to fix.
Not the software you think you need — the thing that's slow, error-prone or invisible today. An engineer replies within one business day with a view on whether custom is the right call at all.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732
- Discovery is paid, and the output is yours to take anywhere