Application code you own
Keep your product in its own source code, with Wildo supplying the shared framework.
Application-owned code · framework packages · open-core directionA foundation you can understand and build upon.
Choosing a framework is a long-term relationship. You need to understand what it contributes, where your own product lives and how that relationship can evolve.
Wildo is moving toward open core. The direction is to combine an inspectable shared foundation with a sustainable way to maintain it. The licensing terms and the boundary between open and commercial features are being defined.
Make the relationship with the framework explicit
Keep the application a concrete project
Wildo applications have their own declarations, business implementations, components and environment configuration. The factory works with that project through development tools and coding agents.
That gives a team concrete material to review and evolve: product specifications, application code and the framework dependency it uses. Explore the B2B SaaS application to see how those parts fit together.
- An application to inspect: Specifications, declarations and custom code form a concrete project.
- Development in your workspace: Tools and coding agents work with that application structure.
- A visible framework dependency: Teams can examine how the engine supports their product.
Make the foundation understandable
An inspectable engine helps a developer follow a behavior to its implementation. It also gives AI tooling a stronger basis for explaining and extending the application, alongside the framework knowledge supplied for that purpose.
This is the intention behind the open-core direction: make the shared engineering easier to understand and scrutinize. The eventual license will define the rights attached to the published source.
- Follow behavior to source: An inspectable engine supports deeper understanding of application behavior.
- Stronger context for tooling: Implementation knowledge complements the framework guidance supplied to agents.
- An explicit open-core direction: Published licensing terms will define the associated source rights.
Support the work that continues
A framework needs continuing attention: security corrections, integration changes, compatibility work and improvements to the mechanisms applications share.
Open core is the intended model for sustaining that work while making a common foundation available. Commercial boundaries will be explicit, so a team can understand which parts of its application depend on which offerings.
- Maintenance beyond first release: Security, compatibility and integrations require continuing engineering attention.
- A sustainable shared foundation: The intended model supports the work applications depend on.
- Clear commercial boundaries: Published offerings should make application dependencies understandable to teams.
Plan for a product that will evolve
A team should be able to examine the foundation it is choosing, understand how its application uses it and plan how to adopt future changes. That visibility matters to technical teams and to the people responsible for the product over time.
The intended open-core relationship brings that consideration into the product itself: a common foundation, clear commercial boundaries and continuing engineering behind them.
- Understand the chosen dependency: Inspect how the foundation contributes to your application.
- Plan for future changes: Adoption decisions include updates and the continuing product lifecycle.
- Evaluate the published terms: Licensing and commercial conditions define the eventual adoption relationship.
Example: Evaluate a long-term dependency
A team examines the application it would maintain, the engine mechanisms it would depend on and the deployment model it needs. It then checks the published license and commercial terms against those needs before making an adoption decision.
Separate architecture from licensing rights
Identify the parts of the relationship
| Part | What to examine |
|---|---|
| Application project | Its specifications, declarations, custom code and configuration |
| Engine dependency | The shared runtime mechanisms and the revision the application adopts |
| Development tooling | The companion, CLI, framework knowledge and coding-agent workflow |
| Deployment | The application’s service topology and operating configuration |
| Licensing and commercial access | The published rights and feature conditions that apply to those parts |
Understand what the architecture establishes
The generated application separates its own implementation from shared engine packages. Framework knowledge is delivered into the development project, and the companion exposes project context to supported tooling. Deployment configuration describes the services used by that application.
Those are architectural properties. They do not, by themselves, establish redistribution rights, the terms of source access or an entitlement to commercial features.
Use the terms that exist when you adopt
The open-core boundary is still a product decision. No licensing conclusion should be inferred from a repository path, an implementation detail or the absence of an Enterprise badge.
The development companion and CLI explain the working environment; the application artifacts explain the delivered project. Licensing terms will govern the rights associated with them.
Build a relationship that can last.
Understand the application, the shared foundation and the terms connecting them. Wildo’s open-core direction is intended to make that relationship clear and sustainable.
Building a B2B product or an internal tool?
Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.