Skip to main content

Technical due diligence

Find out what you're actually buying, before you sign

The pitch says the platform is scalable, the code is clean and the team is strong. Sometimes it is. Technical due diligence is a senior engineer reading the code, the infrastructure, the security posture and the running costs, and telling you in plain language what's true, what it will cost to fix, and what you should ask before the money moves.

Every layer of the stack read in turn, and the findings rated so a board can see the two things that matter without reading the forty that don't.

In short

PixelApps carries out technical due diligence for Australian investors, acquirers and boards: a senior engineer reviews the code, architecture, infrastructure, security, running costs and team of a software business or product, and delivers a written report with risk ratings, remediation cost estimates and the questions to ask. Fixed price, agreed before we start, usually inside two weeks of access.

This is for you if

  • Investors and angels putting money into a software business and wanting a technical view they can defend
  • Acquirers buying a business whose value sits in a platform, a codebase or a data asset
  • Boards and directors who need an independent read on the technology they're responsible for
  • Business owners about to commit to a large build, a platform migration or a long vendor contract
  • Founders preparing for a raise who want to find the problems before the investor's engineer does

It isn't if

  • The owner of an app that's broken or stalled. That's a rescue audit, it costs $495, and it's on the fix pages.
  • A large engineering organisation with hundreds of services. You want a specialist due diligence firm with a team, and we'll say so.
  • A deal that needs a rubber stamp. If the report has to say the right thing, we're the wrong firm.

What you get

  1. A summary a board can read in five minutes

    The verdict, the two or three findings that affect the deal, and what they'd cost to put right. Written for the people deciding, not for the engineers.

  2. A risk register with severity and cost

    Every finding rated by likelihood and impact, with an estimate of the effort to remediate, so problems can be priced into the deal rather than argued about afterwards.

  3. Architecture and scalability, tested against the plan

    Whether the system will carry the growth in the business plan, where it breaks first, and what it costs to get past that point. Not a theoretical opinion: read against the actual code and traffic.

  4. Security and data handling

    Authentication, access control, secrets, dependencies, backups, and how customer data is stored and shared. The findings that turn into breaches, and the ones that turn into Privacy Act problems.

  5. Ownership, licensing and running costs

    Who owns the code, what's under which licence, what the platform costs a month and how that grows. The commercial questions engineers usually skip.

  6. Team and key-person risk

    How much lives in one head, how work gets shipped, and whether the team you're buying is the team that built it. Plus the questions to ask them, and what a good answer sounds like.

Three ways to engage

The cadence is agreed up front and can change with a month's notice. The fee is fixed in writing on the first call.

Pre-investment

One to two weeks from access

For angels, funds and family offices. A technical view sized to the cheque, from a half-day read for a small round to a full review for a lead position.

Acquisition

Two to three weeks from access

For buyers of a business whose value is in its platform. Deeper on ownership, licensing, data, running costs and what it takes to keep the thing running after the founders leave.

Pre-commitment review

About a week

For an owner about to sign a large build, a migration or a long vendor contract. The proposal, the architecture and the quote read by someone with no stake in the answer.

The first ninety days

  1. 01

    The first call

    What the deal is, what's being claimed, what you're worried about and when you need the answer. We scope the review to the decision and give you a fixed price.

  2. 02

    NDA and access

    A mutual NDA, then read access to repositories, infrastructure, documentation and, where useful, an hour with the technical lead. We work on copies and change nothing.

  3. 03

    The review

    A senior engineer reads the code, the architecture and the accounts, runs the checks, and tests the claims in the deck against what's actually there. Usually one to two weeks.

  4. 04

    The report, and a call with the deal team

    A written report, a walk-through with whoever is deciding, and answers to the follow-up questions. If you want the findings fixed, the report says what that costs and you can take it anywhere.

Due diligence, the rescue audit, or a fractional CTO

Three reviews we offer, for three different questions. The right one depends on who's asking and what they're about to do.

CriteriaTechnical due diligenceRescue auditFractional CTO
Who it's forSomeone about to put money behind softwareThe owner of an app that's broken or stalledA company that needs ongoing technical leadership
The questionIs it what they say it is, and what will it cost me?What's wrong, and what will it take to fix?What should we do next, and who should do it?
What you getA board-ready report with risk ratings and remediation costsA written report on code, database and hostingA standing engagement, a roadmap, decisions made
TimeOne to three weeks3 business daysOngoing, month to month
PriceFixed, quoted on the first call$495 fixedFixed monthly fee

When we're not the answer

If the deal is small and the product is a marketing website, an afternoon with the questions in our buying guide will do and we'd be overkill. If the target runs hundreds of services with a large engineering team, you want a specialist firm with a team of reviewers, not a studio. And we won't do the review and then pitch to rebuild what we found: the report says what remediation costs, and you can take it to anyone.

Start with a conversation

An hour on where you are and what's in front of you. You'll leave with a straight answer on whether this is the right shape, and the monthly figure if it is.

Email

jayson@pixelapps.com.au

Location

Macedon Ranges, Victoria

Serving clients across Australia

Only if a quick call would be easier than email.

What kind of help?(optional)
Rough monthly budget(optional)

A range is enough. It helps us recommend the right approach, not the biggest one.

We reply within 24 hours. No obligation, and we never share your details.

Common questions

Code quality and maintainability, architecture and scalability against the business plan, security and data handling, infrastructure and its monthly cost, ownership and licensing of everything in the codebase, and the team: how work ships and how much depends on one person. Each area gets findings, a severity and a remediation estimate.

Usually one to two weeks from getting access, up to three for an acquisition. The price is fixed and sized to the decision: a small round needs less than a lead position or a purchase. We quote on the first call, in writing, before starting.

Read access to the repositories, the hosting and infrastructure accounts, any documentation, and ideally an hour with the technical lead. Everything happens under a mutual NDA, we work on read-only copies, and we change nothing.

The rescue audit is for the owner of an app that's broken or stalled and wants to know what it takes to fix. Due diligence is for the person about to put money behind software they don't own yet, and it's written for a deal: risk ratings, remediation costs, and the questions to ask before signing.

If you ask, yes, through the development team or a fractional CTO engagement. But the report is written to stand on its own, with remediation estimates any competent firm can work from, and we'd rather you compared quotes than felt obliged. A review that leads to its own upsell isn't independent.

Yes, and it's increasingly what we're asked to look at. AI-built products have a recognisable set of problems, mostly around security rules, secrets and the parts that were never finished, and we've written about them on the fix pages. The review says which of those apply and what it costs to make the product something you'd want to own.