HOW WE WORK · STANDARD FIRST

Standard first. Custom only when it earns it.

Every hour of custom development is an hour you pay for again at every update. So we start from what Dynamics already does well, and most clients end up with a fraction of the customisation they expected.

WHY WE DEFAULT TO STANDARD

Every hour of custom development is an hour you pay for again at every update.

Custom code has to be retested, sometimes rewritten, at every Dynamics 365 release. Standard functionality just keeps working. So we start from what Dynamics already does well, and most clients end up with a fraction of the customisation they expected going in.

What custom-first usually costs later

1
Every release becomes a mini re-implementationCustom code has to be checked, and sometimes rewritten, against each new release rather than just updating.
2
Institutional knowledge of "why" fades fastTwo years on, nobody remembers why a customisation exists, which makes it harder to safely remove or change.

What standard-first actually buys you

✓
Updates that just workMicrosoft's own testing covers standard functionality; you inherit that instead of re-doing it yourself.
✓
A system your next hire can actually learnStandard configuration is documented and searchable. A pile of undocumented custom code is not.

THE FOUR-STEP APPROACH

Standard first. Custom only when it earns it.

Understand

We walk your floor, sit through a close, and read whatever system you're on now. You get a written view of what's working and what isn't.

1–2 weeks

Fit to standard

Your processes mapped against out-of-the-box Dynamics. Every gap gets one answer: change the process, configure it, or build it, with the cost stated.

2–3 weeks

Build and migrate

Configuration, extensions, and data migration in parallel, with your team testing as we go rather than at the end.

8–20 weeks

Go live and stay live

Hypercare through your first close, then ongoing support that covers the two release waves a year.

Ongoing

See the full six-stage delivery method →

Where this fits inside Build (stage 04) →

WHEN WE DO RECOMMEND CUSTOM WORK

"Standard first" doesn't mean "standard only."

Some gaps are real. The test is whether the gap reflects something that actually differentiates the business, not just a habit left over from the old system.

1
The process is a genuine source of competitive advantageIf how you do something is part of why customers choose you, it's usually worth configuring or extending to match, not the other way around.
2
A regulatory or contractual requirement can't be met out of the boxSome statutory or customer-mandated formats genuinely require custom development.
3
The alternative is a manual workaround run every single cycleIf "fitting to standard" means a recurring manual process forever, the maintenance math usually favours building it once, properly.

FAQ

Questions about this approach.

Q.Won't fitting to standard mean changing how we work?

Sometimes, yes, and we'll say so explicitly during Fit to Standard rather than quietly building around it. Not every existing habit is worth preserving in code.

Q.How do you decide what gets built versus configured?

Every gap identified during Fit to Standard gets one of three answers: change the process, configure it, or build it, each with the cost and trade-off stated up front.

Q.Does this take longer than a custom-first approach?

Usually the opposite. Configuration is faster to build and test than custom code, which is most of why the timeline compresses.

Q.What happens to existing customisations if we migrate from another system?

Each one gets evaluated during Fit to Standard on its own merits, not carried over by default just because it existed before.

Considering an engagement

Get a straight read before you commit.

Tell us what you are trying to get done. We will walk you through how this approach would apply to your situation.

Book a 30-minute call

With someone who has run this before.

→

Run the situation diagnostic

Four minutes, no email required.

→