Build software that belongs in your enterprise.
A working app in an unapproved cloud still leaves your team with a problem. Your architecture, security standards and operating model belong in the decisions that shape the software, before anyone builds it.
Taiga brings your business intent and published company policies into the specification and design, then carries that context into delivery and maintenance.
A customer portal, built around your company.
The business asks for a customer portal. Your team already has an identity provider, approved infrastructure and rules for customer data. Taiga uses that context to shape how the request becomes software.
The interview clarifies who can see an order and what a customer needs to know. Published policies and team context inform the specification.
The architecture describes how the portal connects to company identity and approved services. Technology decisions explain those choices against your published policies.
An initiative plans the order-tracking feature using the agreed documents and policies. Code, checks and review records follow that scope.
Your delivery pipeline applies its configured checks and approvals. Taiga connects the portal’s deployment history to changes and environments, so your team can see what reached production.
Linked repositories can refresh after completed initiatives or code changes. Policy assessments compare the refreshed record with company controls and show the assessment state and source commit.
Discovery
The interview clarifies who can see an order and what a customer needs to know. Published policies and team context inform the specification.
Illustrative workflow
Your team gets software with a documented architecture and an operating record.
Your preferred cloud is a design input.
Set the cloud providers and technology stack your organization uses. Published architecture policies define approved choices; project documents describe the services, data flows and integrations the application needs.
Document checks surface policy conflicts for review. Deployment checks and approvals follow your configured pipeline.
- Identity
- Use the company identity provider
- Infrastructure
- Use approved cloud services and regions
- Data
- Apply access and retention requirements
- Delivery
- Version infrastructure and deployment configuration
Document the selected services and why they fit.
Proposal: a separate password database
Company rule: use the approved identity provider
Document review: resolve the identity conflictThe next team should know why.
The architecture records the chosen identity service; the data flow shows where customer information travels. The threat model examines how access could fail. Eight required setup documents carry these decisions into delivery. Service Blueprint and Look & Feel are optional.
For existing software, codebase-derived documents describe what is there. Policy assessments retain evidence for reported gaps and link to the initiatives addressing them.
Evolve your software- Specification
- User flows
- Architecture
- Technology decisions
- Data flow
- Threat model
- DPIA
- Risk register
- Service Blueprint · optional
- Look & Feel · optional
See the decisions waiting for your team.
Your team owns the policies and required approvals. Pause the line, reorder queued work and resume when ready. If planning or building fails, Needs you explains why, with Plan again or Resume build where appropriate. Maintenance findings stay visible until the relevant verification resolves them.
These records support your compliance work. Your organization determines which regulations and frameworks apply and approves the controls it needs.
22 questions to organize a readiness review.
Govern, Secure, Build and Run are review areas, not one universal automated release gate. Mark what applies to the system, the evidence available and the accountable owner. An SBOM, rollback exercise or on-call arrangement is not implied by a completed Taiga run.
Govern
- Did a DPIA exist before the build started?
- Does a written threat model exist for it?
- Could you produce a record of who changed what, when, and why?
- Did every change go through a documented change-control step?
- If AI is in the loop, could you show conformity evidence this quarter?
Secure
- Was the code hardened against a written security policy, not reviewed by eye?
- Are its IAM roles least-privilege, and has anyone checked since launch?
- Are all secrets out of the code, stored and rotated?
- Is threat detection watching it in production right now?
- Can you show where its data lives, and prove it stays there?
Build
- Are its integrations (ERP, IdP) documented outside the code?
- Does the documentation match what actually shipped?
- Do its tests check what the business asked for, not just what the code does?
- Could you rebuild the environment from the repository alone?
- Is there a tested rollback path, versioned with the delivery?
Run
- Would you know it is degrading before a user tells you?
- Are its logs centralized and retained per your policy?
- Is someone on call for it, in writing?
- Are SLOs and error budgets defined?
- Do you have a current SBOM and a patch cadence?
- Has a backup ever been restored on purpose, as a test?
- Would it survive one availability zone failing?