Software Customisation

Nearly right is expensive. Close the gap properly.

Extending the systems you already own rather than replacing them, in the way the platform supports, so that next year’s upgrade is an ordinary morning rather than a project.

Configuration before codeUpgrade-safe by designFree first hour
The free first hour

What you leave with

  • Whether your platform can do what you need with configuration alone
  • The customisations that will survive upgrades, and the ones that will not
  • A rough effort and a safer order to do them in
Book your free hour

With a senior architect, not a salesperson. Sixty minutes, no cost, no obligation.

The last twenty per cent

The product does most of it. The rest is where your business actually differs.

Every organisation reaches the same point with bought software. It handles the ordinary cases well, and then there is the part that is particular to you: the approval nobody else needs, the pricing rule, the report a regulator asks for. There are three honest answers, and only one of them is customisation.

☰

Change the process

Sometimes the software is right and the process grew around an older system. We will say so. It is the cheapest answer and the one vendors never suggest.

⚙

Configure to the edge

Most platforms can do more than their owners know. Before anybody writes code, we find out what the product already supports, because configuration survives upgrades and code has to be maintained.

◆

Build the difference

When the gap is real, we build it: in the platform’s own extension model where that exists, or as a small service beside it where it does not.

How we keep it maintainable

The question is not whether it works on Friday. It is whether it survives the next upgrade.

⚑

Extension points, not core edits

Work goes where the vendor supports it: scripts, custom functions, webhooks and APIs. Changes made to the core are the ones that break when the platform updates.

⇄

A clear line

What lives in the product, what lives beside it, and why. Drawing that line on purpose is the difference between a system somebody can hand over and one nobody wants to touch.

☷

Data you can trust afterwards

Migration and the checks that prove it worked: record counts, sample comparisons and a way back. Most of the risk in customisation lives here rather than in code.

✎

Documented and yours

What was changed, where, and how to change it again. The code and the documentation belong to you, and we would rather your own team maintained it.

Platforms we work in most often

Zoho in particular, where the standard configuration usually stops just short.

◉

Zoho, including Deluge

Custom functions, workflows and business logic across CRM, Bigin, Bookings, Campaigns and Flow, and the connections between Zoho and everything around it.

Integration work
☁

Microsoft and Google platforms

Dynamics 365, Entra ID, Microsoft 365 and Google Workspace: extension, automation and the identity and permission work that goes with them.

⚙

Products you bought or inherited

Industry platforms, learning and student systems, booking engines and the internal application that somebody built a decade ago and everybody still uses.

Capabilities

What we customise

Extending the systems you already own, in the places the vendor supports.

Zoho

Custom functions in Deluge, workflows, blueprints and integrations across Zoho CRM, Books, People, Projects and Flow.

Microsoft

Dynamics 365, Power Platform, Microsoft 365 and Entra ID: extensions, automation and the permission work that goes with them.

Google Workspace and others

Apps Script, add-ons and integrations, plus HR, finance and industry platforms with an API worth using.

Learning and student systems

Extensions and integrations for learning platforms and student record systems, through LTI and the vendors' own APIs.

Upgrade-safe changes

Custom code kept outside the core, documented and tested, so the next vendor release is an ordinary day.

Or replace the patchwork

Where the customisation costs more than the tools, we say so, and show what one platform would look like.

When people call us

Sound familiar?

  • Your platform does 90 per cent of what you need and the rest is manual
  • An upgrade is postponed because nobody knows what the customisations will break
  • Customisation was done by someone who has since left
  • Several tools each need a workaround to talk to the others
  • You are paying for licences you only half use
Why Aitina

A small, senior team that stays accountable.

  • Architect-led. Every engagement is led by a senior architect who stays accountable for the decisions, from the first hour to the handover.
  • Over twenty years of building and integrating software. Enterprise integration, cloud platforms, product delivery and now AI agents, across sectors where systems cannot fail.
  • Independent and vendor-neutral. AWS, Azure and Google Cloud, and whatever platforms you already run. We recommend what fits, including doing less.
  • Research, applied. The patterns we use are published openly on The Software Lens and applied by our R&D Wing, so you can read the reasoning before you hire us.
  • We run what we recommend. We build our own product, Nexcubator, on the same architecture we design for clients.
  • You own everything. Your repository, your cloud account and your documentation from the first week. Based in Ireland, working across the EU and beyond.
Book a free 1-hour consultationDescribe the problem; we will tell you what it actually is, including when the answer is not us.
Straight answers

Questions we get asked

Will customising the software stop us upgrading it?▼

Not if the work is done where the vendor intends it to be done. Custom functions, workflows, webhooks and APIs are supported surfaces and survive updates. Edits to the core product are what turn an upgrade into a project, which is why we avoid them and say so when a request would require one.

How do we know whether to customise or replace the system?▼

Compare the cost of the gap with the cost of the move, including the year of disruption that a replacement brings and the processes that would have to change with it. We will give you that comparison honestly, including the cases where replacing is the right answer and there is no work in it for us.

Who owns the code you write?▼

You do, along with the documentation. We would rather hand it to your team than become the only people who understand it, and the handover is part of the work rather than something arranged afterwards.

Can you work with our existing vendor or partner?▼

Yes, and it is common. Where a platform partner holds the licence relationship, we do the engineering that sits beside it, with the boundary agreed in advance so nobody is waiting on anybody.

Start here

One free hour. No pitch, no obligation.

Bring the problem you are stuck on: an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.

  • Architecture and integration review
  • AI feasibility: what will actually work, and what will not
  • AWS, Azure and Google Cloud cost and design
  • Business process audit and ISO readiness
  • Technical due diligence before you invest or acquire
Or the other way round

When customising the tools costs more than replacing them.

Sometimes the honest answer is that the HR system, the timesheet tool and the project tracker are each fine, and the cost is in the customisation that holds them together. Nexcubator is one platform for all of it, built so nothing has to be stitched.

See what one platform looks like