Case studies / Tigg Admin & ERP · Jul 2025 – Aug 2026
One release, not four dropdowns
Two ends of a Tigg tenant. In the admin console, a release tool the development team uses to test, deploy and run demos: one reviewed choice of release across selected workspaces. In the ERP portal, company creation rebuilt as five steps, with errors that find the person and Nepal-specific rules made correct.
Role
Timeline
Team
Platform
Not mine
Measured outcome
the key decision
Release is one reviewed batch action; the version control offers a single choice instead of four.
how deep do you want to go?
Two tools at either end of a tenant
Every Tigg customer is a tenant: its own workspace, its own features, and its own set of app versions. Two very different people touch that record.
- A business owner, once, when they sign up and create their company in the ERP portal.
- The development team, again and again, in the admin console, when they move workspaces to a new release to test it, deploy it or set up a demo.
This case covers one piece of each. In the admin console I designed and built Version Management, the screen the team uses to move tenants between releases. In the ERP portal I rebuilt company creation as a guided flow and fixed the Nepal-specific details that made it fail in quiet ways.
Both pieces are about the same thing: make the risky action narrow, and make errors impossible to miss.
Version Management: one release, not four dropdowns
Version Management was built for us, the development team. We needed one place to put a workspace on a new release to test it, roll it out, or prepare a demo. I built it over about three weeks in January and February 2026.
The first version asked the wrong question
Tigg ships several apps that are versioned separately: the accounting web app, the POS web app, a second POS product for a white-label partner, and the backend. My first version gave each one its own dropdown. The change only went through if all four pointed at the same release. If they didn't, you found out after pressing Apply.
In retrospect, that design offered far more combinations than were valid. A release is a bundle: its four versions were tested together. Four dropdowns let you build a mix that never shipped, and the only guard was an error afterwards.
Guarding the one button that matters
The modal has one commit point, Apply, and I put the guards around it:
- The workspace's current release is shown but disabled, tagged "Current", so a no-op change can't be sent.
- Apply stays disabled until the chosen release is different from the current one.
- The scope is written out above the cards: "Sagar Stores is selected", "12 organizations selected" or "All organizations will be updated".
- For a single workspace, the current release is preselected when all four versions match one release, so the starting point is visible and an accidental downgrade is harder.
Asset to add
Screenshot: Admin console → Version Management → Change version modal with one workspace selected, showing the Current and Latest tags (desktop, 2x PNG)
What red and green should mean
The version table colours each app version so the team can see at a glance who is on what. I got the meaning wrong the first time.
- 12 February 2026: only the latest release was marked, in green. Green meant "in sync with the newest".
- 20 April 2026: I added a second state. The latest release became red and the previous release, the stable one, became green.
So this was not simply a colour swap. Green changed from "newest" to "proven", and the newest release became something to treat with care. In retrospect, that is the right reading for a team that uses the newest release to test before it reaches everyone.
Reviewing it later, I found two problems of my own making. Colour is the only cue in the table, which fails for anyone who can't tell red from green. And the modal's "Latest" tag is still green, which contradicts the table. The fix is small: text tags ("Latest", "Stable") next to the colour, one shared colour pair, and a legend.
Company creation: steps by task, not by data type
On the other side of the tenant, a business owner creates their company in the ERP portal, often on a phone. Until July 2025 the form had three steps split by type of data: names and workspace address first, then accounting date, VAT, PAN and address, then logo, contact details and the terms. There was no choice of features, no review before submitting, and no clear moment of success.
In July 2025 I rebuilt it as five steps, each answering one question:
| Step | What the owner does |
|---|---|
| 1 · Details | Company name, industry, address, accounting start date, VAT registration, workspace name. Email, phone, PAN and website are folded into an optional "More information" block. |
| 2 · Features | Seven cards, each with a plain description: Track Inventory, Manufacturing, POS Retail, POS Restaurant, Multiple Locations, Multiple Warehouses, Multi-Currency. |
| 3 · Review | A summary of everything, plus the bot check, before anything is created. |
| 4 · Submitting | A loading state; any problems the server finds are listed field by field. |
| 5 · Finish | A short celebration and one button: "Go to my Organization". |
Some features depend on others. Choosing either POS adds Multiple Locations; choosing Manufacturing or Multiple Warehouses adds Track Inventory. Turning a prerequisite off removes what depends on it. Getting these rules right took three revisions; the second one tied inventory to the wrong feature, and I corrected it the same morning.
Asset to add
Screenshot: ERP portal → Add company → Accounting Features step with POS Retail selected and Multiple Locations added (phone width, 390 px, 2x PNG)
An error you cannot see
Folding the optional fields away made the first step shorter, but created a new failure. If the PAN in the folded block was wrong, pressing Next did nothing visible. In November 2025 I made the error find the person, in four steps:
- Reveal the folded block.
- Wait 300 ms, the length of its opening animation, so the field is really on screen.
- Scroll it to the centre of the view.
- Focus it, so the keyboard lands in the right place.
Nepal details are correctness, not polish
Two small fixes in the same flow mattered more than their size suggests.
- PAN is nine digits. The form accepted 9 to 12. Nepal's Inland Revenue Department issues a nine-digit PAN, so in November 2025 I changed the rule to exactly nine. A wrong tax number is easy to type and hard to notice later.
- An empty date must stay empty. The accounting start date uses a Bikram Sambat date picker. If you cleared the field and pressed Enter or Tab, the picker quietly filled in a default date again. That is worse than an error: it looks like your input. I fixed it in two passes (November 2025 and August 2026) so a cleared field closes and stays empty, and the "required" message can do its job.
The default accounting start date is set to mid-July because Nepal's fiscal year starts on Shrawan 1. Right now that default is a fixed date that someone has to update each year. Working it out from today's date is on my list.
Results and what I learned
Status. Version Management (the list, the release picker, the add-release form, the colour rule and the filters) is in production, built between January and May 2026. The five-step company creation, the feature rules, the error reveal, the PAN rule and both date-picker fixes are in production, built between July 2025 and August 2026. The development team uses Version Management to test, deploy and run demos.
Measured outcome: none. There is no record of how many workspaces were moved, of mistakes avoided, or of how many people finish company creation. If I measured one thing for each, it would be:
- For releases: how often a bulk change is rolled back.
- For company creation: where people leave the five steps, and how often a hidden error is revealed on Next.
Lessons
- 01
Narrow the dangerous control
Four fields that must agree are worse than one choice that can't be wrong. Show what the bundle contains before the person commits.
- 02
Colour needs a meaning, a legend and a second cue
I changed what green meant within ten weeks, and the modal still disagrees with the table. Words next to colours would have caught both problems.
- 03
Tell people when you change their choices
The feature step adds prerequisites silently. Next time I would add one line: 'Track Inventory was turned on because Multiple Warehouses needs it.'
States and edge cases
Version Management
| Situation | What happens |
|---|---|
| One workspace whose four versions match no release | Nothing is preselected; Apply needs an explicit choice. |
| The chosen release is the current one | The card is disabled and tagged "Current"; Apply stays off. |
| Selected rows, then "Select all organizations" | A toast shows while every workspace is gathered; the link then reads "Deselect all" and restores the earlier selection. |
| "Change All" | The scope line reads "All organizations will be updated". Apply is the only confirmation, which I would strengthen next with a typed or second confirmation. |
| Save fails | An error toast; the modal stays open with the choice intact. |
| Success | "Version updated", "Updated N organizations" or "All organizations updated", and the table refreshes. |
| No matching workspaces | "No namespaces found"; pagination is hidden. |
Creating a release
The add-release form shows two columns, V2 (new, editable, prefilled from the latest release) and V1 (the previous release, read-only). When you change a field under V2, only that field's old value moves across to V1, with a short arrow animation and a "was …" label. Fields you don't touch keep their V1 values. The helper text says exactly this, because the rule is not obvious: the two slots are rewritten field by field, not appended.
Company creation
| Situation | What happens |
|---|---|
| Error inside the folded optional block | Reveal, wait, scroll, focus (chapter 04). |
| PAN of 10 to 12 digits | Rejected; exactly nine digits are required. |
| Cleared date, then Enter or Tab | The picker closes and the field stays empty. |
| Workspace name already taken | Checked while typing ("Checking duplicate slug"). |
| Turning off a prerequisite | Its dependent features are removed too. The same rules run when a saved draft is loaded, so a draft can't hold an impossible set. |
| Server rejects a field on submit | The submitting step lists each field with its message. |
How it was built, and notes on sources
Building it
I designed and built the frontend for both pieces. The backend services that store releases, move workspaces and create companies were built by backend engineers; a reviewing engineer merged most of my changes. The admin console itself dates from 2023 and was built by other engineers; the three-step company form and its bot check came from teammates before my rebuild.
A few behaviours that shaped the experience:
- Filters and pages live in the address. In the admin console, the version table's filters (by app version, subscription status and partner) and its page are part of the URL, so a filtered view survives a reload and can be shared with a teammate.
- "Change All" is one request. An earlier version collected every workspace first and then sent the list. I removed that step, so updating everyone doesn't wait on gathering everyone.
- The release list is cached. Releases change rarely, so the list of releases is kept for an hour, while the table of workspaces refreshes after every change.
What I would do next
- Text tags and a legend for release colours; one colour pair across table and modal.
- A visible note when a feature prerequisite is added for you.
- Work out the default accounting start date from today's Bikram Sambat date instead of a fixed value.
- Put the logo upload back in the keyboard tab order on the details step.
Sources
This case is written from the shipped product and my own work history. There were no interviews or usability tests for these features, and no usage data. Where I give a reason that was not written down at the time, I say "in retrospect". Workspace names, version numbers and people in the figures are fictional.