Build the app.
Make it enterprise grade.
Every organization should build solutions to its business problems, big or small. Give your teams room to create with AI. Taiga checks apps against your policies, repairs quality and security gaps, verifies the changes and deploys through your chosen infrastructure.
Illustrative project. The example app uses fictional data in your browser.
A small app solves a real problem.
Request Desk
Illustrative workflow · sample records
External display
Requested by a colleague in Operations
Waiting for team approvaloperations/request-desk
An operations team has vibe-coded a request app. Colleagues can ask for equipment, and team approvers can approve it. The workflow is useful. Putting it into everyday use means meeting the organization’s requirements, with evidence your team can review.
Keep equipment requests and the approval workflow. Prepare the app for our organization.Keep equipment requests and the approval workflow. Prepare the app for our organization.
The team built Request Desk to replace equipment requests scattered across messages. Keep that useful workflow. Connect its repository to a new import project in Taiga, and record what the app needs to preserve.
Your app has a place in the organization.
Organization context
Illustrative workflow · sample records
REQ–01Only team approvers may approve equipment requests.
Access and identity
Company sign-in. Only team approvers can approve requests.
Data and retention
Use the approved storage location and retention period.
Engineering and security
Review dependencies, test authorization and protect secrets.
Release and runtime
Use the chosen enterprise environment and its release approvals.
Example requirements set by the organization. Controls without evidence stay open for review.
Set the requirements for putting it into use: who may approve a request, how it signs people in and where it should run. Publish the policies Taiga will assess it against. Keep the team's business purpose and the organization's requirements together.
Find the gaps against your policies.
Findings and policy gaps
Illustrative workflow · sample records
Approval rule is not enforced at the endpoint
Policy REQ–01 · src/api/requests.ts · 8f4c2a1
The interface hides Approve. A direct request can still reach the update.
Dependency needs a security update
Repository scan · package lockfile
A separate scanner finding with its own repair and follow-up scan.
An approval must update the selected request without changing another.
Taiga derives documents from the code, with file citations. Repository scans and an assessment against your published policies turn what it finds into proposed work. Your team reviews the evidence and chooses what happens next.
Approval needs a check on the server.
Repair initiative
Illustrative workflow · sample records
- 01Carry REQ–01 into the plan
- 02Add the server authorization check
- 03Test allowed and denied requests
- 04Review the changes under project settings
approveRequest(requestId);requireTeamApprover(user, request.team);
approveRequest(requestId);requireTeamApprover(user, request.team);
approveRequest(requestId);The request workflow stays. The missing check changes.
Simplified example code. Identity and authorization are checked on the server.
Request Desk hides the approval button from colleagues who cannot approve. The endpoint still accepts their request. Taiga plans and builds the server check, with tests for both allowed and denied requests. The repair also checks that an approval changes the correct request. The original request workflow stays in place.
The same request is rejected this time.
Evidence for the release decision
Illustrative workflow · sample records
Requester calls approval endpoint
Denied · request remains unchanged
Team approver approves the request
Allowed · only the selected request changes
Dependency repair is scanned again
Finding resolved after the fresh scan
Policies are assessed again
Refreshed documents support the acceptance review
8f4c2a1These are separate pieces of example evidence. Passing one does not establish that every control passes.
The permission test tries the approval endpoint as a requester. After the repair, the server rejects it; an approver can still approve. The dependency repair gets a fresh independent scan. The policy assessment is repeated against refreshed documents.
The same app reaches your infrastructure.
Release through your enterprise pipeline
Illustrative workflow · sample records
Your organization’s enterprise infrastructure
Reviewed commit → environment approval → production
8f4c2a1main · GitHub Actions8f4c2a1main · GitHub Actions8f4c2a1ProductionSucceeded8f4c2a1DevelopmentSucceededThe configured pipeline performs the deployment and runtime checks. Taiga tracks the connected GitHub deployment record.
Deploy to your chosen enterprise infrastructure through your configured delivery pipeline. The reviewed change follows its environment approvals and runtime checks. Taiga tracks the connected GitHub deployment record, so your team can follow the commit into the chosen environment.
The next change starts from a running app.
Keep the app and its context together
Illustrative workflow · sample records
Observe the running app
Availability from the configured URL. Browser signals from the installed browser monitoring beacon.
Repair what changes
Repository findings become maintenance work with verification after the repair.
Build the next useful change
Add a reminder when a request is waiting for approval.
The next initiative keeps the same documents and policies.
Taiga keeps scanning the repository and preparing maintenance work. Connect the app URL for availability checks and install the browser monitoring beacon for browser signals. When the team needs a new capability, put it in the same initiative queue, with the app’s documents and policies still in context.
Colleagues can ask. Approvers can approve.
The team's app still solves the same problem. It now has a reviewed repair, verification evidence and a route through the organization's delivery process. Try the permission rule that followed it all the way through.
Only a team approver can approve. Try it as the requester first.
External display
The team needs an external display. Submit the request to start.
The rule behind this result
REQ–01 → server check → denied and allowed request tests → reviewed release. In a real app, the server enforces the rule on every request.
Agree what enterprise grade means for your app.
Start with a linked repository Taiga can work with. Agree the stack, required changes and target environment for your app; compatibility and any infrastructure adaptation need review. Published policies provide assessment context, and evidence supports your team's acceptance decision. It does not certify the app or establish that every control passes.
Under Taiga Complete, Taiga runs the provided environment. In your own cloud account, your organization owns the runtime and its security. Monitoring requires the relevant connections, and incident response follows the agreed service scope.