Looking for guidance on pushing Dev Tier (multi-tenant, clean architecture)

Context (high level)

  • Solo builder, early in the build.

  • Completed Speedruns; limited hands-on beyond that.

  • Goal: set a clean architecture now to avoid rework later.

What I’m aiming to do (kept intentionally generic)

  • Multi-tenant SaaS on Foundry with strict tenant isolation.

  • Ontology-centric reads; Actions for all writes.

  • Orchestrated background workflows (no customer data included here).

  • Analytics layer + optional AI-assisted recommendations that always require an admin approval step (no auto-execution).

  • External app ↔ Foundry via OAuth2 + REST.

Questions:

  1. Dev Tier feasibility: In practice, can Dev Tier support strong multi-tenant isolation (e.g., per-tenant namespaces/workspaces, RLS patterns, separated service principals)? Or are there common blockers that typically require Enterprise?

  2. Limits to plan around: Any Dev Tier caps that could constrain this approach?

    • Ontology scale (objects, relationships, versioning)

    • Actions throughput, idempotency/audit patterns

    • Automate / scheduled jobs / event triggers

    • AIP Logic/Agents availability or constraints

    • API/webhook rate limits or external integration boundaries

  3. Design for minimal rework: If starting on Dev Tier, what early design choices help a future migration (naming/namespace strategy, per-tenant isolation approach, repo/port-adapter boundaries, approval workflows, logging/audit strategy)?

  4. Learning path: Recommended training/certs for a solo builder beyond Speedruns?

  5. Early-stage pathways: Any programs or suggested paths for projects that may need select Enterprise-only capabilities before fully committing?

1 Like