/ Service — First look

It's slow. Buy the diagnosis before the fix.

Slow posting. Lock timeouts. Deadlocks. A report that used to return in seconds. A month-end close that now runs all night. The expensive mistake is buying a fix for the wrong one of those. This is the smallest thing you can pay us for: one database, read only, diagnosis only — a ranked answer to what is actually costing you the time, and a short list of what to do first. One limit, said here rather than in the small print: a read can show you that lock waits are hurting you, but pinning them to a particular posting routine needs a live capture, and that is engineering work rather than a read. It ends with a document and a conversation, and it is deliberately cheaper than deciding to act.

Why this step exists at all

Until now the first paid thing on this site was a full health audit on one database. It is a good piece of work, and it is a bigger decision than the question most people arrive with. Somebody whose month-end close has doubled does not yet want a project. They want to know what is wrong, from someone who will show their working, and they want to find that out without starting an approval chain.

So there is now a smaller step underneath it. The distinction is not depth of care — the collection is the same read-only bundle and the findings are ranked the same way. The distinction is scope and what happens next: a first look tells you what is wrong and stops. Everything past that point is a separate decision you make with the findings already in hand, rather than one you make in order to get them.

And the honest reason to offer it: it is easier to say yes to. That is the entire design intent, and pretending otherwise would be silly. A cheap, finite, clearly-bounded first step is how a practice with no client references earns the right to a second conversation: the artifact is the proof, and what it is proof about is your own database rather than somebody else's.

What you get

  1. /01

    A ranked list, with the evidence under each line

    Every finding carries the collected measurement it came from, so your own DBA can check the reasoning rather than take the ranking on faith. Findings are ordered by what is costing you time, not by what is easy to write up.

  2. /02

    A short “do this first” list

    The few highest-leverage items, separated from the long tail. Most estates have two or three findings that matter and a great many that do not, and the value of a first look is being told which is which.

  3. /03

    A thirty-minute readout

    A live walk through the findings with the engineer who read them, so you can ask the follow-up question that decides whether there is a project here at all — including, quite often, the answer that there is not.

What it does not include

This list is the point of the rung, not the small print. A cheap first step that quietly implies fixing is a refund conversation waiting to happen, so the boundary is stated plainly and it is the same boundary in the proposal.

  • No remediation. Nothing is changed, tuned, indexed, reconfigured or deployed. This rung ends with a document and a conversation.
  • No second database, and no estate-wide sweep. One database is the whole scope. A fleet is a different engagement.
  • No re-measurement. Proving an improvement means collecting again after the work, and there is no work in this rung to measure the effect of.
  • No agent, and no connection to your database from our side. You run a read-only bundle you have read, and hand back the output.
  • No lock-contention attribution. Instance-wide counters since the last restart cannot be pinned to a specific posting routine without a live capture, which is engineering work rather than a read.

One further limit worth knowing before you buy, because it is the kind of thing a vendor normally leaves for you to discover. The scoring engine behind the ranked findings is deterministic and its evidence is auditable, but it has been calibrated against far more synthetic estates than real ones — so a first look is read and sanity-checked by the engineer before it reaches you, and the engineer's read is the part you are buying. A score is a way of ordering findings. It is not a verdict, and this page will not pretend it is one.

Where this sits

This is the database-performance path, smallest first — five rungs, each a separate decision, and nothing here commits you to the one above it. It is not the whole catalogue: migration and posture work runs on its own track, and how we work lays every engagement shape out side by side. The point of showing this much of it is that you can see where a first look leads before you buy one, rather than learning the shape of the engagement after you are inside it.

  1. /01

    Free 30-minute discovery call

    You describe what is slow and when it started. We say whether this is something we can read usefully, and whether it is worth paying anything at all. Some calls end here and that is a fine outcome. Book the call.

  2. /02

    A first look at one database

    This page. The smallest paid step: read-only collection, ranked findings, a short shortlist, a thirty-minute readout. Diagnosis only. Fixed fee, and it is credited against the next rung if you take it.

  3. /03

    The Database Health Audit

    The fuller read on one database, with a senior engineer's interpretation pass over the findings, a longer readout, and a remediation shortlist scoped tightly enough to quote a sprint from. Larger than a first look, and a bigger decision. What the health audit covers.

  4. /04

    The tuning work itself

    A senior engineer does the work the assessment sized, and the same collection runs again afterwards so the result is measured rather than asserted. How a tuning engagement runs.

  5. /05

    Ongoing

    Where a database matters enough that somebody should be watching it between incidents, the engagement becomes a standing one. This is the rung the earlier ones exist to reach — the others are episodic by nature, and this one is not. How a standing arrangement is scoped.

The rungs are episodic by design except the last one. Tuning is work you do once and it stays done, so anyone selling it as a subscription is selling you something else under its name. Where a standing arrangement is genuinely the right answer, it is because somebody should be watching a database between incidents — not because the tuning needs redoing every month.

Dynamics NAV and Business Central — on-premises only

A first look reads the SQL Server database underneath the ERP, so it applies to Dynamics NAV and to Business Central on-premises, where that database is yours and your DBA can query it. It does not apply to Business Central online: the SaaS tenant runs on an Azure SQL database Microsoft administers, and no one outside Microsoft has a SQL surface on it. There is nothing there for this collection to read, and any offer to index-tune a Business Central online tenant from the SQL side is describing something that does not exist.

A slow SaaS tenant is still a real problem — it is simply a different one, worked through AL, keys and SIFT, partial records, DataAccessIntent and Application Insights telemetry rather than through the database. The tuning page draws the same line and explains what the ERP lens adds on top of the standard SQL Server read.

If you are a Microsoft partner

Then you already know the shape of this. Microsoft's own support documentation makes the reselling partner the frontline of support, and says that once a cause is determined to point to custom code, partner or ISV software, environmental factors or anything else outside core Microsoft code, the Dynamics support team provides evidence to support that, in order for the customer or partner to proceed with the investigation themselves. Separately, where an isolated performance case is not resolved after best-effort break-fix work, the guidance is to consult a partner or the community forums — and the technical support incident is then closed. Microsoft Learn — Technical support overview ↗

Read those two together and the shape is plain. The obligation is to evidence that the cause sits outside Microsoft's code — not to find where it sits instead. Whichever way the case ends, the question you still have to answer lands back on your desk, and that is the work this rung is built for.

The arrangement is corp-to-corp and it is deliberately unglamorous: a specialist read on the database layer, under your brand if you prefer it that way, on an estate you already hold the relationship for. No introduction to your customer is required and none is sought. If it is useful once, it is useful again the next time a ticket comes back.

How it is quoted

A fixed fee in Canadian dollars, stated in writing before any work starts, and never time-and-materials — you are buying a defined deliverable, not an open meter. We do not publish a figure before seeing the estate, because a number quoted ahead of scope is wrong for almost everyone who reads it. The figure for a first look is settled on the free discovery call, and the whole of it is credited against a Database Health Audit or a tuning engagement if you proceed within the stated window.

Founder-led delivery, with additional capacity contracted in per engagement where scope warrants it — there is no standing bench. There are no client references yet and we will not invent them. Microsoft, Dynamics, Business Central, SQL Server and Azure are names of their respective owners, used here for identification only.

Get in touch

Find out what is wrong before you decide what to spend.

Book a free 30-minute discovery call. Tell us what got slow and roughly when, and we will tell you whether a first look would answer it — including when the answer is that it would not, which is worth knowing before you pay anybody.

Book the free call