In this Areopa Academy webinar, David Singleton, a Navision consultant since 1992 and long-time Microsoft MVP, asks a blunt question of the channel: you sell Business Central, you develop in AL, you have published an app—but does your team actually think like a Business Central partner, or is it still a NAV shop wearing a new logo? Moderated by Henrik Helgesen, the session traces three decades of change in the Navision/BC ecosystem and argues that the real dividing line between a NAV partner and a BC partner has very little to do with code.
Three decades of change
Singleton built the talk by feeding years of old conference decks into ChatGPT and asking it to summarize the major turning points in his own career, then narrowed the result down to a handful of milestones. The exercise surprised him: several changes that feel recent actually happened decades ago.
The timeline includes:
- 1993 — the first public demonstration of extensions in the DOS version of Navision, where separate trigger objects could be bolted onto the product without touching the underlying code.
- 1995 — at a partner meeting in Hanover, Navision partners were told hourly billing had no future and needed to shift to selling value.
- 1997 — Navision split its channel into two partner types: the NSC (Navision Solution Center), which sold product, and the NISH (Navision Independent Software House), which developed it — effectively an early version of today’s AppSource model.
- 2009 — at a Microsoft keynote in Munich, partners were told to move away from big custom projects toward vertical solutions.
- 2014 — Singleton presented a SaaS version of Navision at the Microsoft Azure Summit in Abu Dhabi, which he believes was the first time a SaaS Navision demo appeared on an official Microsoft stage.
- 2018 — the “dinosaur” presentation at NAV TechDays, delivered with Erik Ernst, argued that the technology itself had stopped being the differentiator and that individual, non-repeatable “10x developers” were becoming a liability rather than an asset.
- 2019 — the first Days of Knowledge conference in Odense shifted the community’s focus from developers and sales toward consultants and business model.
📖 Related session: NAV TechDays 2018 — The Future for Developers and Consultants — the earlier “dinosaur” presentation with Erik Ernst that this webinar builds on.
NAV partner vs. BC partner: what actually changes
Singleton is explicit that he sees little meaningful difference between writing a table, a codeunit, or a page in DOS-era Navision versus AL in Business Central Cloud. The AL language and the tooling, in his view, are not what separates a NAV partner from a BC partner. The difference comes down to how a partner sells, delivers, and gets paid.
He lays the old and new models side by side: early payment vs. constant cash flow, selling hours vs. selling products, a big upfront license vs. a monthly license, “magic sauce” custom work vs. “bottled sauce” standardized products, two-year projects vs. 60 days to live, 10x dinosaur developers vs. pipelines, project management vs. product management, technical debt vs. fast upgrades, and full service vs. self-serve.
Crucially, he separates this from the SaaS-vs-on-premises question. A partner selling recurring value without timesheets, even on an on-premises deployment, is a Business Central partner in Singleton’s framing. A partner selling SaaS licenses while still billing project hours dressed up as “apps” has not made the jump.
Cost-plus vs. selling value
The core of the talk is a distinction Singleton draws sharply: a NAV partner prices work based on what it costs the partner to deliver — cost plus margin, whether billed as fixed price, time and materials, or a capped estimate. A Business Central partner prices based on the value delivered to the customer, independent of the partner’s internal cost.
He warns against a common shortcut: taking a project’s total cost and dividing it into equal monthly payments over the contract term is not a recurring revenue model. That is simply the partner acting as a bank and lending money to the customer. A genuine shift means investing in a product once and selling it repeatedly, rather than investing in one-off projects.
Under the old model, risk sat with the customer — they paid up front and hoped the partner would deliver. Under the value model, the partner absorbs the delivery risk and only gets paid once, and for as long as, the customer is satisfied. Singleton argues this reverses the old incentive to stretch out project timelines: the faster a partner gets a customer live, the sooner recurring revenue starts.
The magic sauce problem
Every customer believes their process is special — their “magic sauce.” In the NAV era, partners built a business around bottling that exact sauce for a single customer. In the BC world, Singleton describes the opposite skill: blending ten different customers’ sauces into one standardized, “good enough” product that is not as good as any one customer’s original recipe, but better than most generic alternatives on the market.
He acknowledges the exceptions: sometimes a customer will not buy unless they get their specific customization. His own approach is to build it for free, absorbing the cost, rather than breaking the standardized pricing model with a change-request process. Occasionally that custom piece can be resold to another customer later; often it is simply a cost of keeping the deal.
Development model, project management, and technical debt
Singleton considers the shift from individual “10x dinosaur” developers to production-line style development teams to be largely solved across the channel already. He predicts that within five years, no single person at any BC partner will be able to deliver a complete implementation alone — delivery will require ten or more specialists, each contributing narrow pieces.
He draws a sharper distinction between project managers and product managers. A project manager exists to track costs against a specific customer’s budget and chase timesheets. A product manager oversees costs — for example, an internal automated-testing team — that are never billed directly to any one customer but instead get priced into the product as a whole. In his estimate, fewer than 5% of partners have fully made the shift away from time billing, but roughly half have already adopted product management for their vertical offerings.
Technical debt, tied closely to the magic sauce problem, is another area Singleton sees as largely handled: continuous update cycles have replaced the multi-year upgrade projects of the on-premises era.
The hidden cost: from support fees to employee burnout
The session’s most pointed observation concerns data ownership and self-service. In the NAV era, partners routinely accepted responsibility for cleaning up bad customer data — something Singleton calls one of the worst habits the industry ever adopted. In the BC era, that responsibility has shifted back to the customer, which he frames as fair: the partner should be able to say the data is dirty and refuse to touch it until it is cleaned up.
But he flags a side effect he is already seeing among end users: as partners charge less for support and push more onboarding and cleanup work onto the customer’s own staff, those employees end up absorbing extra, uncompensated work on top of their normal jobs — leading to burnout. He frames this as a cost that has not disappeared, only moved, and one the industry has not been fully honest with customers about.
Can we have both?
Singleton estimates around 80,000 Navision-style customers are still out there on older commercial models, meaning plenty of billable work remains for partners who have not made the shift. He believes a partner can serve both models in theory, but argues it is very difficult to run both well inside a single organization, since a team paid to maximize billed hours and a team paid to minimize delivery cost while keeping a customer subscribed have fundamentally opposed incentives. Splitting the two into genuinely separate teams, in his experience, is close to a requirement.
Q&A: how long the transition actually takes
In the Q&A, moderated by Henrik Helgesen, Singleton walked through his own timeline for eliminating timesheets across his customer base. He made the decision at a conference in Antwerp in 2018 and started with his largest customer — a choice he says, in hindsight, was a mistake, since a mid-sized customer would have been a safer first test. It then took him over a year to convert a second customer, largely from a lack of confidence, before the pace picked up to a new customer every two to three months. He sent his last timesheet in November 2023.
Looking back, he estimates the process took him five years but believes it could be done in about a year with the benefit of hindsight. Asked how many customers pushed back or refused the switch, his answer was: none. In his account, every customer preferred the new model — the resistance he encountered came from internal staff worried about commissions and overtime pay tied to hourly billing, not from customers.
📖 Related conference: Days of Knowledge Nordic — the Business Central partner conference in Odense that Singleton references as a milestone in the channel’s shift toward consultant-focused, business-model content.
📅 Upcoming Areopa webinars: the moderator listed several upcoming sessions, including “AI-Enabled Delivery for Consultants” (Neil McGowan) and “From Zero to Agent: Building Agents in Business Central” (Bert Verbeek). See the full schedule and past recordings at areopa.academy.
This post was drafted with AI assistance based on the webinar transcript and video content.