Building an inspection system in-house is a defensible decision under three specific conditions, and a costly one outside them. The published analysis is consistent about where the trap sits. A well-scoped custom application for a mid-market operator in 2026 runs roughly fifteen to forty thousand dollars for discovery and architecture, eighty to three hundred and fifty thousand for twelve to twenty-four weeks of development and testing, and two to eight thousand a month thereafter for maintenance, enhancement and infrastructure — putting first-year cost in the region of a hundred and fifty to four hundred thousand. That figure is genuinely comparable to the true total cost of a mid-market enterprise platform of equivalent scope, which is why the build case looks reasonable on a one-year view. The divergence begins in year two. Ongoing maintenance typically runs fifteen to twenty-five percent of the original build cost annually, forever, and the research is blunt that hidden costs usually double the effective cost across three years, with thirty to fifty percent of them emerging in the first. And in maritime there is a fourth cost that generic build-versus-buy analysis never mentions: you become the sole maintainer of a regulatory surface that changes several times a year. Start a free trial of Marine Inspection and price the alternative properly before deciding.
Year 1
Roughly comparable, which is why build cases get approved
A well-scoped custom application lands around a hundred and fifty to four hundred thousand in its first year, described in published analysis as directly comparable to the true total cost of ownership for a mid-market enterprise platform of equivalent functional scope. On a twelve-month view the decision is genuinely close.
Year 2
The subscription stops rising and the maintenance line begins
Custom software carries no per-seat fee, which is the genuine advantage of building. Against that, maintenance typically runs fifteen to twenty-five percent of the original build cost every year, plus infrastructure at two to eight thousand monthly, plus the staff who hold the knowledge.
Years 3-5
Hidden costs have roughly doubled the effective figure
Research on build decisions finds hidden costs — maintenance, technical debt, hiring, compliance — typically doubling the effective cost over three years, with thirty to fifty percent of them appearing in year one alone. Most build-versus-buy analyses undercount these, because at the point of decision they are not yet visible.
None of this makes building wrong. It makes the one-year comparison the wrong comparison, and a five-year view the only honest one — the same horizon on both sides, with maintenance, infrastructure, staffing and regulatory upkeep on the build side rather than only the development quote.
Three Conditions Where Building Is Right
These come from the general build-versus-buy literature and they are worth applying honestly rather than rhetorically, because for some readers they will hold. Book a Marine Inspection demo only if none of the three describes you.
Condition 1
You have a software team large enough to absorb the maintenance burden
The threshold cited in the literature is substantial: organisations with fifty-plus person internal software teams can absorb maintenance without it breaking the business, and a build staffed with around five developers and a dedicated product manager solves the continuity problem. Below that, the maintenance obligation lands on people whose main job is something else.
Maritime reality: very few ship operators have this, and those that do usually have it for commercial or chartering systems rather than for technical maintenance.
Condition 2
The software is your competitive moat rather than a utility
The governing rule stated across the literature: if the software performs a utility function that does not differentiate you from competitors, lean toward commercial off-the-shelf, so the team can focus on high-value work rather than reinventing standard business processes. Build where seventy percent or more of the features are genuinely unique to your business.
Maritime reality: recording an inspection is not a differentiator. Every operator in your segment does it against the same conventions, for the same inspectors, to the same standard.
Condition 3
Your regulatory environment prohibits commercial software
Where classified work, air-gapped networks or accreditation requirements make third-party software legally impossible, there is no decision to make. The literature names classified defence contracts and equivalent constraints as genuine cases where building is the only route.
Maritime reality: this one does apply — to naval and classified programmes, and occasionally to government fleets under accreditation requirements. For a commercial operator it almost never does.
Two of those three fail for the overwhelming majority of commercial fleet operators, and the third is a genuine carve-out worth respecting rather than arguing with. If condition three describes your operation, stop reading — a commercial platform is not appropriate and no amount of cost comparison changes that.
The Cost Nobody Puts in the Build Estimate
Generic build-versus-buy analysis stops at maintenance and infrastructure. Maritime adds a category that has no equivalent in most industries. Sign up for Marine Inspection and let somebody else carry this line.
What changed in a single recent period
SOLAS Regulation II-1/3-13 on lifting appliances entered force on 1 January 2026, with new certification, marking and register requirements and guidelines in a supporting circular
STCW amendments effective the same date added fatigue management as a mandatory training element for seafarers certified afterwards
A separate resolution added harassment-prevention competence to personal safety and social responsibilities for every certificate issued or revalidated after that date
Container loss reporting became mandatory under amendments effective 1 January 2026
A tanker inspection regime moved to a new question set applying to all inspections from late February 2026
A joint concentrated inspection campaign on cargo securing opened for a defined window in the autumn
That is one year, and it is not unusual. Industry commentary puts the number of maritime regulations updated in 2026 at more than a hundred and eighty. Each one that touches an inspection checklist, a certificate type, a competence requirement or a record format is a change request against a system somebody has to specify, build, test and deploy across a fleet.
If you bought it
The vendor absorbs regulatory change as a cost of doing business and spreads it across every customer. You receive it as an update. Whether the vendor does this well is a question worth asking in evaluation — but the obligation is theirs and the cost is amortised across a customer base rather than borne by your fleet alone.
If you built it
You have become a maritime regulatory tracking organisation as well as a shipping company. Somebody has to read the circulars, decide what they mean for the data model, specify the change, get it built, test it and deploy it — several times a year, permanently, with no end date and no economies of scale to spread it across.
The build never finishes, because the regulations never stop
Every other cost in a build estimate is bounded — development ends, infrastructure is a run rate, technical debt can in principle be paid down. Regulatory upkeep is the one line with no terminal date, and it is the one that generic build-versus-buy calculators omit entirely because most industries do not have it at this frequency.
The People Problem
A built system is only as durable as the small number of people who understand it, and shipping companies rarely have enough of them for that to be safe. Schedule a walkthrough and consider what happens to each option when a key person leaves.
The staffing requirement
Published analysis puts internal maintenance burden at typically one to three full-time staff with expertise in the specific stack, plus ongoing version upgrades. A three-person development team is costed at three hundred to six hundred thousand dollars a year fully loaded — described explicitly as the true cost of in-house development rather than the estimate on an agency pitch deck.
The concentration risk
With one or two maintainers, the system's continuity rests on individuals. The literature notes that a build with around five developers and a dedicated product manager resolves this. Below that threshold, a departure converts a working system into a liability nobody can safely modify — and legacy systems that are too expensive to maintain but too critical to switch off are a recognised category.
Why maritime makes it harder
The person maintaining a marine inspection system needs both software capability and enough domain knowledge to interpret what a regulatory change means for the data model. That combination is scarce, expensive, and portable — which means the person who has it is also the person most easily recruited away from a shipping company by a software company.
Where Build Estimates Go Wrong
The figures below come from published build-cost analysis and each represents a line that is routinely absent when a build is first proposed. Start a free trial and add every one of these to the build column before comparing.
Table 1: The Build Column, Complete
| Line | Reported figure | Duration | Why it is usually missed |
|---|---|---|---|
| Discovery and architecture | Around fifteen to forty thousand dollars over two to four weeks | One-time | Usually included, and usually the only line that is |
| Development and testing | Around eighty to three hundred and fifty thousand over twelve to twenty-four weeks for core functionality | One-time, in principle | Scoped to core functionality, which is not the same as the system you will need |
| Infrastructure during build | Two to five thousand monthly for hosting, authentication, monitoring and database | Throughout development | Twenty-four to sixty thousand over a twelve-month build, producing nothing yet |
| Ongoing maintenance | Fifteen to twenty-five percent of the initial build cost, annually | Permanent | Treated as a small percentage rather than as a permanent obligation |
| Running infrastructure | Two to eight thousand monthly for maintenance, enhancement and infrastructure combined | Permanent | A run rate that quietly matches a subscription within a few years |
| Integration work | Reported as underestimated constantly, at twenty to forty percent of implementation effort | One-time, then recurring on change | Scoped optimistically because the connecting systems are assumed stable |
| Maintenance staffing | One to three full-time staff with stack-specific expertise | Permanent | Absorbed into existing headcount on paper and not in practice |
| Regulatory upkeep | No published figure exists, because most industries do not carry this | Permanent, several times a year | Absent from every generic build-versus-buy model |
| Hidden costs generally | Typically doubling the effective cost over three years, with thirty to fifty percent surfacing in year one | Cumulative | Not knowable at decision time, which is precisely the problem |
Compare on five years
One published comparison in an adjacent sector put a five-year build total cost of ownership above eight hundred thousand dollars against a range of five to twenty-six thousand for a proven off-the-shelf product. The gap is not the development quote — it is everything in the table above.
The Honest Case for Building
This page is published by a software vendor and would be worthless if it only argued one side. The case for building has genuinely strengthened, and here it is without hedging. Book a walkthrough and weigh it against what follows.
Build costs are falling
Commentary in 2026 puts the reduction from AI-assisted development at sixty to eighty percent, and reports that seventy-eight percent of enterprise leaders plan to build more custom software this year. The barrier to entry for custom platforms is genuinely lower than it was, and dismissing that would be dishonest.
No per-seat cost, ever
Custom software carries no subscription that scales with users or vessels. For an operator whose fleet is growing quickly, or whose objective is to get every crew member using the system, a model with no marginal user cost has a real structural advantage.
The platform constraint is real
Organisations that default to buying without rigorous analysis frequently discover, at high cost, that the platform they chose now constrains the exact growth they invested in it to support. That is a genuine failure mode of the buy decision and it happens often enough to take seriously.
Where that argument lands for inspection specifically
All three points are strongest where the software is a differentiator. Inspection recording is not — it is a utility function performed against conventions that every operator in your segment shares, assessed by the same inspectors, to the same standard. The build case is strong for the thing that makes you distinctive, and weak for the thing that makes you compliant.
The Hybrid Nobody Mentions
The decision is frequently framed as binary and rarely is. There is a middle option that suits maritime particularly well. Start a free trial and test whether the platform can be extended rather than replaced.
Buy the regulated layer
Inspection templates, certificate tracking, defect workflows, class survey windows, drill records, evidence packs. Everything that changes when a convention changes, where the value is in somebody else absorbing that change and where you gain nothing from doing it differently to your competitors.
Build the distinctive layer
Whatever genuinely differentiates your operation — a chartering model, a commercial optimisation, a customer-facing capability, an analytical approach nobody else has. This is where the build literature's seventy-percent-unique test is actually satisfied.
Connect them
Which makes integration capability a primary evaluation criterion rather than a checkbox. Ask specifically whether API access is included at your tier or priced as a connector, what the export format is, and whether the data model is documented — because a hybrid strategy only works if the bought layer will let your built layer read from it.
Questions Before Either Decision
These separate a considered build from an optimistic one, and several will change a build estimate materially. Schedule a demo and ask the equivalent questions of any vendor you evaluate.
Table 2: Testing a Build Proposal, and a Buy One
| Area | Ask the build team | Ask the vendor | What a weak answer looks like |
|---|---|---|---|
| Regulatory change | Who reads the circulars, and how does a change reach production? | How did you handle the January 2026 changes, and how fast? | Either side treating regulatory change as an occasional event |
| Five-year cost | What is the total including maintenance, infrastructure and staffing? | What is the total including implementation, uplift and internal time? | A one-year figure from either party |
| Continuity | How many people could safely modify this system in two years? | What happens to our data if you are acquired or cease trading? | Confidence without a mechanism behind it |
| Offline capability | Have you built offline sync with conflict resolution before? | Can we test a full offline round with photographs today? | Offline described as straightforward, which it is not |
| Mobile reality | Who tests this in a machinery space, and how often? | Can a crew member time a job closure on deck during the demo? | Desktop-first thinking on either side |
| Integration | What is the effort to connect to our existing systems, honestly? | Is API access included at our tier, or priced separately? | Integration scoped optimistically, which it usually is |
| Failure mode | What happens if the lead developer leaves in month eight? | What happens if crews do not adopt it, and what does exit cost? | An answer that assumes the risk will not materialise |
| Scope discipline | What percentage of requirements are genuinely unique to us? | What do you not do, that we would have to solve elsewhere? | A build team that says everything is unique, or a vendor that says it does everything |
| The honest comparison | What would we lose by buying instead? | What kind of operator should not buy this? | Neither party being able to argue the other side credibly |
2026 BUILD ECONOMICS REALITY
The cost figures on this page come from general software development analysis rather than from maritime-specific studies. Build cost ranges, maintenance percentages, staffing costs and hidden-cost multipliers are drawn from published 2026 build-versus-buy research across sectors, and they vary enormously by region, complexity, team composition and whether development is in-house, agency or offshore. Treat them as a framework for building your own estimate rather than as a quotation. This page is published by a software vendor. That is a reason to read the case for building carefully rather than to discount it — the arguments in that section are genuine, the reduction in build costs from AI-assisted development is real, and the risk of a bought platform constraining growth is a documented failure mode of the buy decision. The regulatory examples are illustrative. Changes cited reflect a single recent period and are described at summary level; confirm the current position for each with the relevant instrument. Condition three is a genuine exclusion. Where classification, accreditation or air-gap requirements prohibit commercial software, no cost comparison is relevant.
Frequently Asked Questions
How much does building an inspection system actually cost?
Published 2026 analysis puts a well-scoped custom application for a mid-market operator at roughly fifteen to forty thousand dollars for discovery and architecture, eighty to three hundred and fifty thousand for twelve to twenty-four weeks of development and testing, and two to eight thousand monthly thereafter for maintenance, enhancement and infrastructure — a first-year total in the region of a hundred and fifty to four hundred thousand. The figure that matters more is ongoing: maintenance typically runs fifteen to twenty-five percent of the initial build cost every year, permanently, and hidden costs are reported to double the effective total across three years.
When does building genuinely make sense?
Three conditions, and they are narrow. First, you have a software team large enough to absorb the maintenance burden — the literature cites fifty-plus person internal teams, with roughly five developers and a dedicated product manager as the point at which continuity risk is solved. Second, the software is a genuine competitive differentiator rather than a utility, with the working test being that seventy percent or more of the features are unique to your business. Third, your regulatory environment prohibits commercial software entirely, as with classified or air-gapped work. For most commercial fleet operators the first two fail and the third does not apply.
What makes maritime different from a generic build decision?
Regulatory drift, and it appears in no generic build-versus-buy calculator. In a single recent year, lifting appliance requirements entered force under SOLAS with new certification and marking obligations, STCW amendments added a mandatory training element, a separate resolution changed a competence requirement for newly issued certificates, container loss reporting became mandatory, a tanker inspection regime moved to a new question set, and a concentrated inspection campaign opened on cargo securing. Industry commentary puts maritime regulations updated in 2026 at more than a hundred and eighty. Every one touching a checklist, certificate type or record format is a permanent change request against a system somebody has to maintain.
Is the build case stronger now that AI assists development?
Yes, and it would be dishonest to claim otherwise. Commentary in 2026 puts the reduction in build costs from AI-assisted development at sixty to eighty percent, with seventy-eight percent of enterprise leaders planning to build more custom software this year. Custom software also carries no per-seat subscription, which matters for a growing fleet. The qualification is where that argument applies most strongly — to software that differentiates you. Cheaper development makes it more attractive to build the thing nobody else has; it does not change the calculus for a utility function performed against the same conventions as every competitor, where the ongoing regulatory and maintenance burden is the dominant cost rather than the initial build.
What is the biggest risk in a small in-house build?
Concentration of knowledge. Published analysis puts internal maintenance burden at typically one to three full-time staff with expertise in the specific stack, and notes that a build with around five developers and a dedicated product manager resolves the continuity problem. Below that threshold the system depends on individuals, and a departure converts a working platform into something nobody can safely modify — the recognised category of legacy applications too expensive to maintain and too critical to switch off. Maritime sharpens this because the maintainer needs both software capability and enough domain knowledge to translate a regulatory change into a data model change, which is a scarce and portable combination.
Is there a middle option?
Yes, and it suits maritime well. Buy the regulated layer — inspection templates, certificate tracking, defect workflows, survey windows, evidence packs — where the value lies in somebody else absorbing regulatory change and where doing it differently to competitors gains you nothing. Build the layer that genuinely differentiates your operation, which is where the seventy-percent-unique test is actually satisfied. That makes integration capability a primary evaluation criterion rather than a checkbox: ask whether API access is included at your tier or priced as a connector, what the export format is, and whether the data model is documented, because a hybrid only works if the bought layer will let the built layer read from it.
Is inspection recording what makes you different from your competitors?
If the answer is no, the build literature has already given you the decision: utility functions go to off-the-shelf so the team can work on what does differentiate you. If the answer is yes — or if classification requirements rule out commercial software entirely — build it, and budget for maintenance at fifteen to twenty-five percent annually, one to three specialist staff, and a regulatory tracking function with no end date.
.png)
.png)
