Out of the box, Taiga is opinionated — and your process probably isn’t exactly its default. Because the app runs on your own server, your vibe-code agent can edit Taiga’s configuration, tune the database, and adjust the frontend to fit how you actually work. Here are ten customizations worth asking for.
1. Rename and Recolor Statuses to Match Your Process
Taiga’s default story statuses (New, Ready, In progress, Ready for test, Done) are a starting point, not a rule. The agent can add, rename, and recolor statuses and task statuses per project — an ‘In review’ step, a ‘Waiting on client’ hold state, whatever your board really looks like. Ask: In the Website Redesign project, add an ‘In review’ status between In progress and Ready for test, color it orange, and move Victor’s current stories into it.
The board starts describing your workflow instead of the other way around.
2. Add Custom Fields to Stories and Issues
Custom fields let you attach structured data Taiga doesn’t track natively: text, numbers, dates, checkboxes, and dropdowns on user stories, tasks, or issues. Think ‘Customer requester’, ‘Found in version’, or a release-train dropdown. Ask: Add a dropdown custom field called ‘Release train’ to user stories with options 2026-Q4 through 2027-Q2, plus a text field ‘Customer requester’, and backfill the mobile stories to 2026-Q4.
Filters and exports suddenly carry the dimensions you care about.
3. Switch the Estimation Scale
If Fibonacci points feel arbitrary to your team, Taiga supports other scales — powers of two, T-shirt sizes — and even separate point attributes per role so design, dev, and QA effort are estimated independently. Ask: Change the project from Fibonacci to T-shirt sizes for points and add a separate QA-effort point attribute so testers can estimate independently.
It takes the agent minutes through the API or admin and changes how planning conversations feel.
4. Tune the Kanban Board: WIP Limits and Swimlanes
Kanban without limits is just a to-do list with columns — cards pile up and nobody notices until delivery slows. The agent sets work-in-progress limits per status and can add a check that flags you when a column overflows, plus configure swimlanes so epics get their own rows. Ask: Set WIP limits of 3 for In progress and 2 for Ready for test, alert me when a column exceeds its limit, and group the board into swimlanes by epic.
Flow problems become visible the day they start, not at the retro.
5. Lock Down Who Sees What
Taiga has a real permission model — owners, admins, members, and external viewers — and projects can be private or public, which matters the moment a client or contractor needs eyes on the work. The agent audits every project, fixes the roles, and adds outside collaborators with the narrowest sensible access. Ask: Make the Legal project private, add our external lawyer as an external viewer on only that project, and verify they receive no notifications from anywhere else.
Clients and contractors see their board and nothing else.
6. Tame the Notification Flood
Taiga can email on every change, which trains people to ignore Taiga email — and then real mentions drown in the noise. The agent walks each member’s settings and keeps only what matters — mentions and assignments for most, status changes for leads — and turns the rest off. Ask: For every member except me, keep only mention and assignment emails and disable everything else so the team stops tuning Taiga out.
Fewer, meaningful pings means people actually read them and react the same day.
7. Rebrand the Instance
The frontend’s behavior lives in its config — default language, max upload size, terms-of-service links, plugin endpoints — and the login page text can be adjusted too. The agent edits those files on the server and restarts the frontend. Ask: Set the frontend default language to Spanish, raise the max upload to 50MB, and change the login page text to our company name with a link to our internal wiki.
Your instance stops looking like a generic install on day one.
8. Control Registration
A self-hosted Taiga with open public registration is an invitation to strangers, and it’s a setting worth checking on every new install. The agent checks the registration flag, confirms invitations still work for your team, and audits for accidentally public projects. Ask: Disable public registration on my instance but keep project invitations working, and list any public projects so I can confirm they’re meant to be.
Two minutes of checking beats discovering a public board with your roadmap on it.
9. Harden the Server Side
Under the hood, Taiga is Django plus Postgres behind nginx, and it deserves the same care as any production app — it’s easy to forget that because the UI feels so friendly. The agent rotates the secret key, makes sure debug flags are off, points SMTP at a proper relay, and sets up nightly database dumps with rotation and an offsite copy. Ask: Rotate Taiga’s secret key, confirm debug is off, and set up nightly Postgres backups to /backup with a 30-day rotation.
It will also show you the restore command it set up, not just the backup. This is the unglamorous work that saves you the day something breaks.
10. Clean Out Demo Data and Set the Defaults
Fresh installs ship with sample content and default settings that don’t match your region or team. The agent removes the sample project and demo users, sets the server timezone and locale in Taiga’s configuration, and documents where things live in the project wiki so the next person isn’t guessing. Ask: Delete the sample project and demo users, set the server timezone to Europe/Madrid, and write a wiki page documenting the backup location and restore steps.
New teammates inherit a clean, documented instance instead of archaeology.
Customizations like these are exactly what self-hosting is for — no vendor ticket, no waiting on a roadmap. Describe the change, watch the agent make it, and verify in the UI before rolling it out to the team.
