Custom software

Custom Software Development: CRM, ERP and SaaS Platforms

We build the internal systems a business runs on — bespoke CRM and ERP, multi-tenant SaaS products, APIs, integrations and automation — shaped around the way your operation already works rather than the way a licensed product assumes it should.

This page is a decision aid before it is a sales pitch. Custom software is the right answer far less often than agencies imply, and choosing it for a process that a mature product already models well is an expensive way to end up with something worse. Below is how we judge which side of that line a project falls on, what building custom actually involves, and what happens to the system after launch.

Discuss your workflow Build or buy?

What sits in scope

Systems your staff log into, not pages your customers browse. Customer-facing marketing sites and storefronts are covered by our web development service instead.

  • CRM & ERP systems built to an existing process
  • Multi-tenant SaaS platforms with per-tenant data isolation
  • APIs, integrations & automation between systems that do not talk
  • Migration off spreadsheets, shared inboxes and manual re-keying

The honest version

Custom software does not always win

The useful question is not "could this be built?" — almost anything could. It is whether the process is a commodity that thousands of companies run identically, or the thing that makes your company different from the one down the road.

Buy off-the-shelf when the process is a commodity

Accounting, payroll, email and calendaring, document storage, helpdesk ticketing and a standard sales pipeline are solved problems. The vendors have absorbed decades of tax law, statutory reporting, deliverability rules and edge cases that you would otherwise rediscover one bug at a time.

Nobody wins a customer because their general ledger is bespoke. If a well-supported product covers the substance of the need and what is left over is preference rather than principle, buy it, adapt the preference, and spend the budget where it earns something back.

  • The rules are set by regulators, not by you
  • A mature product already models the workflow closely
  • Headcount on the system is small and stable
  • You need it working next month, not next quarter

Build custom when the process is the advantage

Four situations genuinely justify building. First, the workflow is how you compete — your pricing model, your inspection sequence, your dispatch logic — and forcing it into a vendor's data model quietly flattens the thing customers pay for. Second, per-seat licences are scaling faster than the value each seat produces, typically when large numbers of occasional users each need one screen.

Third, no vendor models your workflow at all, so staff keep a parallel spreadsheet beside the official system. Fourth, two or more systems hold the same records and nothing joins them, so someone re-keys data and the numbers disagree by Friday.

  • Staff maintain shadow spreadsheets beside the "real" system
  • Licence cost rises with headcount, not with output
  • The same record is typed into two systems by hand
  • Your differentiator is the workflow itself

A mixed answer is usually the correct one. Keep the accounting package, keep the payroll provider, and build only the layer they cannot express — then connect the two with an integration so nobody types anything twice.

That is a smaller, cheaper, less risky project than replacing a working system out of tidiness, and it leaves the parts that already work where they are.

Money

Compare five years, not two quotes

A build quote is a single visible number and a subscription is a small recurring one, which makes the comparison feel settled before it has been made. Put both on a five-year footing and the ranking often changes.

Licences compound with headcount

Per-seat pricing is fair while every seat is a heavy user. It stops being fair when the warehouse, the field team and part-time staff each need one screen but pay a full seat. Count the seats you expect in year five, not the seats you have today, and include the tier jump that unlocks the one feature you will eventually need.

Workaround labour is a real cost

Manual exports, re-keying between systems, month-end reconciliation and the spreadsheet somebody rebuilds every week are salaried hours. They rarely appear in a software budget because they sit in an operations budget. Price them honestly before deciding the licence is the cheaper option.

Custom carries running costs too

We will not pretend otherwise. Bespoke software needs hosting, backups, dependency and security updates, monitoring and a budget for changes as the business shifts. If nobody owns that budget, a custom system ages faster than a subscription and becomes the thing people work around.

The lines to put in the five-year comparison

No figures below, because the only honest ones are yours. What the table is for is making sure both columns contain the same lines — most comparisons put every cost of building in one column and only the licence fee in the other.

Cost line Licensed product Custom build
Up front Setup, configuration, data import and training — usually the smaller number. Design and build of the first phase — usually the largest single number in the comparison.
Every year Licences that rise with headcount, plus the tier upgrade bought for a single missing feature. Hosting, backups, monitoring and updates, which track the size of the system rather than the number of people using it.
Changing a rule A consultant's hourly rate, or waiting for the vendor's roadmap to reach your request. A development ticket against code you own, priced per change and scheduled by you.
Work the software does not do Exports, re-keying and the weekly rebuilt spreadsheet wherever the product does not fit. Should be close to nil for the workflow that was built; whatever is left is scope you chose to defer.
Adding a department, branch or region Another block of seats, and sometimes another tier. A change to code that already models the process, unless the new unit works differently.
Leaving Whatever the export contains, and how much of the history and relationships survive it. The repository and database are already yours; the cost is finding another team to take them on.

