In March 2020 Danny Hellemons joined an Areopa Academy webinar to describe the multi-year journey Schouw Informatisering took from a traditional combined ISV/VAR model to a full ISV publishing on Microsoft AppSource. Danny was the CTO who drove that change; by the time of the session the company had been acquired by Aptean and he carried the title of Principal Architect. The talk is practical and frank — equal parts architecture, team management, and lessons learned the hard way.
Moderator Luc van Vugt facilitated the session and fielded audience questions throughout the Q&A.
Product Development Is Not a One-Off
Danny opened with a premise he shared with the CEO on day one: product development is a continuous discipline, not a project. He compared it to running a sports club — you have to build the team, develop the merchandise, and maintain the brand over time through incremental improvement rather than a single big-bang release.
When he arrived four years earlier, the product development department was functionally entangled with the services and implementation teams. Developers were taking assignments from customer projects rather than building a standalone product. The first task was to separate those two activities so that each could find its own pace — what he called standing on their own two feet.
From ISVAR to True ISV
The transition unfolded in three stages. First, the Product Development department had to operate independently from implementation. Second, the team shifted its mindset from “building for our customers” to “building for VAR channels globally” — a significant change when the company had previously only served Dutch customers. Third, delivery needed to expand well beyond code: documentation, training materials, support programmes, and a clear Definition of Done all became part of what it means to ship a product.
Danny was candid that changing the organisation’s mindset took roughly two years. The underlying product, Foodware 365, is an industry solution for food companies built on Dynamics 365 Business Central. In the year before the webinar, the team completed 31 apps from scratch — no refactoring of the old monolith, no reuse of legacy C/AL code.
Leveraging the Full Microsoft Platform
One of the central messages is that a modern ISV product cannot live entirely inside Business Central. Schouw deliberately set out to use the wider Dynamics 365 and Azure platform: Power Automate, Power Apps, Power BI embedded, Common Data Services (now Dataverse), Azure Functions, Azure Service Bus, Logic Apps, Office 365 including Teams, SharePoint, and the Outlook add-in.
To illustrate the positioning of apps across that landscape, Danny showed a bubble chart mapping each app along two axes: “functionally loaded” versus “less functionality” on one axis, and “old-fashion thinking” versus “embracing the Dynamics 365 platform” on the other. Apps that lean heavily on standard BC finance and logistics sit toward the left; newer purpose-built apps such as the Quality Check (QCK) and Shop Floor Production (SFP) modules sit to the right, using Power Apps and CDS as their primary runtime.
“For quality control, the ERP basis is not heavily in Business Central — so why build it inside BC? Put it outside and connect it through events.”
Danny Hellemons
The Quality Check app illustrates this approach in detail. BC raises events via an Azure Function, which puts a message on an Azure Service Bus. A second Azure Function picks up that message and pushes data to CDS and the Quality Check Foundation app built in Power Apps. When an inspection creates a transaction that needs to flow back into BC, a third Azure Function calls the BC REST API. Deployment of the Power Apps side uses the Power Apps ALM lifecycle toolkit, and release management must align across both the BC and Azure Marketplace targets.
The BC–CDS integration Danny references for near-real-time data synchronisation is now documented in full. See Integrate with Microsoft Dataverse on Microsoft Learn.
Product Strategy: Gartner’s Pace-Layered Model
To decide what to build and how to build it, the team adopted Gartner’s Pace-Layered Application Strategy from 2006. The model splits an application landscape into three tiers:
- Systems of Record — standard business processes focused on operational efficiency and compliance.
- Systems of Differentiation — business-critical processes that give competitive advantage and need to be flexible and highly parameterised.
- Systems of Innovation — exploratory, uncertain-value areas where low-code and no-code tools shine. If an experiment succeeds, it graduates to a fully built application.
In the food and fresh-produce market, processes such as commission handling vary significantly from customer to customer. Those belong in the differentiation layer with a parameterised, modular design rather than a single monolithic codebase. Danny described the hard cost of the old monolith: high migration effort for customers, difficult upgrades, and slow partner onboarding.
Business Domain and App Approach
The response to the monolith problem was an explicit Business Domain and App Approach. Rather than one large product, Foodware 365 is structured as independent domain modules — ERP, CRM, Shop Floor, TMS, PIM, WMS — that each stand alone but connect through a shared integration layer.
Danny used a house analogy: you do not tile the bathroom before designing the house, because the plumbing runs through every room. The Foodware 365 “house” provides the foundation and event-driven plumbing so that a customer who only needs ERP and TMS still benefits from a consistent architecture, and a VAR can add their own extensions on top of the Foodware 365 layer, just as Foodware 365 builds on top of BC.
External communication — EDI (EDIFACT), GDSN, Customs, and other third-party systems — plugs into the same functional and technical layers through a Data Exchange Framework, keeping cross-company business processes consistent regardless of their direction.
Building extensible apps that support layered partner extensions requires careful attention to the extension model in AL. Integration events and API pages are key mechanisms for enabling downstream customisation without breaking the ISV layer.
DevOps: a Unified Platform Challenge
Moving beyond a single BC app makes DevOps substantially more complex. The Schouw team had to automate provisioning and configuration across BC, Power Apps, CDS, and Azure Services simultaneously. The five-minute version of their setup covers: VS Code and Git for developer environments; container-based test environments; Azure Test VMs for full-blown testing; configuration packages (RapidStart) for BC setup; ARM templates for Logic Apps and other Azure infrastructure; and BC and CDS APIs for automated post-deployment configuration.
Danny was explicit that not everything was ready when they started, and that disruptions — such as multi-factor authentication combinations breaking existing BC flows — are part of the journey. The advice is a consistent step-by-step approach rather than trying to automate everything at once.
For BC-specific build and release automation, the community broadly uses ALOps by Hodg-High. It integrates AL compilation, app signing, and deployment into Azure DevOps pipelines — the same kind of automation Danny described for automated functional testing and staged release environments.
Two-Track Development
With enough resources after the Aptean acquisition, the team moved to a two-track development model. Track 1 (DEV) focuses purely on product development: new apps and new releases built on pre-release/daily BC builds, with W1 localisation only, unit tests, and a timebox-per-app schedule. Output from Track 1 goes into Track 2 (PROD), which handles localisation, translation, integration testing for every product-market combination, staging for each VAR and customer, and delivery to Microsoft AppSource on Microsoft’s CU release schedule.
Keeping the two tracks separate prevents the common ISV anti-pattern of simultaneously trying to ship new features and fix localisation issues — which Danny compared to pressing the accelerator and the brake at the same time.
The current DevOps process ties it all together: Azure DevOps for work item tracking and project management, build pipelines for individual apps, a test release pipeline covering integration testing and staging environments, and a pre-production environment that was still work in progress at the time of the session.
Team Readiness and Continuous Learning
Before starting the main product project, the team ran a six-week ramp-up programme covering Azure architecture, Power Apps, ClickLearn for work instructions, design patterns, UX fundamentals, and automated testing. The week before the first sprint was an exam week where everyone built something for practice.
The frank message is that 80% of the knowledge you need at the start of a SaaS project is knowledge you do not yet have. The three strategies Danny recommended are: forward thinking and accepting that learning and delivering happen in parallel; running rehearsals and PoCs to build confidence rather than waiting for certainty; and opening up — partnering with MVPs, other ISVs, and Microsoft rather than trying to acquire all expertise internally.
Retrospectives at architectural, UX, and developer levels feed a continuous cycle of combining what was learned, establishing design patterns, and adapting before the next sprint. The team deliberately avoids the status quo — “never accept the status quo” was a recurring theme.
The Rethink–Redesign–Redevelop–Validate Process
Rather than refactoring the old code, the team chose a complete rethink for each module. Solution architects and functional experts draw process flows, run functional decomposition, and produce entity relationship diagrams. The output goes into redesign sessions that generate use cases, test scripts, and Definition of Done artefacts. A reference group of key VAR contacts and customers validates progress every two days in short communication cycles within a two-week sprint.
Definition of Done
The Definition of Done is what separates a product from code. For every app shipped, the Schouw team requires: process designs and entity relationship diagrams; a DEV kit including OAS/Swagger documentation and a full Postman test collection; automated unit tests, test scripts, and test plans; data install and upgrade procedures; translation files; integration events for VAR extensibility; work instructions and how-to videos using ClickLearn; release notes; profiles and permission sets; W1 English with growing support for other languages; the latest cumulative update; demo datasets and demo scripts; and build and release pipelines for both internal use and VAR distribution.
Danny noted the ratio: for every half-hour of development and half-hour of unit test scripting, the team spends a further three-and-a-half hours completing the Definition of Done. That overhead is not waste — it is what makes the product supportable, extensible, and upgradeable for a global VAR network.
AppSource: Scratching the Surface
The AppSource section was the most cautionary part of the talk. At the time of recording, AppSource validation was largely manual, versioning was non-trivial, packaging and pricing were difficult, and commercial marketplace tooling was incomplete. Subscription and licence management, KPIs for pay-as-you-go, and monetisation infrastructure all required custom solutions because Microsoft had not yet delivered them.
The practical advice: start thinking about AppSource early because it is a project in its own right, collaborate with other ISVs to share solutions, and expect iteration. The team had launched a “Launch Fast Forward” programme to get customers live on Foodware 365 within five to ten days — a five-step onboarding process covering package selection, account creation, planning, training, and going live — and were rolling it out in waves to learn from each cohort.
The AppSource submission and validation process Danny describes has evolved significantly since 2020. The current requirements, including technical validation, marketing content, and the commercial marketplace offer types, are documented at AppSource submission checklist for Business Central apps.
This post was generated with AI assistance from the Areopa Academy webinar recording. The transcript was produced from YouTube auto-captions and may contain transcription errors in proper nouns and technical terms. Timestamps link to the relevant moment in the video.