Code & architecture
Structure, maintainability, test discipline, technical debt and whether the system makes engineering sense beyond the demo.
Buy-side technical & evidence due diligence
Know what you are buying before the seller walks away.
Due Diligence is the AI Verdict pointed at a target company. Before you inherit the code, systems, dependencies or document-backed revenue, establish what is actually there.
For software-led and evidence-heavy businesses, typically A$100K to A$5M enterprise value. The code, infrastructure and operating reality examined before they become yours.
A typical focus, not an eligibility rule. If the available evidence cannot support useful diligence, we say so before you commit.
Enterprise value focusA$100K to A$5M
Side of the tableBuy-side only
Scope and feeFixed, agreed first
WhereRemote, cross-border
The decision
A polished demo is not evidence of a sound software business.
Software has never been faster to build or easier to make look finished. That is good for builders. It creates a different problem for buyers.
A product can have customers, revenue and an impressive interface while carrying weak architecture, fragile dependencies, superficial tests, undocumented infrastructure, security exposure or a system only the seller really understands.
Technical diligence asks the question underneath the listing, the demo and the revenue chart: what are you actually inheriting?
The software does not have to be perfect.
It does have to be understood well enough for you to price the risk, ask the right questions and decide whether to proceed.
What gets examined
The asset underneath the business.
01
02
Infrastructure & security
Hosting, deployment, access boundaries, secrets, backups, operational dependencies and material security indicators.
03
Dependencies & ownership
Third-party services, libraries, accounts and technical dependencies that may affect cost, continuity or transferability.
04
Operational resilience
What keeps the product running, how it fails, what is monitored and whether another competent operator could take over.
05
Key-person risk
Where knowledge lives in the seller rather than the system, documentation or team, and what happens when that person leaves.
06
Cost to own
Technical liabilities and operating realities that can change the economics after acquisition, separated from cosmetic engineering preferences.
Evidence-backed value
When the price depends on records, test the records.
Not every acquisition derives its value from proprietary code. Some businesses are bought because a portfolio of agreements, accounts or recurring fees is represented to produce a particular income stream.
Where the relevant source material is available, diligence can reconcile the operational record against the underlying documents and surface exceptions before the buyer pays for them. That may include missing source documents, duplicate or stale records, inconsistent recorded commercial fields, unsupported entries, concentration, or other discrepancies that change what deserves further investigation.
We establish what the supplied evidence supports.
We do not turn document analysis into legal, accounting or valuation opinions. Questions of enforceability, legal transfer, regulatory compliance, tax treatment, accounting treatment or valuation remain with the appropriate adviser.
Illustrative reconciliation
Do the records underneath the price reconcile?
For an evidence-heavy acquisition, the useful output is an exception register tied back to source, not a claim that automation has replaced professional judgment.
Represented
412 revenue-producing records represented by the seller.
Supported
371 records matched to supplied source material. The operational record and its corresponding source document were located and reconciled against the agreed fields.
Investigate
28 records contain documentary exceptions. One or more agreed fields do not reconcile cleanly and require review before reliance.
Unverified
13 records have no corresponding source document in the supplied set. The commercial representation may still be correct. The supplied evidence did not establish it.
-
What the register carries
Claimed revenue-producing records compared with supplied source documents. Missing, duplicate, stale or inconsistent records surfaced. Recorded commercial terms compared with documentary evidence where appropriate. Concentration and exception patterns quantified.
-
Where it stops
Material questions are isolated for the buyer, accountant, lawyer or other specialist. Every conclusion is bounded by what could actually be verified from the material supplied.
Document-heavy diligence
Large source sets are useful only if the finding can still be traced back to the record.
For document-heavy diligence, Lumen & Lever can use its own evidence-processing technology to structure, cross-reference and trace large source sets while preserving the connection between a finding and the material supporting it.
The technology is not the product. The product is a buyer-readable evidence record: what reconciled, what did not, what remains unknown, and which exceptions are material enough to investigate before completion.
AI-built software
AI can make software look mature before the engineering underneath is mature.
AI-assisted development is not a red flag by itself. Poor engineering is.
Where AI has been used heavily, the review looks past whether the application appears to work today. It examines the discipline around what was generated: architectural coherence, testing, security boundaries, dependency hygiene, maintainability and whether the system can be understood and operated after acquisition.
The relevant question is not whether AI was used. It is whether the speed of generation outran the engineering required to make this a durable asset.
- Coherence
Whether the generated parts form a system or a collection of working fragments.
- Testing
What the tests actually cover, and what they only appear to cover.
- Boundaries
Where secrets, permissions and untrusted input are handled, and where they are not.
- Operability
Whether a competent engineer who did not write it can run it, change it and fix it.
The output
A decision document, not an engineer’s bug list.
You do not need three hundred observations of equal weight. You need to know which findings matter to the transaction, what supports them, what remains unanswered and what should happen next.
Material
Production deployment depends on a seller-owned account
Transferability risk
Confirm ownership transfer and credentials before completion.
Investigate
Automated tests cover the happy path, not payment failure states
Reliability exposure
Request incident history and the payment-recovery procedure.
Context
Framework version is behind current release
Not independently material to the deal
Recorded for post-acquisition maintenance planning.
Two points of entry
Spend diligence money in proportion to how close you are to the deal.
-
Early red-flag assessment
For a buyer who wants to know whether the technical story deserves deeper diligence before more time and money are committed. Narrow scope, fast turnaround, focused on material reasons to stop, question or continue. From A$1,500, quoted against the access available and the asset.
-
Full technical and evidence diligence
For a live acquisition where access to the repository, infrastructure and supporting material is available. Scope is agreed against the asset and the transaction before work begins. Quoted after a short scoping call. Scope depends more on technical complexity and access than on enterprise value.
-
How we are paid
Fixed scope. Fixed fee. No success fee, and no incentive for the deal to complete.
How it runs
Three steps. No theatre.
01
Scope the asset
Thirty minutes. Deal stage, software type, available access and the decision you need to make. If the evidence available cannot support useful diligence, we say so.
02
Examine the evidence
Repository, architecture, infrastructure, operational records and supporting source material examined against the agreed scope. Material unknowns stay unknown rather than being filled with confidence.
03
Get the verdict
A buyer-readable report with findings, evidence, unanswered questions and transaction-relevant risks. You decide what the evidence means for the deal.
Who signs it
The name on the verdict.
Lumen & Lever is led by Lee Powell: Oxford-trained software engineer, roughly thirty years across enterprise architecture and production delivery in banking, insurance, exchange, healthcare and government. He built IBM's first online retail platform and document software used by more than a million writers worldwide. The same discipline that ran a hundred-million-dollar post-acquisition banking integrationa now examines AI positions and signs verdicts on them.
Founder experience, not a client list
Lloyds International · Commonwealth Bank of Australia · Deutsche Bank · ASX · IBM · Zurich Insurance · GlaxoSmithKline · ASIC · Australian Government Defence · NSW Health · Westpac
These are organisations and sectors from Lee Powell's prior career unless separately named in a Lumen & Lever case record. Confirmed Lumen & Lever outcomes are published separately only when permission exists.
Based in Melbourne. In person or remote, anywhere in Australia, with travel at cost outside Melbourne.
Sources
a. Post-acquisition integration programme, Commonwealth Bank of Australia.
Next step
Before you inherit the software, establish what is actually there.
Send the listing or a short description of the deal. We will tell you whether technical diligence is warranted, what access would be required and what the scope should be. Write to hello@lumenandlever.com or use the form.