Multi-tenant SaaS for the software development lifecycle
Plan the work. Govern every deployment.
Epics, sprints and boards on one side. On the other, a change-governance workflow that carries every release from development to production with committee authorization, install evidence and a full audit trail.
- Tenant isolation on three layers
- Append-only audit log
- Spanish and English
11
Governed deployment phases
11
Work item types
3
Tenant isolation layers
2
Interface languages
Capabilities
Everything the delivery cycle needs, in one place
Planning, execution and governance share one data model, so a task, the sprint it belongs to and the release that ships it are never three disconnected tools telling three different stories.
Configurable work items
Epic, Feature, PBI and Task, plus Bug, Issue, Impediment and Support. States, transitions and required fields are defined per tenant, not fixed by us.
Boards and backlog
Drag a card and the workflow decides whether the move is legal. Illegal transitions are refused with a reason instead of silently accepted.
Sprints and capacity
Plan by real availability: team calendars, per-person capacity and burndown computed from the history, not from a manually updated field.
Reports that answer why
Flow bottlenecks, cumulative flow, on-time delivery graded from the actual transition history — so a report says what happened and where, not just how many.
Business Case and investment
Tie delivery to the business: owner area, cost centre, investment amount and the deployments that spent it, on the same record.
Roles with real boundaries
Atomic permissions, deny by default. The project manager governs the work; the tenant administrator governs the system — and neither can grant itself the other's authority.
Dynamic control
The process bends to your organization
Workflows, states and field rules live in configuration, not in our source code. Two tenants on the same platform can run genuinely different processes — and change them without waiting for a release.
- Per-tenant state machines Add a state, reroute a transition, require a comment on the ones that matter. Each transition keeps a named reason derived from the pair it connects.
- Field policies by state Decide which fields are required, editable or frozen in each state, so data quality is enforced at the moment of the change.
- Configurable roles and plans Functional roles are editable templates, and each plan decides which modules a workspace can reach.
Any sector
Not built for one industry — built to take the shape of yours
Every organization that ships change needs the same three things: a way to track what is happening, one place where the information lives, and evidence of who approved what. What differs between industries is the process — and here the process is configuration, not our source code.
One place for the information
When the request, the work, the approval and the evidence live on separate tools, reconciling them becomes somebody's job. Here they are the same record, so there is nothing to reconcile.
A method, not a habit
A workflow the software enforces gives every team the same steps. It stops depending on who is on shift, and it survives the person who used to remember how it was done.
Answers when they are asked for
What shipped, when, who authorized it and what happened next — reconstructable from the record itself, whether the question comes from an auditor, a client or the board.
The sectors above are examples, not packaged templates: what adapts is the workflow, the states, the field rules and the roles, configured per workspace.
Change governance
Every release passes through the same gates
Not a status field someone remembers to update — a state machine. Each phase has an owner role and an exit requirement, and the transitions that matter demand a written reason before they are allowed.
- 1 New
- 2 Development
- 3 Code Review
- 4 Test
- 5 To Committee
- 6 Committee Authorized
- 7 Installed Pre
- 8 To Committee Prod
- 9 Committee Prod Authorized
- 10 Installed Prod
- 11 Done
A committee, not a checkbox
Production is authorized by a named approver holding the role — twice, once for Pre and again for Prod. The decision, the approver and the moment are all recorded.
Evidence, not assurances
Install evidence is attached to the phase it belongs to, so an auditor can reconstruct what shipped, when, and who signed it off.
Rollbacks open their own bug
A production rollback demands a mandatory reason and generates a severity-1 bug linked to the deployment. Failure is recorded, never quietly retried.
Where it fits
A tracker plans work. A pipeline ships code. Neither governs the change.
Most teams end up with both, plus a spreadsheet and an email thread holding the approvals. DevGov keeps the approval, the evidence and the work item on the same record.
Swipe the table sideways to see every column.
| Capability | Issue tracker | CI/CD pipeline | DevGov |
|---|---|---|---|
| Backlog, boards and sprints | Native | Outside its purpose | Native |
| Automated build and deploy execution | Outside its purpose | Native | Native |
| Change committee authorization by role | Usually added on | Usually added on | Native |
| Pre and Production install evidence on the record | Usually added on | Usually added on | Native |
| Rollback opens a linked severity-1 bug automatically | Outside its purpose | Outside its purpose | Native |
| Per-tenant workflow and field policy configuration | Usually added on | Outside its purpose | Native |
| Append-only audit log across work and releases | Usually added on | Usually added on | Native |
This compares what each category of tool does out of the box. Many products in the first two columns can cover the remaining rows through plugins, integrations or custom work — the difference is whether it arrives assembled and governed, or has to be built and maintained by you.
Isolated by subdomain
Each workspace answers on its own subdomain, and every query is scoped to its tenant at the repository layer — not by remembering to add a filter.
Append-only audit
State changes, phase transitions, permission changes and denied access are all recorded. The application never updates or deletes an audit row.
Hardened by default
Deny-by-default permissions, per-endpoint ownership checks, rate limiting on sensitive routes and a content policy that forbids inline script.
Installs on your phone
The workspace can be installed as an app on Android, iOS and desktop, with offline support and its own update channel.
About and legal
What the platform is, and the terms that govern using it
DevGov
A multi-tenant SaaS for the software development lifecycle — work items from Epic down to Task, plus a first-class Deployment module that governs every release through committee approval and install evidence.
Our mission
Give every team a single, auditable source of truth for what's being built and what's being deployed — without forcing everyone onto the same rigid process.
Vision
A place where "who approved this?" and "what changed?" always have an immediate, trustworthy answer — for a team of ten or an organization running dozens of tenants side by side.
Reach
From the first backlog item to the last install in Production — one platform for planning, building, reviewing and shipping, instead of stitching several disconnected tools together.
What we value
Tenant isolation
Every query, every write, every file — scoped to your tenant at every layer, not just the login screen.
Traceability
Every state change, every deployment phase, every permission edit — appended to an audit trail nobody can quietly rewrite.
Adaptability
Work item states, roles, and workflows are configurable per tenant — the platform bends to your process, not the other way around.
Accountability
A committee decision, a permission grant, a role change — always made by one identifiable person, never anonymous and never automated.
Built to scale
Cursor-paginated lists and anti-N+1 query patterns throughout — a project with ten work items and one with ten thousand behave the same way.
No proprietary lock-in
Standard, well-understood building blocks — MySQL, JWT, bcrypt — instead of a proprietary black box only the platform operator can reason about.
What makes it different
A real change-governance workflow
The Deployment module takes a change through 9 phases — development, review, committee authorization, Pre and Prod install evidence — with rollback-triggered bugs generated automatically.
The full work-item hierarchy
Epic → Feature → PBI/User Story → Task, plus Bug, Issue, Impediment, PreRelease Defect, and Support — one backlog, not five disconnected trackers.
Roles that match how you actually govern
Tenant Admin governs the system; SCRUM/PM governs the work. Functional roles — PO, Tech Lead, QA, Release Manager, Committee Approver — are editable templates, not fixed labels.
An audit log that can't be edited
Append-only by design — no UPDATE, no DELETE, from inside the app. What happened, happened.
Bilingual from day one
Every screen — including this one — is available in Spanish and English, switchable at any time, not translated as an afterthought.
Security aligned with OWASP and NIST, from day one
Every change is reasoned through against the OWASP Top 10 before it ships, and the platform's own controls — access, encryption, audit logging — are built around NIST's guidance from the start, not added on afterward. See "Información Legal" → "3. Data security" for the specifics.
Built for
One record serves all four: the team plans on it, the committee authorizes on it, the auditor reads it back, and the business sees what the investment bought — instead of four tools that have to be reconciled.
By using DevGov, you and your organization accept the terms below. This page is for your tenant's own reference — it doesn't replace a signed order form or master services agreement, if one exists between your organization and the platform operator.
Last reviewed: 10 Aug 2026
1.1 Acceptance
Signing in to a tenant workspace means you accept these terms on behalf of yourself and, where applicable, your organization.
1.2 Permitted use
- Managing your organization's own work items, deployments, and project data.
- Inviting and managing accounts that belong to your own tenant.
- Using the API and integrations for your own tenant's data only.
1.3 Prohibited use
- Attempting to access another tenant's data, accounts, or configuration.
- Probing, scanning, or attempting to bypass authentication, rate limits, or tenant isolation.
- Uploading unlawful content or content that infringes a third party's rights.
1.4 Account responsibilities
You're responsible for activity under your account. Enable multi-factor authentication where it's offered, and report a suspected compromise to your Tenant Admin immediately.
2.1 Data we collect
- Account data: name, email, timezone, language preference, avatar.
- Work data: the work items, deployments, comments, and attachments you and your team create.
- Usage and security data: sign-in history, IP address, and session metadata, kept for audit and abuse prevention.
2.2 How we use it
Solely to operate the platform for your tenant: authentication, the features you use, email/queue notifications you're subscribed to, and the security controls described below.
2.3 Sharing with third parties
Never sold. Shared only with the sub-processors strictly needed to run the service (e.g. outbound email delivery, and any integration your tenant explicitly connects, such as source control).
2.4 Data retention
Kept for as long as your tenant subscription is active, plus a limited period for backups and legal obligations. Deleted records are soft-deleted first, then purged on a schedule.
2.5 Your rights
You can review and correct your own profile at any time from Mi Perfil. For export or deletion requests beyond that, contact your Tenant Admin or platform support.
2.6 Cookies and local storage
Only what's needed to keep you signed in and the interface usable: an essential session cookie, a CSRF-protection token, and a small preference cookie for your chosen language. None of these are used for advertising or cross-site tracking, and none are set until you actually sign in.
These aren't marketing claims — they're the controls this platform actually implements.
- 3.1 Encryption in transit— HTTPS everywhere, no exceptions.
- 3.2 Encryption at rest— Database and file storage encrypted at the infrastructure level.
- 3.3 Multi-tenant isolation— Every query is tenant-scoped at the repository layer, not just the login screen.
- 3.4 Authentication— JWT access + refresh tokens, bcrypt-hashed passwords, optional TOTP multi-factor authentication.
- 3.5 Audit logging— Append-only trail of state transitions, permission changes, and denied access — never edited or deleted from inside the app.
- 3.6 Rate limiting— Sliding-window throttling on login, password, and other sensitive endpoints.
- 3.7 OWASP-aligned development— Every change is reasoned through against the OWASP Top 10 before it ships: parameterized queries only, no raw SQL string interpolation, CSRF tokens on every state-changing form, and server-side sanitization of any content that gets rendered back to another user.
- 3.8 Least-privilege access— Every endpoint checks a specific permission before acting, and denies by default — a missing grant means no access, never an open door.
- 3.9 NIST-aligned controls— Beyond OWASP's application-layer checklist, access control, audit trails, and cryptographic protections are reasoned through against the control families in NIST SP 800-53 and the NIST Cybersecurity Framework (identify, protect, detect, respond, recover) — defense in depth, not a single layer.
Found a security issue? Report it responsibly to your Tenant Admin or platform support before disclosing it anywhere else — we take these seriously and will follow up.
4.1 Platform ownership
The DevGov software, design, and branding belong to the platform operator. These terms don't transfer any of that to you or your organization.
4.2 Your data stays yours
Every work item, deployment record, comment, and attachment your tenant creates belongs to your organization.
4.3 Limited license to operate the service
You grant the platform the narrow license needed to store, process, and display your data back to you — nothing broader, and never for training or resale.
4.4 User-uploaded content
Every file, attachment, or other piece of content a user uploads belongs entirely to that user (or their organization) — never to the platform operator. Uploading it is that user's own responsibility: making sure they have the right to upload it, and that it doesn't infringe anyone else's rights or break any applicable law. The platform operator doesn't review uploaded content before it's stored, doesn't claim any ownership over it, and isn't responsible for its legality, accuracy, or the consequences of someone choosing to upload it — see §5.3.
5.1 Service availability
We aim for high availability but don't guarantee an uninterrupted service; maintenance windows and incidents can happen.
5.2 No implied warranties
The platform is provided on an "as is" basis, to the extent permitted by applicable law.
5.3 Limit of liability
Liability for any claim related to the service is limited to what's set out in your organization's own agreement with the platform operator, where one exists. In particular, the platform operator isn't liable for:
- Outages or slowdowns caused by your own network, browser, or local device.
- Failures of a third-party service your tenant has connected — an identity provider, source-control host, or email relay.
- Misuse of the platform, including sharing credentials, disabling multi-factor authentication where it was offered, or misconfiguring roles and permissions.
- Force majeure events beyond reasonable control, including third-party cyberattacks against the underlying infrastructure.
- Content a tenant's own users upload — see §4.4; it belongs to, and is the sole responsibility of, whoever uploaded it, never the platform operator.
- Any other matter genuinely outside the platform operator's reasonable control, including your organization's own configuration choices, your users' own actions, or the behavior of a third-party system or service.
5.4 Your responsibility
Keeping accurate work-item and deployment data, and using access controls correctly, is your organization's own responsibility.
6.1 No automated decisions on your data
Every decision that governs your work stays human: a committee authorization is always made by a specific Committee Approver, a permission grant always by a Tenant Admin, a work-item state change by whoever moved it. DevGov does not use AI to approve, reject, or otherwise decide on your behalf.
6.2 If AI-assisted features are ever added
Any future feature that uses AI to summarize, suggest, or draft content inside the platform would be clearly labelled as such where it appears, and would be opt-in rather than silently enabled — this document would be updated first.
6.3 Your data is never used to train third-party models
Work items, comments, attachments, and any other tenant data are never sent to a third-party AI provider for model training, with or without identifying details removed, without your organization's explicit, separate consent.
6.4 AI-assisted software development
The platform's own engineering team may use AI-assisted tools while building and maintaining DevGov, the same way many software teams do — every change those tools help produce still goes through the same human review, security checklist, and testing as any other change before it ships.
7.1 Primary governing law
These terms, and any dispute arising from your use of DevGov, are governed by the laws of the Republic of Guatemala, without regard to conflict-of-law rules — the jurisdiction where the platform operator is established — unless your organization's own signed agreement with the platform operator states otherwise.
7.2 Users elsewhere in Latin America
For tenants and users located elsewhere in Latin America, Guatemalan law governs everything these terms don't expressly address — but nothing here overrides a consumer- or data-protection right you hold under your own country's law that can't lawfully be waived.
7.3 Users in México and Canadá
If you access the platform from México or Canadá, nothing in these terms limits any non-waivable right you hold under the Ley Federal de Protección de Datos Personales en Posesión de los Particulares (México) or the Personal Information Protection and Electronic Documents Act (Canadá) — those rights apply exactly as your own local law grants them, alongside these terms, not instead of them.
7.4 Special note for users in the United States
The platform operator is not established in, does not direct its activities toward, and does not conduct regular business in the United States. Nothing in these terms should be read as consenting to the personal jurisdiction of a United States federal or state court, as a general submission to United States regulatory authority, or as accepting any liability the platform operator wouldn't otherwise have under the law that actually governs these terms (§7.1). Any right a United States-based user holds that can't lawfully be waived remains unaffected, subject to §7.5 below.
7.5 Dispute resolution and arbitration
Tell us first — reach out using the contact details in §8, in good faith, before filing anything formal; most disagreements resolve faster that way. If that doesn't resolve the matter within 30 days, any dispute, claim, or controversy arising from or relating to these terms or your use of the platform — including a claim that these terms are void or voidable — is resolved by binding arbitration under the rules of the Centro de Arbitraje y Conciliación de la Cámara de Comercio de Guatemala (CENAC) in effect when the arbitration is filed, seated in Guatemala City, conducted in Spanish, rather than in court, except where applicable law doesn't allow a given dispute to be arbitrated.
Arbitration proceeds only on an individual basis — never as a class, consolidated, or representative action, and the arbitrator has no authority to combine your claim with anyone else's. Each side normally bears its own costs; if the arbitrator finds a claim was brought in bad faith or for an improper purpose — to pressure a settlement rather than resolve a genuine grievance, for instance — the arbitrator may award reasonable costs and fees to the other side. Nothing here waives a right that applicable law doesn't allow an arbitration clause to waive.
Questions about these terms, or a request related to your own data, go to your Tenant Admin first — for anything that needs the platform operator directly:
Bring your releases under the same roof as your work
Sign in to your workspace, or reach the administrator of your organization to have one opened for you.