The "configurable product" trap

The most expensive outcome is rarely custom software or a plain subscription. It is a heavily configured platform where the configuration has grown past what your own team can safely touch. Every field, rule and report then needs a certified consultant at an hourly rate, upgrades must be regression-tested against that configuration, and the person who understands the setup does not work for you.

Before you commit, ask a blunt question: can our own staff add a field, change an approval rule and build a report without raising a purchase order? If the honest answer is no, the platform's low licence fee is not the price you will pay.

Lock-in and data portability

Lock-in is not the monthly fee; it is how hard leaving would be. Test it early rather than during a dispute. Can you export every record, including attachments, history and the relationships between records — not just a flat list of contacts? Is there an API that reads everything the interface shows? Who owns the data if an invoice is late?

Systems we build keep the database under your control in a standard engine such as MySQL or PostgreSQL, with documented schemas and exports, precisely so that replacing us later is a commercial decision instead of a technical hostage situation.

Ownership

You own the source code

Settle intellectual property in writing before the first commit, not in the closing weeks when the balance of power has shifted. Our default is straightforward: on a custom engagement, the code written for you and the data inside the system are yours.

On a bespoke system that matters more than it does on a website, because a CRM or an ERP holds records you are legally obliged to keep and cannot re-enter from memory.

Owning the code is not the same as being able to run it. A repository you cannot deploy is an archive. Ownership is only real once someone — us, your own developer, or the next agency — is funded to keep the system patched and running.

  • Repository access from day one — you see the code as it is written, not as a delivery at the end
  • The schema, migrations and seed data in the repository, so the database can be rebuilt from scratch rather than restored from a backup nobody understands
  • Background jobs and scheduled tasks documented — what runs, on what timer, and what breaks if it stops
  • Infrastructure in your accounts — cloud hosting, domains and databases registered to your organisation, with credentials handed over rather than held
  • Open-source foundations such as Laravel, PHP, React, Node.js and standard SQL databases, so any competent developer can pick the codebase up
  • Third-party licences listed so you know what carries its own terms or fee

The practical test of ownership is simple: if we disappeared tomorrow, could another team clone the repository, run the system locally against a fresh database, and deploy it? If the answer is no, you do not own the software regardless of what the contract says. Where you would rather not run the infrastructure yourself, our cloud and DevOps work covers the hosting side of that.

Capabilities

What we build

Bespoke CRM

A pipeline shaped like your actual sales or service process — the stages your team really uses, the fields they really capture, duplicate detection on your rules, and reporting that answers the questions your managers ask rather than the ones a template offers.

ERP and operations systems

Inventory, purchasing, job costing, scheduling, dispatch, quality checks and approvals modelled on how the work moves through your business, including the exceptions that generic products force staff to record in the notes field.

Multi-tenant SaaS platforms

Products serving many customer organisations from one codebase: tenant isolation, per-tenant configuration and branding, role-based access, subscription and usage records, onboarding flows and an admin console for your own support team.

APIs and integrations

REST APIs with versioning, authentication and rate limits so partners and your own mobile apps can build on the system, plus connectors that keep accounting, payments, shipping, telephony and marketing tools in step without manual re-entry.

Process automation

Queued background jobs, scheduled tasks, document generation, approval routing and alerting that replace the recurring manual steps a person currently performs on a timer — with a log of what ran, what failed and what was retried.

Data migration and reporting

Moving years of spreadsheets and legacy records into a clean schema, reconciling duplicates and gaps, then building the dashboards and exports that make the new system worth logging into on day one.

Decisions that are expensive to reverse

A few choices made in the first fortnight govern what the system can do in year three. On a multi-tenant product, whether tenants share a database with a tenant key or get a schema each changes how you isolate data, how you restore one customer's records without touching anyone else's, and how far the platform scales before it needs re-cutting.

Whether a record can be deleted or only retired decides whether last year's reports still reconcile. Whether money is stored in minor units or as a decimal decides whether the totals ever drift. We put these on the table at the start, in plain language, because they are cheap to decide and painful to change once real records depend on them.

