Some of your Questions:

Q. How LeBLANC compares to lowcode/nocode platforms?

LeBLANC is at it's best when creating line of business systems (LOB) large or small, like for example expenses payable, billing, logistics, insurance handling or a reservation system. Systems that own the data and handle the business processes from start to finish.

Current lowcode / nocode tools are good for creating small utility apps that implement few business process steps for selected oganization internal users. To answer the question: LeBLANC creates you whole systems with everything included: User interfaces, API layer to for integrations and data layer implementation to store your entities. And gives you the source codes for you to enhance & modify. So if you wish to call us a lowcode/nocode platform - that's fine, but that's not what we are really about.

Q. How does LeBLANC position with other business app platforms?

LeBLANC excels in the same class and category that you might consider other business app platforms like Microsoft Dynamics 365, SalesForce, Oracle ERP and others. The main difference lies in flexibility: We won't tie you to any specific business domain (eg. CRM, logistics, billing), which means you can easily create crossovers. Create systems that handle all the domain(s) you need now, implement cross business unit processes, integrate with others, and later on alter or expand when your business changes.

In addition, our licensing policy is simpler, more straightforward and more flexible than the alternatives. We charge you a small share of the value (cost savings or increased revenue) you get by using our LB software factory. When you win, we win.

Q. What's LeBLANC view on Agile?

Our method, and most principles listed in Agile Manifesto aim for the same results: Continuously deliver valuable software, with working software being the measure of progress. We welcome changes, and include the business expert in key role during the design. If you were asking whether the work with LeBLANC can be organized to sprints and other Scrum practices - Yes, by all means. Or any other method you may prefer, we don't really care.

Instead of Agile, we see our approach closer to Lean: We eliminate waste from the development process. Our software factory method defines what should be done, by whom and in which order to eliminate wait times and overproduction. Automatically produced, flawless code reduces needs for testing and correction iterations. Our tools minimize motion and conveyance.

The method distilled: "Add your unique business content, we handle the rest."

Q. Is the resulting application a Black Box?

Nope. Fusion Generator produces you a downloadable Visual Studio project, which contains the application source codes, required scripts and configuration files. There are things that are easier to just code, instead of try solve with any models. Our whole method is based on idea that you can (and most often should) enhance your key use cases with custom implementations. Typical modifications include customized home pages for various user roles, integrations to other systems and business process implementation. These customizations are usually less than 20% of the whole application, so the majority of the application is still automatically generated code.

You can alter any part of the application as you see best fit, but we have few best practices - or conventions - that enables you to regenerate the application at any time without breaking the application or your custom code.

Q. Does using LeBLANC result into a vendor lock?

From application development perspective, there's no vendor lock. The application uses standard Microsoft techologies, so if you decide to stop using our development tools (and start maintaining the app manually with human coders), you'll have number of skilled development partners available for the job. Please note though that as long as your in-production application uses generated source code (our © copyrighted IPR), you are required to have a valid production license for your application. See Terms of Use for details.

Q. Can I customize what the application looks like?

The application you get as a result from Fusion Generator is "white labeled". This means that the user interface you get is themed with our default LeBLANC look and feel, and the idea is that you theme it to suit your needs - add the company colors, your logo, footer texts - you can alter the whole application outlook with CSS style sheets. We've reserved app.css stylesheet for your customizations, which you can use to override our default white label theme.

Q. Model Driven Development has been around for a long time, how is this better now?

Our method is based on 60+ years of real life business application development experience, not solely on academic interests like the 4GL mostly was at the time. The main difference is that we are not trying to solve how to build every imaginable application, but to keep tight focus on line-of-business (LOB) applications (Meaning: We wouldn't recommend building Fortnite gamer user interface using LeBLANC). We seek repeating tasks and patterns in LOB application development, and try figure out how to automate these. Also finding the right abstraction level is crucial - there are things that are easier to code, than try solve with any models. One major caveat in previous attempts was that the CASE tools used to be rigid - you couldn't touch the generated code without breaking the application. We can. Our whole methodology is based to enable your customizations - not to prevent them.

Q. What are the roles and their required skills in LeBLANC software factory project?

See page Roles and skills required.

Q. What is LeBLANC pricing policy?

We use value based pricing, meaning we charge you a small share of the value (cost savings or increased revenue) you get by using our LB software factory. If the value for you is small, we charge you a little. If we can help you make or save shitloads of money, we charge you a bit more.

No upfront costs, monthly billing on your Azure invoice. You pay a monthly fee for 1) development tools (LeBLANC Designer and Fusion Generator) with selected features, and when your application goes to production, you need to obtain a 2) Named Application Production runtime license. Development and test environments don't require production license.

See Pricing for details.

Q. How does your method deal with customer requirements changing mid-prjoject?

"We welcome change", but IRL everybody hates to have them out-of-the-blue mid-project as they tend to affect both schedule and cost. This is still reality, and can happen in any project. Due to automation, the projects are shorter using LeBLANC, meaning that life altering changes are much less likely to occur, or at least the amount of changes during single project is more limited. The customer has less time to move the goal, so to speak.

If and when these changes occur in LB project, you usually return to fix your model. Make the change, and re-generate the application. The automatically generated parts now contain the changes in data model, database, their respective UI's and APIs provided.

The change may affect your custom coded parts - if the API (or db table) your own custom code uses change, you must implement the respective changes to your own custom code. Trying to avoid unnessecary customization as much as possible is the key to limit the effects of changes.

Q. Why the resulting application doesn't use microservices (or some other architecture I like)?

Every architecture- and technologial decision we've made can be traced back to typical business application requirements, and are battle proven in thousands of similar real life production applications for decades. We know there are hundreds of different of technologies, tools, libraries, architectures, patterns, styles, programming languages and components, that could have been used to create the same result. Because of this combinatorial explosion, nothing we provide can ever satisfy any architect or developer personal preferences - It’s statistically near impossible, like winning a lottery. Read more about NIH .

Explicitly - why not microservices... We picked this answer from Medium discussion, as it explains our reasoning as well (sorry - couldn't find the original author anymore):

Microservices aren’t bad. They’re just expensive. You pay for them in infrastructure, observability, network complexity, deployment orchestration, and cognitive load. That’s a fine trade if you’re Amazon. Or if you have ten teams working on loosely coupled domains. Or if your scale makes it necessary.

But most of us aren’t building Netflix. We’re building HR portals, internal tools, and SaaS apps for dentists. You don’t need a distributed system to send password resets. Modular monoliths let you delay paying the distributed systems tax until you absolutely have to. And when you do outgrow the monolith, splitting it into microservices is way easier when your modules are already clean and isolated. It’s the only migration plan that doesn’t end in regret and career burnout.