Context
Triskelle Software Solutions is a consultancy that builds and maintains software for enterprise and government clients — often the kind of long-running relationships where a small request in 2003 turns into a twenty-year partnership. I spent five years there working across several long-running client engagements, with the largest share of my time going to a state-level special education compliance platform.
The Challenge
About 18 months into my tenure, the consultancy took on the special education compliance work. The requirements were unusual for a SaaS engagement: every interaction had to meet WCAG 2.0 AAA — the highest accessibility standard, not the more common AA. Every data model had to satisfy state-specific regulatory requirements that varied by jurisdiction. And every deployment had to pass government audits before going live.
On top of that, the software had to work for the actual humans using it: special education teachers, case managers, and administrators responsible for Individualized Education Programs (IEPs) and Individualized Family Service Plans (IFSPs). If the software failed them, students didn’t get the services they were legally entitled to. The stakes were higher than a typical enterprise application.
Approach & Architecture
We built one platform, four deployments.
Single stack, state-specific configuration. The application ran on C# with EF Core on the backend, TypeScript and Angular on the frontend, and Node microservices handling integration work. Every state got the same codebase — what varied was the compliance configuration layer: which forms existed, which fields were required, which workflows fired, which reports had to be generated. This let us ship new features to all four states simultaneously without forking.
Accessibility as a foundation, not a retrofit. WCAG 2.0 AAA can’t be added after the fact. We built every component from the ground up with keyboard navigation, semantic structure, ARIA patterns, color contrast, and screen reader support as non-negotiable requirements. A component was not considered “done” until it passed accessibility review.
Shared Angular component library. I invested heavily in an internal Angular component library used across every state’s deployment (and reused across other Triskelle client engagements). This wasn’t a theoretical win — as a consultancy shipping to multiple clients, every hour saved on scaffolding was an hour we could spend on the compliance logic that actually mattered. The library standardized our accessibility patterns so individual developers couldn’t accidentally regress AAA compliance on a new feature.
Key Contributions
IEP and IFSP management. Built the core workflows for creating, reviewing, and renewing Individualized Education Programs and Individualized Family Service Plans. These are the legal documents that govern what services a student receives, who delivers them, and how progress is measured. The forms are long, the validation is strict, and small mistakes have real consequences for students.
State-specific compliance logic. Each state had its own regulatory framework — different program types, different action items, different reporting cadences, different audit requirements. I designed and built the configuration layer that let one codebase serve all four states without any state needing to know the others existed.
Regulatory reporting. Built the reporting pipelines each state used to submit data to federal education authorities. Reports had to be correct, accessible, and generated on tight deadlines.
Shared component architecture. Created and maintained the Angular component library deployed across every state’s application, along with the shared modules and patterns that reduced time-to-ship on new features. This infrastructure outlasted any individual feature and was used across Triskelle’s broader client portfolio.
Agilent Technologies. Spent time on Triskelle’s longest-running engagement — Agilent’s Instruments Demo Division — contributing to platforms that manage over $60 million in global inventory and streamline financing request workflows across departments.
Technical Deep Dives
Accessible IEP forms. An IEP document can run to hundreds of fields across dozens of sections, with complex conditional logic: some fields only appear based on student age, disability category, or service type. Making that AAA-accessible was the hardest UX problem of the project. Screen reader users needed to navigate the form structure efficiently without drowning in announcements. Keyboard users needed predictable focus behavior as sections expanded and collapsed. Error states needed to be announced clearly without stealing focus mid-entry. We solved it with a strict separation between structural markup and visual styling, programmatic focus management tied to validation events, and live regions that announced changes without interrupting input. Every form interaction was tested with a screen reader before it was considered shippable.
One codebase, four jurisdictions. Serving four states from a single deployment without forking required a compliance configuration system strong enough to express the differences and a boundary discipline strict enough to keep them from leaking into shared code. State-specific behavior lived in declarative configuration — field definitions, workflow transitions, validation rules, report schemas — loaded at runtime based on the tenant. Shared code never branched on state. This invariant was tested aggressively, because the moment a single if (state === 'TX') appeared in shared code, the whole model would erode.
Impact
The platform has been deployed and actively used by special education departments across Texas, Maryland, Iowa, Nevada, Utah, and Colorado for managing student compliance, documentation, and regulatory reporting. The shared Angular component library I built became the foundation for future Triskelle client projects, reducing delivery timelines and maintaining consistency across engagements that extended well beyond the special education work.
Reflections
Consulting at this level teaches you that constraints aren’t obstacles — they’re the product. A “simpler” spec without AAA accessibility or without strict state-by-state compliance would’ve been a different product, one that didn’t actually solve the problem. Every constraint I resented at the time turned out to be load-bearing.
Building the component library early was the single highest-leverage decision. It felt like overhead on day one and looked like a force multiplier by month six. I now start every new long-running project with a shared component layer, even when the short-term pressure is to just ship the feature.
Accessibility isn’t a frontend concern — it’s an architecture concern. You can’t bolt AAA compliance onto a system that wasn’t built for it. Treat it as foundational from the first component or accept that you’ll rewrite the frontend later.