Wildo narrows its world to B2B SaaS and corporate internal tools, because a knowable domain is what makes a methodology writable
Wildo is not a builder for any software. It is a builder for one kind of software: the application a company sells to other companies, or runs for its own staff. That world has a recognisable shape, with tenants, roles, billing, a CRUD domain, approvals, retention and evidence, and the shape is stable enough that the way such a product is worked out can be written down as steps a machine runs and gates. There is no domain-plan playbook for “any program”; there is one for a world with tenants and a data model. The narrowing is what makes the methodology, and the engine underneath it, possible at all.
The problem it answers
The distance between a generated demo and a product a company can run is a long list of things that appear in no screenshot: tenant isolation that holds, roles and authorisation that fails closed, invitations, password, magic-link and multi-factor sign-in, enterprise single sign-on over SAML and OpenID Connect, directory provisioning, a billing catalogue with subscriptions and invoices, an audit trail routed to a security team’s own system, data-subject export, erasure with a retention policy that survives it, internationalisation, transactional email, files that carry the permissions of the record they belong to, observability, deployment. None of it is visible on a first screen and every item is required before the first real user.
A general-purpose generator cannot carry that list, because for general-purpose software the list is not known. For B2B SaaS and internal tools it is: it is finite, it is the same from one product to the next, and it is almost the whole cost. Wildo’s position is that the list belongs in the engine rather than in each generated application, where it is inherited, cannot drift per project, and does not have to be reviewed again for every new application.
The same narrowing is what lets a method be authored. Business method (positioning, customer profiles, benefit classification, value propositions) enters Wildo as executable playbooks rather than as prose in a prompt, and a playbook can only be written for a world whose steps are known.
What it rules in, and what it rules out
- A closed capability vocabulary. What an application may ask of the engine is a finite enum,
EngineCapability, currently seventeen members from organisations and billing through email, the AI slots and observability. An application declares the slots it intends to operate; it does not implement them. Rejected: an open capability string. An open vocabulary is one nobody can audit for completeness, and it would let each application invent a slot the engine does not fill. - A catalog of playbooks with declared inputs, outputs and preconditions. Twenty-six authored playbooks in three phases: seventeen top-down (vision, market, value proposition, requirements, roadmap, brand, business model, compliance), seven bottom-up (domain plan, placement plan, foundation, decompose, dispatch, scale, assemble and verify) and two refinement playbooks for document facts and compliance document candidates. Rejected: a single free-form “build my app” prompt. A prompt cannot be gated on what already exists in the repository; a playbook can.
- Hard parts in the engine, not in the generated code. Multi-tenant organisations, per-tenant scoping of every resource, tenant-confusion defences on writes, role hierarchies with a grant ceiling, fail-closed refusals, last-owner and last-administrator floors, enterprise single sign-on over SAML 2.0 and OpenID Connect, SCIM 2.0 provisioning: each is an engine mechanism that a generated application inherits by declaring a capability. Rejected: templating these into each application. A template copies the code and loses the fixes.
- Not a general-purpose builder, and not claimed to be one. Wildo does not position itself for games, embedded software, consumer mobile applications or scientific computing. Rejected: widening the domain to grow the market. Widening it removes the property everything else rests on.
What it means for someone building with Wildo
- If you are building a B2B SaaS or an internal tool, the parts you would otherwise rebuild for the hundredth time are already there and are not yours to maintain. You declare a capability; you do not implement tenancy, roles, SSO, billing or audit.
- If you are building something else, Wildo is the wrong tool, and it will say so rather than stretch. The narrowing is a feature you benefit from only inside the domain.
- The methodology has an opinion about order, and the opinion is visible: a playbook that needs a market snapshot says so, and the eligibility board says why it cannot run yet.
- Some of the list is carried by the engine but not yet exercised by an application, and the domain files say which. Where a capability is marked as implemented rather than shipped, treat it as a capability of the framework rather than a running feature of a product.
For engineers
Where it lives in the framework
- The capability enum.
EngineCapabilityinengine-capabilities.shared.schemas.tsis the closed vocabulary an application declares against. Its source records why slots were split (a chat model and a coding agent are different procurement and authorisation decisions) and why two former members were withdrawn when no provider could fill them. An application’swildo.saas.config.tsenables the slots it uses, aswildo.saas.config.tsdoes for organisations, transactional email and billing. - The playbook catalog. One folder per playbook under
playbooks, each aplaybook.definition.tsbeside amethod.md. The definitions are typed againstMetaWorkflowPlaybookSchema, with a phase, an executor, preconditions of a closed predicate kind, declared input families and declared output families.bottom_up.domain-plan, for example, requires requirements and a market snapshot to exist, reads five families, emits one atomic domain plan, and names the skills its executor loads.bottom_up.foundationturns the approved domain plan and the definition set into a configured application skeleton, and emits no artifact because the deliverable is the application itself. - The tenancy and identity mechanisms the domain presupposes. The
organizationsresource roots the organisation scope;ResourcePrimaryScopehas exactly four members; contextual filters are applied once per persistence adapter; SAML and OIDC connections are per organisation and routed by verified email domain; SCIM tokens are per organisation. These are the hard parts known in advance, and each is recorded with its maturity in the two domain files linked below.