Application development: the four decisions that set the cost
Feature lists are a poor predictor of what an application costs. Four decisions, all made in the first fortnight, account for most of the variance.
Insights
Thoughts on AI, data engineering, custom software, and growth.
What separates a useful audit from an expensive formality
Both kinds of audit produce a document on the same schedule for a similar fee. Six practices separate the one that changes something from the one that does not.
Being audited: what to expect and how to prepare
Most of the cost of being audited is self-inflicted: preparing the wrong things, answering more than was asked, and treating findings as accusations.
Writing an audit plan that decides something
A plan listing systems produces a survey. A plan listing questions produces answers. Five components, and the two that most plans omit entirely.
The audit process, and where each stage goes wrong
Five stages, and each one has a characteristic failure. Knowing which stage you are in tells you what a finding at that point is actually worth.
How to become a CTO, and what the job turns out to be
Most advice on becoming a CTO describes a promotion track. The job is three different jobs, and the skills that get you the title are rarely the ones that keep it working.
Buy and extend: the option most decisions actually land on
Build or buy is a false binary. Most companies end up buying the commodity and building the differentiator, and the hard part is drawing that line in the right place.
When an off-the-shelf product fights the way you work
Off-the-shelf products carry a model of how the work is done. When that model disagrees with yours, the mismatch shows up as workarounds long before anyone calls it a problem.
Buying software you will still be living with in five years
Software evaluations test features, which is the part that changes. The four questions that predict whether you will still be happy in five years are rarely on the scorecard.
The three different jobs that share the title CTO
Hiring a CTO goes wrong when nobody agreed which of three jobs the title means. The builder, the scaler and the representative are different people.
The records compliance actually asks you to keep
Compliance is mostly a records problem. Six categories cover almost every request, and the ones that hurt are the two you cannot produce after the fact.
Cross-platform apps: what the shared layer should actually contain
The cross-platform question is usually framed as one framework against another. The more useful question is which layer you share, and my answer is the core.
The point where a spreadsheet stops being enough
Spreadsheets fail on a schedule you can predict. Four signals mark the point where custom business software gets cheaper, and three are about people.
When custom software is the wrong answer
Most people who ask for custom software should buy something instead. Here is the test I use to work out which case you are in, including the three conditions that make building genuinely cheaper.
A technical due diligence checklist that is not a formality
Most technical checklists test whether artifacts exist. The useful ones test whether the artifacts are true, which is a different exercise and produces different findings.
The diligence process, stage by stage, with real timings
Diligence runs in four stages and the timeline is set by access, not by analysis. Knowing which stage you are in tells you what a finding at that point actually means.
What the word enterprise actually adds to a build
Enterprise software is not bigger software. It is software where the buyer is not the user, and that single fact adds a specific, predictable list of work that nobody enjoys estimating.
Where the fractional executive model works, and where it fails
The fractional model works when the job is judgement-dense and low-frequency. It fails when the job is availability. Most disappointments are that mismatch.
Security you can evidence, rather than security you assert
Nobody can demonstrate that a system is secure. What can be demonstrated is that specific controls were operating, which is a narrower claim and the only honest one available.
You cannot audit an information system nobody has listed
Every audit, security programme and compliance exercise starts with an inventory, and nearly every one discovers the inventory is wrong. Here is why, and what a usable one contains.
What an IT auditor does, and what independence requires
The job is not finding bugs. It is establishing what can be evidenced, which makes independence the load-bearing part — and the part most often quietly compromised.
Internal audit of technology: what it catches and what it cannot
An internal function has context an outsider cannot buy and a structural weakness an outsider does not have. The reporting line is what decides which one dominates.
What an IT audit actually checks, item by item
An IT audit checks five things, and only one of them is about software. Here is what each is testing and what a weak answer looks like.
What a compliance audit proves, and what it does not
A compliance audit proves you operated stated controls over a period. That is narrower than secure, broader than paperwork, and the difference decides whether the exercise is worth anything.
IT due diligence: the risks that are not in the codebase
Code review misses the risks that most often delay a transaction: licences, account ownership, vendor contracts and data residency. None of them is visible in a repository.
Product development is not project delivery
A project ends when the scope is delivered. A product ends when nobody uses it any more. That single difference decides your architecture, your budget shape, and who you should hire.
Protecting sensitive data starts with knowing where the copies are
The security posture of sensitive data is the posture of its least protected copy, and most organisations have copies they have not counted.
Outsourced, fractional, interim: which arrangement you need
Outsourced, fractional, interim and virtual CTO describe four different arrangements with different failure modes. Picking by price rather than by shape is how engagements go wrong.
What building software actually commits you to
The build decision is usually costed as a project. It is a subscription you pay in engineering attention, and the five obligations it creates outlast the people who agreed to them.
The development process I run, and where it has failed
Every studio publishes a process diagram and none of them publish the failure modes. This is the sequence I actually run, what each stage is for, and the three places it has broken.
Auditing one system end to end, rather than everything shallowly
A shallow pass over twenty systems finds less than a deep pass over the one that matters. Depth beats breadth when the goal is a decision rather than a register.
Tech DD: what the term means and what it involves
Tech DD appeared in your term sheet and nobody explained it. Here is what it is, who asks for it, what it costs in time, and what it is not.
What a technical due diligence report actually contains
The report is the only part of the exercise anyone keeps. Four sections, three readers with different needs, and one convention that decides whether it survives a negotiation.
What acquirers are really assessing in a technology review
An acquirer is not grading the code. They are pricing three things: what it costs to integrate, what it costs to keep running, and how much of the value walks out with the team.