Any language, any cloud: why we stay agnostic

One of the first questions we hear is which technology we use. It is a fair question, and our answer can sound evasive at first: we use the one that fits. We work in the languages and frameworks an organization already relies on, deploy to the cloud it has chosen or to hosting we manage ourselves, and keep running what we build.

This is not a slogan. It is a design position, and it has consequences for how applications are shaped, governed and maintained. This article explains the reasoning.

Agnostic does not mean indifferent

Being agnostic does not mean we have no opinions. Our architects have strong views about what makes a system maintainable, secure and pleasant to change. What we avoid is starting from a favourite stack and fitting the organization to it.

Every technology choice trades one set of constraints for another. The right trade depends on the organization, not on the vendor. A choice that is excellent for one client can be a liability for the next, because the people, systems and obligations around the application are different.

The constraints that decide

When we shape an application, the technology follows from a handful of questions that are specific to the organization.

• Who will live with it? If an internal team will maintain parts of the system, the languages they know matter more than the languages we prefer.
• What must it talk to? An application rarely stands alone. The ERP, the CRM, the identity provider and the reporting tools already in place shape what integrates cleanly.
• Where may the data live? Privacy law, contracts and internal policy can decide which regions and which providers are acceptable, before any technical preference enters the conversation.
• How will it be operated? Monitoring, backups, updates and incident response have to fit the people and processes that will carry them, day and night.
• How would you leave? Every system should have a credible exit: to another provider, to another team, or back in-house.

These questions are asked early, and the answers are recorded with the rest of the design. They are not left for the end of a project, when changing them is expensive.

Where it runs is a design decision

Hosting is often treated as an operational detail, settled after the application is built. We treat it as part of the design. An application can run in the organization's own cloud, in its own data centre, or on infrastructure that Croo manages. Each option carries different responsibilities for security, availability and cost, and the choice belongs to the organization.

To keep that choice real, the target environment is described in configuration rather than woven into the code. A simplified, illustrative record looks like this:

# Where the purchasing portal runs is recorded with its design.
application: purchasing-portal
packaging: container
environments:
  - name: acceptance
    hosting: client-cloud
    data-residency: canada
  - name: production
    hosting: client-cloud
    data-residency: canada
fallback:
  hosting: croo-managed
  reason: kept available if the platform team changes direction

The value is not in the file format. It is in the discipline: the application does not assume where it lives, so moving it is a deliberate project rather than a rewrite.

Keeping the exit door open

Lock-in rarely comes from a single decision. It accumulates through small conveniences: a proprietary service here, an undocumented script there. Staying agnostic means resisting that accumulation on the client's behalf.

In practice, that means a few habits.

• Portable packaging. Applications are packaged so they run the same way in any environment that supports standard containers, so the organization is not tied to one provider's runtime.
• Infrastructure described as code. Environments are created from reviewed definitions, not assembled by hand, so they can be recreated elsewhere.
• Open data. The organization can export its data in documented formats, at any time, without our help.
• Documentation that travels. Decisions, architecture and operating procedures live in the shared record, so another team could take over.

None of this prevents using the best service a provider offers. It means knowing, and writing down, what that choice costs if circumstances change.

What agnostic asks of us

Working across languages and clouds is harder than specializing in one. It asks for breadth in the crew and for discipline in how knowledge is kept.

Two things make it sustainable. The first is the Factory's shared memory: patterns, decisions and lessons from one stack are recorded in a way that the next piece of work can use. The second is AI-assisted production, which lowers the effort of working in a less familiar framework or reading an unfamiliar codebase. The judgment about architecture, security and trade-offs still belongs to senior people who answer for it.

Governance by design

Choosing where an application runs is also a governance decision. Data residency, access control, encryption, backups and the handling of personal information are settled in the same conversation as the technology, and recorded with it.

That is why we place this topic under governance by design. An organization should be able to say, at any time, where its applications run, who can reach them, why those choices were made and how it could change them. Staying agnostic is how we keep those answers in the organization's hands.

The short version

We do not sell a stack. We build enterprise applications in the languages and on the clouds that fit the organization, or run them ourselves when that is the better answer. The constraints decide, the choices are recorded, and the exit door stays open.