Our role
Independent technical supervision and advisory partner. Not the developer — the party checking the developer’s work on the client’s behalf.
The brief
How does an institution check work it does not have the staff to check?
The Arab Urban Development Institute is building the Arab Cities Academy — a digital learning platform intended to strengthen the capacity of municipalities and urban development professionals across the Arab region, over a horizon measured in years rather than releases. Certification tracks, professional development pathways, self-paced courses, and institutional programs for partner cities, all on infrastructure AUDI will own and operate long after the build ends.
An institute of urban development specialists does not employ solution architects. AUDI had commissioned an implementation vendor and had a clear vision of what it wanted, but no in-house technical authority to answer the questions that determine whether a platform lasts: is this architecture defensible in five years, or convenient today? Is this requirements document specific enough to build from, or specific enough only to sign? Does this recommendation follow from analysis, or does the analysis follow from the recommendation?
Those questions cannot be asked by the party being paid to build. They also cannot be asked by a client who lacks the vocabulary. That gap is what independent technical supervision exists to fill.
What we do
Ask the questions the client cannot, of the party that should not be asked to ask them.
ISEET reviews and validates every vendor deliverable against approved scope, holds the architectural position, gates the decisions that are expensive to reverse, and reports to AUDI leadership on a fixed cadence. ISEET does not write code, does not manage the vendor day to day, and does not make legal determinations.
01 / Baseline
Established what good would look like, before there was anything to judge
The engagement opened with an inception phase that produced the framework everything since has been measured against: a governance model, a risk register maintained through every reporting cycle, and a six-stage deliverable validation and acceptance workflow — vendor submission, completeness check, technical and functional review, gap and risk identification, formal feedback, re-validation. Eight comparable platforms were benchmarked to establish what the Academy was being built against rather than in isolation. Setting the standard before the first deliverable arrives is what makes later review a matter of evidence rather than opinion.
02 / Position
Held an architectural position long enough for it to matter
ISEET recommended, and AUDI adopted, a platform-led three-layer architecture: a public website, a bespoke application layer, and the learning engine, kept as three distinct layers on three distinct subdomains. Enrollment and commercial authority sit in the bespoke layer. The learning engine delivers learning and nothing else. When a two-layer alternative was proposed, the position held. It is the decision with the longest reach in the whole engagement — it is what makes the learning engine replaceable rather than load-bearing, and why a payment integration discussion eight months later opened from a settled premise rather than a debate. Architecture is only worth recommending if someone is still holding it when the pressure to simplify arrives.
03 / Gate
Made approval a gate rather than a formality
Two decisions were governed rather than waved through. The learning engine recommendation arrived as a comparison document that read as pre-concluded — no weighted evaluation matrix mapped to requirements, no treatment of paid alternatives, no total cost of ownership, no version evidence, and a multi-tenancy claim asserted by naming a product rather than by mapping it to AUDI’s municipality model. ISEET did not reject the recommendation; it judged the engine plausibly correct. It returned the document against a structured requirement set and issued a formal advisory note giving conditional endorsement. AUDI confirmed the decision two days later. The engine chosen was probably the same either way — what changed is that AUDI now holds a decision it can defend to its board, its funders, and an auditor. The requirements baseline was handled the same way. Review found the document did not yet constitute something testable: insufficient functional detail per portal and role, missing end-to-end workflows and validation rules, underdeveloped non-functional requirements, no compliance matrix back to the terms of reference, and no process maps. Rather than approve conditionally and hope, ISEET defined a set of deliverables required before sign-off — multi-tenancy design mapped to AUDI’s scaling profile, performance targets with load-test evidence, high-fidelity mockups across all user journeys, a five-year hosting architecture with cost projection, and the commerce architecture specification.
04 / Oversee
Review what arrives, and find what nobody else is looking for
Review is continuous rather than milestone-bound. Across a single month, three rounds of structured design feedback produced 47 categorized review items spanning information architecture, content readiness, integration, user experience, visual design, governance, and function. AUDI leadership receives an executive brief on a fixed cadence carrying progress, deliverable status, the risk register, and the decisions required of them. Two examples show what continuous review catches. The Academy’s domain was found to be redirecting to an address that does not exist at the registry level — ISEET traced it through authoritative DNS analysis and response headers to a configuration inside the vendor’s stack, established that the client-side records were correct, and specified the corrections. Nobody else was checking, and the configuration was believed to be correct. Separately, ISEET identified that the proposed first-year hosting arrangement would leave AUDI to establish its own account and migrate every system and data set at renewal, and established that portability depends on receiving the repository, dependency manifest, and environment configuration rather than credentials alone. That risk is now in front of AUDI leadership with defined remedies, well before it would otherwise have surfaced as a migration bill and a negotiating position.
Both diagrams are ISEET’s own independent analysis from the inception phase, not design deliverables. Left: the validation workflow. Right: the learner journey across the three layers.
The vendor believed the configuration was correct. The client had no way to know otherwise. That gap is the entire job.
ISEET lead advisor
Where it stands
In development, under governance.
The platform is in development and has not launched. This engagement is live, and the case study describes a method rather than a finished result.
What can be said is what governance has produced so far. The architectural position adopted at inception still governs decisions being taken now. The learning engine selection is documented and defensible rather than asserted. The requirements baseline is gated on defined evidence rather than approved on trust. Asset ownership, hosting, domain control, and payment account arrangements have been raised as questions of principle early enough to be decided rather than inherited.
47
Structured review items issued on design deliverables in one month
4
Executive briefs to leadership across six months
3
Formal review cycles on the requirements baseline
Supervision is the one professional service that looks like nothing when it works. There is no artifact at the end that ISEET built, and the strongest evidence of value is a set of expensive problems that did not happen. What AUDI holds instead is a documented decision trail — every significant architectural and commercial choice made against stated criteria, recorded, and defensible to whoever asks next.
The principle behind this
Supervision only means something when the supervisor has nothing to gain from the build going easy. ISEET holds no development role on this platform and no commercial interest in the vendor’s performance.
December 2025 – present
Architecture review · Requirements governance · Vendor deliverable validation · Risk management · Advisory to leadership
Six-stage deliverable validation workflow · maintained risk register · fixed-cadence executive reporting
An independent implementation vendor, contracted separately by AUDI
ISEET is not the platform developer — no coding, no day-to-day vendor management, no legal determinations
Considering something similar?
If a vendor is delivering against your contract, somebody independent should be reading what arrives. That conversation is free.
December 2025 – present
Architecture review · Requirements governance · Vendor deliverable validation · Risk management · Advisory to leadership
Six-stage deliverable validation workflow · maintained risk register · fixed-cadence executive reporting
An independent implementation vendor, contracted separately by AUDI
ISEET is not the platform developer — no coding, no day-to-day vendor management, no legal determinations
The platform behind this
Immunify is a product, not a bespoke build: six modules covering stock, cold chain, temperature, workforce, learning, and reporting.