This is the case study that, four years later, anchors every conversation we have with a new client. So it's worth telling properly — not as a pitch, but as the engineering story behind it. What problem we were actually solving. What we built. What broke. And what we'd do differently if we shipped it again next week.
The brief that wasn't really a brief
IGBS — the International Group for Business Solutions — is Egypt's largest intellectual property and trademark agency. They handle filings, renewals, and disputes for over 4,500 enterprise clients, including roughly 17,000 active trademark records at any given moment. Multinationals. Local conglomerates. Pharma. Banks. The kind of clientele that doesn't tolerate missed filing deadlines.
When we first sat with their team, the brief was: "We need a website."
The actual problem, after one site visit, was something different entirely. The website was the smallest issue. The real situation was this: twenty years of trademark operations were running on a hybrid of Excel spreadsheets, paper case files, a 12-year-old desktop database that nobody fully understood, and the memory of three or four indispensable people. Renewals were being tracked in three places. Client communications lived in shared Outlook PST files. Payroll, vault management, and case status all touched the same records but lived in different tools that didn't talk to each other.
The day before we walked in, a deadline-week incident had cost them a six-figure reconciliation problem: 3,000 renewal notices that should have gone out hadn't, because the spreadsheet that triggered them was being edited by someone else. They didn't need a website. They needed an operating system.
The actual scope, in numbers
That's the system today. When we started, none of those numbers existed in a queryable form. The first month of the project was archaeology — figuring out what the actual data model needed to be by sitting next to operators and watching what they did, then reverse-engineering the records they kept in their heads.
The architecture decision that mattered most
Most Cairo agencies — when they get a brief like "we need an internal system" — reach for one of three things: WordPress with custom plugins, a low-code platform like Bubble or Webflow CMS, or a Laravel/PHP monolith pinned to a single tenant. All three of those decisions would have killed this project by year two.
The choice that made everything else possible was: build it as a multi-tenant system from day one, with proper role-based access at the database layer, on a stack we could maintain ourselves indefinitely. We went with React + Node, hosted on Cloudflare's edge for the front, with a Postgres database designed around tenant isolation at the row level.
That sentence is one paragraph. The implications were the whole project.
What multi-tenant from day one bought us
- 5 languages with no schema duplication. Arabic, English, French, Russian, Chinese — same records, same indexes. Language is a column, not a database.
- Role-based views without forking the code. A junior examiner sees a different dashboard than a partner. Same backend. No "Pro version" branch nightmare.
- Per-client data isolation that audits clean. When an enterprise client asks "who at IGBS accessed our records last month," we have an answer with a SQL query, not a panicked all-hands.
- Onboarding new clients is a database insert. Not a deployment.
It's also why, four years later, we've made zero rebuilds. The shape was right from the start.
The hard part of a custom system isn't the features.
It's choosing the shape that won't betray you in year three.
What we actually built (the eight modules)
By the time we shipped, the portal had eight distinct modules, all sharing the same database and authentication layer:
1. The case management spine
Every trademark, every renewal date, every status change — tied to a client, tied to an examiner, tied to a country. Search by anything, filter by anything. This replaced four separate tools and is what 80% of the daily work happens in.
2. The client portal
External clients log in and see their own trademarks, renewal calendars, invoices, and document vault. It's the single biggest retention tool IGBS has. A client who can see their portfolio at any time doesn't shop around at renewal.
3. The renewal engine
Automated reminders at 90, 60, 30, and 14 days. The exact problem that triggered the original brief — the missed renewals — has not happened once since this went live. That alone paid back the build.
4. The payroll + commission layer
IGBS's examiners get base salary plus per-case commissions across tiers. The system computes monthly settlement automatically. Removed about 40 hours of finance work per month and ended the "I'm owed more" arguments at end-of-month.
5. The vault
Encrypted document storage for client originals — power of attorney forms, signed declarations, certified translations. Versioned, audit-logged, downloadable as a zip per client per quarter.
6. The disbursements module
Loans to clients to cover foreign filing fees, tracked separately from regular invoicing, with full reconciliation against the bank export. This is the most boring module and the one that saves the most accountant-hours.
7. The reporting layer
Board pack auto-generated weekly. Filings by country, renewals by quarter, revenue by client, examiner load distribution. Exported as PDF and editable PowerPoint. The COO stopped working Saturdays in month three.
8. The internal messaging system
Replaced the Outlook chaos with thread-based conversations tied to specific cases. A new hire reads the case thread and is up to speed in 20 minutes instead of two weeks.
What broke (and why we kept the wins anyway)
Honest section. Not everything went smoothly. Three things we'd do differently:
1. The first export-to-PDF system was a disaster. We initially used a headless browser running in production to generate board packs. It worked at small scale, then queued up under load and brought the API down twice. Replaced it with a templated rendering service running in a separate worker. Lesson: don't put browser rendering in the request path. Ever.
2. We underestimated bilingual data entry. Examiners in Cairo type case notes in Arabic. Examiners in Dubai type them in English. The first version assumed one language per record. We had to retrofit a per-field language tag. Two weeks of work that could have been three lines of schema at the start.
3. The role permission matrix grew faster than we expected. Started with 4 roles. By year two there were 11. By year three we'd added a per-team override layer because "all senior examiners can see X, except this one team" became a regular request. We rebuilt the permission system once in year two. It would have been cheaper to design it as a policy engine from the start.
None of those broke the project. They all cost time. The architecture decision — multi-tenant, owned codebase, generic data layer — is what made the fixes possible without rebuilds.
What this project actually cost (in real engineering hours)
Roughly 1,400 engineering hours over 14 weeks. Three phases: 4 weeks of discovery and data modelling, 8 weeks of module shipping (modules released weekly, used by IGBS staff during the build), and 2 weeks of handover, training, and data migration from the legacy tools.
Then four years of maintenance — averaging about 4 hours a month of small fixes, schema additions, and one bigger feature push per year. The system has had zero major outages, zero data loss events, and zero rebuilds. The same client today would be at year five with a system that hasn't aged into legacy. That's the upside of designing for time.
What this proves for the next build
The IGBS portal is now the proof point we lean on for every operations-system conversation we have — clinics, real estate developers, professional services firms. Different domain layers, same engineering. The hard part — a multi-team, multi-language, multi-tenant ops system that doesn't break at scale — is solved. The new part on any future build is just the domain.
If you're sitting on a similar situation — twenty years of operations running on Excel that you can feel are about to crack — the build itself is shorter than you think (10–12 weeks for most domains). The decision that takes longer is committing to the right shape. We've done that part now, four years over.