Ask for an artifact, not an assessment
Diligence is over, the deal is done, and the operating partner now has to form a view of a technology function using a language they do not speak, from people who are simultaneously being assessed by them. That combination produces a predictable output: fluent, reassuring, unfalsifiable answers. The architecture is modern. The team is strong. There is some technical debt but it is under control. None of those sentences is a lie and none of them can be checked, which makes them worthless as inputs to a decision about money.
The fix is a habit rather than an expertise. For every question you ask, decide in advance what document, log or list a truthful answer would produce, and ask for that instead. You do not need to be able to read the code. You need to be able to notice that a thing which should exist does not.
Five questions and the artifact each one produces
These five cover most of what threatens a value creation plan in the first year. Each is answerable by a competent team in under a day, and the speed of the answer is itself information.
| Ask this | The artifact | What a weak answer sounds like |
|---|---|---|
| How long from a developer finishing a change to a customer using it? | A list of the last thirty releases with dates and what was in each | “We ship continuously.” The list shows four releases in six months, two of them rollbacks |
| If your best engineer resigned this morning, what would we not be able to change? | A named systems list with a named second person for each, checked against who has actually committed code to it this year | “Everyone can work on anything.” Also: a long pause |
| What does it cost to run, and what drives the number? | Three months of infrastructure and vendor bills broken down by service, plus cost per active customer | “Hosting is about a hundred thousand a year.” No breakdown, no trend, no per-customer figure |
| Show me the last three times something broke for customers. | Three written accounts with dates, duration, cause and what changed afterwards | “We’ve been very stable.” Then a story that turns out to be from a different company |
| What have we promised customers that is not built? | A list of contractual commitments and dated promises, reconciled against the roadmap | “Sales manages that.” Nobody owns the reconciliation, which means it has never been done |
Two notes on how to use them. First, the absence of an artifact is the finding, not a reason to ask again more politely. A team with no written record of its own outages does not have a bad memory; it has no practice of learning from them, and that predicts the next twelve months better than any architecture diagram. Second, ask the same five questions of every company in the portfolio and keep the answers side by side. The comparison across ten businesses tells you more than any single answer does, and it costs nothing extra.
You are probably here because
- The roadmap slipped a quarter and the explanation was technical enough that nobody pushed back
- Gross margin is drifting down and nobody can tell you which line is doing it
- An add-on closed and the integration estimate has doubled twice
- One engineer is named in every conversation about every system
The five questions above surface the first and the last. The margin section covers the second and the add-on section the third.
Technical debt is not a moral category. Price it.
Every engineering team will tell you there is technical debt, because there always is, and the phrase has become a way of asking for money without naming a return. The useful reframing is financial: debt is only debt if it has an interest payment. So ask what the payment is, in units you can act on.
Debt that slows change. Ask how much longer a typical feature takes because of it, and how many features a year go through that area. If a two-week change takes five weeks and it happens six times a year, the payment is roughly eighteen engineer-weeks annually. Now the remediation has a payback period and can be compared with anything else.
Debt that creates risk. An unsupported dependency, a component only one person understands, an unpatched system in the path of customer data, a database with no tested restore. The payment here is not time but exposure, and it should be expressed as what happens if it fires and how likely that is this year.
Debt that is only aesthetic. Code an engineer dislikes in a part of the system nobody is changing. There is no payment. Rewriting it is discretionary spending dressed as maintenance, and a team that keeps proposing it is telling you something about its priorities.
The sorting question that does most of the work: if we never touched this area again, what would go wrong? If the honest answer is nothing, it is the third kind, and it can wait indefinitely.
What actually threatens a value creation plan, as we rank it
Editorial weighting from our own review practice, shown to explain what we look at first. Not a measured statistic.
The bottom row is there deliberately. An old but well-understood stack maintained by people who know it is a far better position than a modern one nobody has operated under load, and stack modernisation is the most common expensive project with the least connection to any number in the model.
The margin question that always arrives late
Software gross margin is an engineering output as much as a finance one, and in most mid-market portfolio companies nobody owns the connection between the two. Cost of revenue is hosting, third-party services, data and content licences, and the support engineering that keeps customers running. The question to ask, monthly and by name, is cost per active customer, trended over the last twelve months. It is knowable in a week and it is very often not known.
Three things move it and each has a different remedy. A handful of large customers consuming disproportionate resource, which is a pricing problem, not an engineering one. Infrastructure sized for a peak that no longer happens, which is a housekeeping problem worth a few weeks. And a per-transaction third-party cost embedded in the product, which is a design problem and the one to watch hardest.
That last one deserves attention now for a specific reason. Traditional software has near-zero marginal cost per use, which is where the whole margin profile of the asset class comes from. A feature that calls a model on every use does not: it has a real, variable cost per request that grows exactly with the usage you are trying to grow. If a portfolio company has added such a feature, ask two things. What does it cost per customer per month at today's usage, and what happens to that number if usage triples. If the pricing is a flat seat fee and the cost is per use, growth compresses margin, and it will show up in the quarter after the launch everyone is pleased about.
Ask for cost per active customer per month, trended, by name
Not total infrastructure spend, which hides everything. A twelve-month trend of cost per active customer, with the top ten consumers broken out, tells you whether margin is drifting, whether a single account is unprofitable, and whether a new feature has changed the shape of the business. If the answer takes a month to produce, that is itself the finding: nobody has been watching a line that runs straight into gross margin.
Add-ons: the integration cost is decided before you sign
Integration estimates for bolt-on acquisitions are wrong in a consistent direction, and the reason is that the estimate is made about the product while the cost is incurred on the customer.
Two honest shapes exist. Leave the systems separate, run the acquired business as it is, and take only the commercial synergies; this is cheap, fast, and delivers no product synergy, and it is the right answer more often than it is chosen. Or genuinely merge, in which case the expensive work is not the feature overlap. It is identity, billing, permissions and the customer record: one login, one invoice, one place a customer's data lives, one support team that can see both. That work is invisible in a product demo and it is most of the money.
The number that predicts the cost better than any other is how many systems hold a copy of the customer record across both businesses, and whether any two of them agree on what a customer is. Ask for the count before the estimate. Two companies each with four such systems is not an eight-system problem; it is a sixteen-pair reconciliation problem, and that is the shape of the surprise.
Questions that sound sharp and discriminate nothing
- “Are you in the cloud?” — almost everyone is, and it says nothing about cost, reliability or speed. Ask what it costs per customer instead
- “Do you use microservices?” — an architectural preference with good and bad versions. Ask how long a change takes to reach a customer
- “What is your test coverage?” — a number that is easy to inflate. Ask what broke last, and whether a test would have caught it
- “Are you using AI?” — the answer is yes everywhere. Ask which customer decision it changes and what it costs per use
- “How many engineers do you have?” — headcount is an input. Ask what shipped in the last two quarters and who used it
- “Is the platform scalable?” — unfalsifiable. Ask what happens at three times current load and how they know
- “Is our data secure?” — nobody answers no. Ask which customer contracts contain security obligations and who checked they are met
What the first hundred days should produce
Post-close technology review
Step six is a restraint and it is the hardest one. The instinct after a close is to reorganise, and the technology function is the most tempting target because its problems are legible in a report. Almost nothing in engineering improves in the first hundred days, and a reorganisation in month two removes the people who could have told you what the last three years were actually about. Measure first, and change when you know which change has a payment attached.
Key-person risk is the one to act on immediately
Of everything on the list, engineer concentration is the item most likely to cost real money and the one with the shortest window for a cheap fix. In a company under about fifty engineers it is normal for one or two people to be the only ones who genuinely understand the systems that make the money. That is not mismanagement; it is what happens when a founding team builds something quickly and it works.
It becomes a problem at exactly the moment ownership changes, because that is when those people re-examine their situation. The remedies are ordinary and they take months, so they have to start early: a second person actually working in each critical system rather than nominally assigned to it, written operational documentation produced by someone new following it rather than by the expert writing it down, and retention arrangements that are decided before anyone resigns rather than negotiated afterwards.
A cheap, honest test. Pick the system that generates the most revenue and ask who deployed a change to it in the last ninety days. If it is one name, you have your answer, and no assurance about documentation or cross-training changes it.
Send the artifacts and we will tell you what they say.
The release list, the last three incident write-ups, three months of infrastructure bills, and the roadmap. Email contact@precisionfederal.com. You get back a written read: what is genuinely at risk, what is being asked for that has no payment attached, and the two things we would do first. One business day, no charge.
contact@precisionfederal.comBefore the next board meeting
- The five artifacts requested, with every missing one written down as a finding
- A key-person map built from who has actually changed each system this year
- Customer commitments reconciled against the roadmap by a named owner
- Cost per active customer per month, trended, with the top ten consumers broken out
- Any per-use third-party cost identified and compared against how the product is priced
- Technical debt priced in engineer-weeks or exposure, with anything unpriced deferred
- Security obligations in customer contracts listed, with evidence they are met
- For any add-on: a count of systems holding a customer record on both sides
Bottom line
Ask for artifacts rather than assessments, because a missing document is a finding a non-engineer can act on and a reassuring sentence is not. Price technical debt before funding it, and decline the portion that has no interest payment. Watch cost per active customer monthly, especially where a feature carries a per-use cost that grows with the usage the plan depends on. Move early on key-person concentration, because it is the risk with the shortest cheap-fix window and the one most likely to fire in the first year. And resist reorganising the engineering function before you can name which change has a return attached to it.
Frequently asked questions
Decide before you ask what document a truthful answer would produce, then ask for the document. Release lists, incident write-ups, infrastructure bills and commit histories are all readable by a non-engineer, and a missing one is a finding you can act on without understanding any code. Fluency is not evidence; artifacts are.
Almost never, and only where the debt has a named payment: features taking measurably longer, or a genuine risk with a probability and a consequence attached. A rewrite proposed because the stack is old, or because the team would enjoy a different one, spends a year of capacity to reach the same functionality. Rebuild the parts that are actually changing, and leave the rest alone.
Benchmarks as a percentage of revenue are weak because they average over businesses with different products and margins. A better question is what shipped in the last two quarters, whether customers used it, and what the run cost per customer did over the same period. Two companies at the same spend ratio can be in completely different positions, and only the output tells you which.
The marginal cost of use is no longer near zero. A model call has a real per-request cost, so a flat-fee product with a per-use cost inside it compresses margin as usage grows. Ask for cost per active customer for that feature, ask what happens at three times usage, and check that the pricing structure matches the cost structure. Also ask what the feature is measured against, because features with no evaluation cannot be shown to work and cannot be safely changed.
When the artifacts are missing and you need to know whether that reflects a young team or a real problem, when an integration estimate has moved twice, or when a large capital request rests on a technical argument nobody in the room can test. The output should be a written finding with evidence attached, not a presentation, and it should be scoped in weeks rather than months.