Usually, I write posts about a certain technical subject, but not today.
Today I’ll tell you the true story behind my build service for NAV/BC and I hope I’ve challenged you by the time you reach the end of this post.

Today is a good day, today the 1000th build ran on my CI service for Dynamics 365 BC/NAV and that feels like a huge achievement if I look back at how this all started.
I initially came up with this idea of a generic build service almost two years ago, in those two years the code has been rewritten twice and I’ve changed from a build API approach to a service exclusively for Azure DevOps.
Next to that, Docker came around, Business Central replaced NAV, C/SIDE is now retired, we got AL in return and I probably forgot to mention a lot of other disruptors.

In this rapidly changing world, building and maintaining a generic build service for BC/NAV is not just about writing some PowerShell functions and ship that to customers.
Also with a small service you have to get used to a dynamic world where you adapt to changes quickly and you’ll need to accept the fact that the service will always be in beta, just like Business Central.
With a cloud service, you’re responsible for everything and you need to have a lot of things in place, for example, logging, monitoring, tenant provisioning, security and a lot of unit tests to ensure quality.
And even then, things can go wrong and they will go wrong, but that’s okay, if you move fast, you break things

Since I’ve released the service at the end of last year, I haven’t blogged about it once, due to the fact that I didn’t have all those SaaS things in place and I wanted to have time to implement that and give my first two customers the best possible experience.
In case you’ve read the book Blitzscaling by Reid Hoffman and Chris Yeh (must read if you’re an entrepreneur), this is called controlled, efficient growth and this is a great way to figure out a product-market fit.

Is it a great product-market fit?

It is and it is not, while there’s a lot of attention for CI/CD at conferences like the NAV TechDays and Directions, there’s literally no traction when it comes to purchasing a third-party service that handles your entire CI process for a small amount of money per month.
That’s really weird, right? I mean, what can you do for €200 per month? (€200 is the cost of using my build service for AL projects, including infrastructure)
Let’s say you’re building your own CI process just for AL, you’ll most likely spend a couple of weeks developing it (sunny scenario) and then you think you’re done, but you’re not.
If you’ve ever built a CI process internally (maybe for C/AL), you’ll agree with me that it’s an ongoing process and that it will always be in development, to put it differently: it’s a huge distraction for you and your team and it might even hold the company back from what it wants to achieve.

Even with all the code being shared by various people on GitHub (kudos for that), you still need to tie everything together (assuming that it covers your scenarios) and you still need to maintain the code, manage infrastructure, etc. etc.
I’m not writing this post to make you buy my build service (which would be great of course), but I’m writing this to challenge you to also look at the business side of things.
If you currently have a CI process in place, you probably spend more than €2400 (€200 x 12 months) per year on it if you sum up labor and infrastructure costs, am I right?

Us developers (yes I’m also a developer) are not used to look at the business side of things, if we need it, we build it, even though another Dynamics partner or company already has a solution or the knowledge to help you out.

Let’s stop to reinvent the wheel, change our mindset and help each other out, it will be way more fun!