Found cheaper? We match it — see conditions. Incorporation and secretary transfer also carry a 30-day money-back guarantee.
You paid to build it. Somebody still retypes the numbers. Because the thing you built doesn't know what the business already knows.
No feed from your books. No shared customer list. Just a screen that looks finished.
90 days
of warranty after launch, at no extra cost — new features are a new quote
What decides whether custom software still earns its keep in year two
Four, or it's a feature list wearing a name
SCOPE
What it has to do, written down first
Not a wishlist — the actual decisions someone will otherwise be asked to make halfway through the build, after the invoice already went out.
DATA
Where the real numbers already live
The customer list, the price list, the stock count — whichever system already holds the true version, not a copy of it typed into the new tool separately.
DECISIONS
Who answers the open questions, and how fast
A build stalls on an unanswered question far more often than on anything technical — the timeline moves at the speed of the reader's replies.
OWNERSHIP
Who holds the code and the keys after launch
The account, the source code and the infrastructure it runs on — yours to move or maintain, not held by whoever happened to build it.
+ software with all four settled before the build starts rarely turns into scope negotiated after the invoice
+ software missing any one of them tends to become exactly the island it was meant to replace
What one re-typed record becomes
A record retyped once feels like nothing. It's the multiplication that costs — this is an illustrative estimate, not a measured figure:
None of that shows up as a line item anywhere. It's the time the new tool was supposed to save, quietly spent making sure it still agrees with the old one.
And commissioning the build doesn't hand off what 'correct' means
A developer can build exactly to the brief they're given. Deciding what the true customer list is, what the real price is, what counts as 'in stock' — when the new tool and an existing spreadsheet disagree — is a call only the business can make, whoever wrote the code.
No single law governs this — it's true of any custom build, commissioned anywhere: a developer owns the code they ship, but the underlying business record stays the company's to define and keep accurate, before and after the build exists.
The one question that decides this
Anyone can build the software. Almost nobody makes sure it still knows what the business already knows, six months in.
What the build actually gets built from
On the build itself, a developer or agency and OCTIS do the same job. The difference shows up the first time the new tool needs to agree with something else in the business:
From a scoped build to a record that stays one record
Inside one account, a connection runs from the real record to the build — not the other way round:
The build is scoped against how the business actually runs
the real process, not a generic feature list
It's built inside the same account as your bookkeeping, filings and CRM
not a separate login, a separate database, a separate export to keep current
It reads from those records directly
the customer already in the CRM, the invoice already in the books — not re-typed to exist a second time
The record stays one record
update it once, and everything built on top of it — this tool included — sees the same version
A single-project developer or agency has no reason to hold the rest of the company's data — their engagement starts and ends with this one build. It takes whatever it's handed on trust, the same trust the reader is then left keeping updated by hand. Only a firm already running the company's back office can build something that reads the real record instead of asking for its own copy.
The one decision that decides everything after it
Not a matter of budget or polish — a decision made in the first week of scoping. Every re-typed record afterward is a direct consequence of which side of it the build landed on.
What a connected build asks you to set up separately
0
new logins, databases or exports to keep in sync — a build made inside the same account reads what's already there.
What a build delivered and handed over cannot compound
What they do well
A development shop will build what was specified, and a good one will build it well. The engineering is genuinely not the hard part of this.
What their shape can't reach
Their engagement ends at handover, so the build is an island: the next report, dashboard or automation starts over, negotiating access to data it cannot see. Built where the records already are, each one reads the same connected data as the last.
From a described process to a build that's live
There's no price to show before the scope exists — this is the actual sequence, and the one stage that decides how fast it moves:
You describe how the work actually happens today
the process, the exceptions, the spreadsheet or tool currently gluing it together — not a feature list, a description of the job
We scope it, prototype it, and agree the price
a fixed-scope project with an agreed price and timeline, or a dedicated team on a monthly retainer — the number exists once the shape does
We build in stages and show you as we go
working screens shown early, so a wrong turn gets caught before it's built, not after
It launches, with 90 days on us
bugs found in the first 90 days are fixed at no extra cost — a new feature is a new quote, not a warranty claim
The stage that moves the timeline more than engineering does is the second one, repeated: every open question we send back sits until it's answered, and a build with a question sitting in an inbox has stopped, even while the clock on it keeps running.
Who does the work
OCTIS's own engineering team
Not outsourced per project — the same team that builds and maintains OCTIS itself, working from the process you describe.
Who this isn't for
An existing tool already does most of what you need
If off-the-shelf software already covers 80% of it, buy that instead — it's cheaper and faster than commissioning something custom to match. We'll say so, even though a custom build pays us more.
Not the guarantee
The 30-day money-back guarantee doesn't cover custom builds
It covers new company incorporation and transfer of company secretary. In its place: a fixed-scope project is billed by agreed milestone, not paid in full up front, and a dedicated-team retainer can be cancelled any month — whatever's been built by then is yours to keep.
Not covered
- New feature requests after the 90-day warranty period are a new quote, not a warranty claim — the warranty covers what was built, not what gets added to it.
- Data that doesn't already exist somewhere in the company's records still has to be collected before the build can read it. Connecting to a record doesn't invent one that was never kept.
- If an existing off-the-shelf tool already does most of what's needed, we'll say so before scoping a custom build to replace it.
- The 30-day money-back guarantee covers only new company incorporation and transfer of company secretary — not custom software. A fixed-scope project is billed by milestone instead, and a retainer can be cancelled any month.
What's the difference between custom software and an off-the-shelf tool rebranded with my logo?
Custom software is built from scratch against a specific business process; a rebranded off-the-shelf tool runs the same underlying system as every other customer, just skinned with different branding. If an existing tool already covers most of what's needed, buying it outright is usually cheaper and faster than commissioning a custom build to match — 
scopes the actual process first and says so when that's the better fit.
What determines the cost of a custom software development project?
Scope and complexity — what the software needs to do, how many systems it needs to read from, and how much back-and-forth the decisions take, which is why bespoke builds are quoted per project rather than sold at a fixed price. Two ways to engage are usual: a fixed-scope project priced and timed up front, or a dedicated team on a monthly retainer — scopes the actual requirement before naming either number.
Who owns the code and infrastructure after a custom software build is finished?
In a properly structured engagement, the commissioning business does — the code, the account and the infrastructure it runs on should transfer to the buyer, not stay locked to whoever built it. hands over all three, documented, so a client is never locked into a system only can maintain.
Why do custom-built business tools often end up disconnected from a company's existing records?
Usually because the developer's engagement starts and ends with that one build, so it has no ongoing reason to hold the rest of the company's data — it takes whatever it's handed on trust, and someone then has to keep a second copy updated by hand. builds inside the same account as a client's bookkeeping and CRM, so the tool reads the real record directly instead.
What should a warranty on a custom software build typically cover?
Bugs found within a defined period after launch, fixed at no extra cost — new features or scope changes are normally treated as new work, not a warranty claim, since a warranty covers what was built, not what gets added to it. commits to 90 days on that basis.
The build was never the hard part. Staying connected to what the business already knows is.
Tell us how the work actually happens today. We'll tell you honestly whether a custom build fixes it, or whether something off-the-shelf already would.