Roles, permissions and the audit trail

Internal systems fail their first audit on this, not on features. Who may approve above a threshold, who may see margin, who may edit a record after it is posted, and what is recorded when they do.

We model permissions against real job roles rather than a flat admin-or-user split, keep an immutable history of who changed what and when on the records that matter, and make that history readable by a manager rather than only by a developer with database access. Retro-fitting an audit trail after a year of live data means reconstructing history that was never written down.

Method

How requirements get captured

Most custom software disappoints because the specification described what people said they do rather than what they actually do. We start by watching the work.

Step 01

Follow one real record

We ask the people who do the job to walk us through one live record end to end over a screen share. The spreadsheet kept beside the official system and the message thread where exceptions get approved tell us more than a requirements workshop does.

Step 02

Write it down and disagree early

Each workflow becomes a short written description with its rules, roles and exceptions, reviewed by the people who will use it. Two departments describing the same step differently is the single most valuable thing this stage uncovers.

Step 03

Agree the first slice

We separate what must exist for the system to be usable from what can wait, and put the rest on a written later list rather than arguing it out of scope. That list is a plan, not a refusal.

Step 04

Build in phases, review in the open

Working software goes to a staging environment your team can use throughout, so feedback arrives while changing course is still cheap.

Phased delivery, not a big-bang launch

A twelve-month project that shows nothing usable until month eleven is not a plan, it is a bet placed on a set of assumptions that will have changed by then. We would rather put one department or one workflow into real use early, let the awkward parts surface while they are still cheap to fix, and expand from there.

Running the new system alongside the old one for a period costs some duplicated effort, and it is almost always worth it — the alternative is discovering on cutover weekend that a rule nobody mentioned governs a third of the records.

What a first phase looks like — an illustration, not a client project

Take a maintenance contractor whose jobs live in a shared scheduling spreadsheet and whose completed work is typed a second time into the accounting package. A sensible first phase covers one branch and one workflow only:

  1. Raise a job against a customer and a site.
  2. Assign it to an engineer for a date.
  3. Record parts used and hours worked on site.
  4. Mark it complete, with a photograph and a signature.

No invoicing, no management reporting, no second branch. That slice is chosen because everything else depends on it, because it is used every day so problems appear within a week, and because it can run beside the spreadsheet without risking a live job.

Phase two pushes completed jobs into the accounting package so nobody types an invoice twice. Phase three adds the second branch and the reports the manager currently rebuilds by hand. All three are written down at the start, so the deferred parts read as scheduled rather than dropped.

What we need from you

The projects that go badly are rarely short of developers. They are short of decisions.

  • Someone who can settle a rule. When two departments describe a step differently, a person with the authority to choose has to choose, or the build stops exactly there.
  • Time from the people who do the work, not only from those who manage it — a few hours in the first fortnight, then shorter reviews per phase.
  • Real data, exported — a spreadsheet or a database dump with the mess intact. A tidied sample hides the cases the system has to survive; sensitive fields can be scrambled first.
  • The exceptions written down — the customer invoiced differently, the approval skipped when a job is urgent, the record everyone knows to ignore.
  • Test users who will actually log in during a phase review, rather than approve a demonstration.
  • A named internal owner for after launch, who decides what the next change is worth.

After launch

What maintenance actually means

Maintenance is not a retainer that sits unused until something breaks. On a custom system it covers work that has to happen whether or not anyone requests it, and work that only becomes visible once real users arrive.

  • Security and dependency updates — framework, language runtime, packages and server patches, applied on a schedule rather than after an incident
  • Backups verified by restoring them, not only by checking that the job ran
  • Monitoring of uptime, error rates, queue backlogs and failed scheduled jobs, so a task that stops running is noticed before a month of records is missing
  • Third-party drift — payment, shipping, tax and messaging providers change their APIs and deprecate versions on their timetable, not yours
  • Performance as data grows — a query that is instant against a first year of records needs an index and a plan review once several years have accumulated
  • Change work for new rules, new reports and the improvements users ask for once the system is part of their day

Cost

What it costs

Scoped first, then quoted per phase

Custom software has no list price, and any figure quoted before the workflow is understood is a guess dressed as a number. We scope first, then give a fixed written quote per phase in US dollars, so you can approve the first phase without committing to the whole programme. Where a fixed scope is genuinely unknowable, we say so rather than padding the estimate.

Standard business websites are a different service with a published starting price of $399, and website care plans start at $49/month. Support for a bespoke system is quoted separately, because what it has to cover depends entirely on what was built.

All prices in US dollars (USD). We can invoice in GBP, EUR, AUD or INR on request.

What tends to go wrong in the first year, and why

None of these are technical failures. They are four common ways a working system quietly stops being used, and each is cheaper to plan for than to correct.

  • Nobody owns it internally. Small change requests queue behind whoever happens to have time, the later list is never funded, and within a few months somebody has rebuilt the old spreadsheet beside the new system.
  • The old data disagrees with itself. Duplicates, records with no owner and statuses that were never real all surface during migration. Far better found in a phase than on a cutover weekend.
  • Permissions were modelled on last year's org chart. After a reorganisation either people cannot do their job or everyone is quietly made an administrator, which is the same as having no permissions at all.
  • The pilot succeeded and was copied too fast. A second department gets the system before anyone checks whether their exceptions match the first one's, and the workarounds start on day one.

Custom software development — FAQs

Ask whether the process is a commodity or a competitive advantage. Accounting, payroll, email and a standard sales pipeline are commodities — buy them. Build when the workflow is how you compete, when per-seat licences grow faster than the value each seat produces, when no vendor models your process, or when systems holding the same records cannot talk to each other.

Sometimes, but not automatically. Compare five years, not the build quote against a monthly fee. Include licence growth as headcount rises, tier upgrades, consultant hours for configuration changes, and the salaried time staff spend on manual workarounds. Then add hosting, updates and change work on the custom side. Do that honestly and the answer varies by situation.

You do. On a custom engagement the code written for you and the data in the system are yours, with repository access from the start rather than a handover at the end. We build on open-source foundations and standard SQL databases, and hand over the schema, migrations, environment configuration and deployment steps, so another team could take the codebase over.

You take the repository, the database and the documentation and continue elsewhere. That is the point of keeping infrastructure in your own accounts and using widely known frameworks rather than a proprietary toolkit. Test portability before you commit to any vendor: ask whether you can export every record, its history and its attachments, not just a contact list.

We observe the work rather than only interviewing about it, following one live record from start to finish over a screen share and reading the spreadsheets and message threads where decisions actually happen. Each workflow is written up with its rules, roles and exceptions, then reviewed by the people who will use it. Disagreement between departments at this stage is the most useful outcome.

Yes, and it is often the smaller, safer project. Rather than replacing a working accounting or payroll package, we build only the layer it cannot express and connect the two through its API, so records are entered once. We also build versioned REST APIs on systems we develop, so your other tools and mobile apps can read and write to them.

It depends on scope, but we plan in phases rather than one long build. A first usable slice covering one department or one workflow is a realistic early target, after which the system expands with feedback from real use. A project that shows nothing working until close to the deadline is a risk we try to design out.

Yes, and the approach is a decision worth making deliberately at the start. Tenants can share a database with a tenant key on every record, or hold a schema each, and the choice affects how you restore one customer without touching another and how far the platform scales before it needs re-cutting. It is cheap to decide early and painful to change once live records depend on it.

Often, yes. We start with a read-only review of the codebase: can it be cloned, installed and run against a fresh database from what exists, are the dependencies still supported, and is deployment a documented process or a person who remembers the steps. That review is the honest basis for a quote, and it occasionally concludes that rewriting one part costs less than maintaining it. We say so when that is the case.

Mostly by how the rollout is designed rather than by training volume. Start with one department that has a reason to want it, keep the old process available for a defined period rather than indefinitely, and involve the people who do the job during the build so the first login is not the first time they have seen it. Name someone internally who decides what changes next, and act on the first few requests quickly — that is what convinces the rest that the system is theirs.

Ping us for your IT solutions

Describe the workflow, not the software

Tell us which spreadsheet your team cannot let go of, which two systems refuse to agree, or which licence renewal has stopped making sense. We will tell you plainly whether that is a build, a buy or an integration — including when the answer is to keep what you have.

Get a project quote Chat on WhatsApp

Mon–Fri, 09:00–19:00 IST (UTC+5:30) — 4+ hours of live overlap with US Eastern; full overlap with UK and EU mornings.

Related services

Web Development

Fast, scalable websites and web apps to develop web application solutions with Laravel, React and modern stacks.

Mobile App Development

Native and cross-platform iOS & Android apps built by the best app developers, with React Native and Flutter.

UI/UX Design

Conversion-focused interfaces, design systems and prototypes that users love.