In August 2014 I was 27 years old, living in Amman, and I did the thing every sensible person tells you not to do: I founded a software company. Not a SaaS side project. A healthcare software consultancy that would end up deploying a full Electronic Health Record system to Prince Sultan Cardiac Centre in Al-Ahsa, Saudi Arabia.

We called it AFAQ. Twelve engineers. Real hospitals. Real patients. I was Founder, CTO, Principal Engineer, Product Manager, Acting CEO, IT Manager, and Development Manager — simultaneously, on the same business card, with the same salary (which was effectively zero for the first year).

Nobody warned me that “Chief Everything Officer” is a job description that will age you in dog years.

What AFAQ actually built

We built an EHR/EMR platform — clinical, administrative, and financial modules, with full ERP capabilities bolted on. The idea was that a hospital shouldn’t need seven different vendors for seven different systems. We’d ship one coherent platform, Jordan-built, deployed to Gulf healthcare facilities that were mid-upgrade-cycle from paper-and-legacy to something modern.

The stack was not minimal. Java EE. Spring Boot, Spring Security, Spring WS. Hibernate with JPA. On the frontend: GWT (Google Web Toolkit) for the heavy clinical interfaces, AngularJS and Bootstrap for the administrative ones. Talend for ETL. Tomcat and WildFly as app servers. PHP with Symfony and Yii for integrations. MySQL and Oracle as primary databases. HL7 and FHIR for interoperability.

That’s a lot. That’s too much for a twelve-person team. We shipped it anyway, because when you’re the one who sold the contract you don’t get to complain about the scope.

The database connector nobody else was writing

Here’s the part I’m still proud of: we wrote new database connectors for fis GT.M.

If you haven’t heard of GT.M — you’re not alone and that’s the point. GT.M is a hierarchical NoSQL database that runs inside VistA, the VA’s open-source EHR system that’s been deployed across American veterans’ hospitals since the 1990s. It runs on a language called MUMPS (now called M). Its access patterns are ancient, its tooling is sparse, and the documentation assumes you already know the system’s four-decade context.

Nobody was writing modern database connectors for GT.M in 2015. We did, because AFAQ’s platform needed to interface with hospital systems running GT.M infrastructure — and “we’ll route around it” wasn’t an option when your client’s pharmacy and billing data lives inside it. So I sat down, read the GT.M programmers’ guide, read the MUMPS specification, and wrote connectors that made GT.M behave like something you could call from a modern Java service.

Most engineers will never write a database connector in their careers. Most of the ones who do will write one for Postgres or MySQL, where every question has a Stack Overflow answer. Writing a connector for GT.M in 2015 meant reading source code and mailing lists from people who’d been doing this since before I was born.

Twelve engineers, one org chart that made no sense

Managing twelve engineers while simultaneously being the principal engineer on the product is a coordination problem that doesn’t have a clean answer. You’re supposed to delegate technical decisions. You’re also supposed to make them faster than anyone else on the team because you’re the one on the hook for the contract. Those two things fight each other constantly.

What I learned: the constraint that matters most in a small consultancy isn’t technical, it’s specificity of scope per person. Every engineer needs a single thing they own and are responsible for. The moment two engineers are both “working on the clinical module,” you have a merging problem and a communication overhead that will eat your sprint.

We ran lean domain ownership before it was a blog-post concept. The billing engineer owned billing. The pharmacy engineer owned pharmacy. I owned the architecture decisions that crossed those lines, and I made exactly two of them per month, max, because every cross-cutting decision is a context-switch tax on everyone.

What KPI analysis looked like in a cardiac hospital deployment

Before go-live at Prince Sultan Cardiac Centre, we ran KPI analysis and implementation across their clinical workflows. That sounds abstract. Here’s what it means concretely.

A cardiac centre cares about: door-to-balloon time (how long from chest pain to intervention), medication reconciliation errors, duplicate test orders, patient-ID mismatches between departments. These are not theoretical KPIs. They’re life-and-safety KPIs. Getting the reporting wrong doesn’t produce a bad quarterly review — it produces a clinical audit you don’t want to be named in.

So we sat with their clinical leads, mapped their existing paper-based and legacy-system workflows, and then built reporting pipelines in our EHR that surfaced the right numbers in the right place. Talend ETL did the heavy lifting for transformations between their legacy data and our models. HL7 messages carried the interoperability layer.

The go-live wasn’t a dramatic moment. It was a Tuesday. A few nurses asked where the button moved. That’s how you know it went well.

What AFAQ was really for

AFAQ lasted from August 2014 to January 2017. Two and a half years. We shipped. We had clients. We had running systems in production hospitals.

But AFAQ was less a company than it was a forge. Twelve engineers who came in knowing Java or PHP and left knowing how healthcare data models work, why HL7 exists, how you negotiate a contract with a hospital IT department that has twelve layers of approval, and what it costs to be wrong about an assumption at the data-model layer when your production database is Oracle and your client is a cardiac hospital in Saudi Arabia.

I came out of AFAQ with a very specific set of opinions. That healthcare software is harder than enterprise software in ways that have nothing to do with the code. That a twelve-person team is large enough to produce real systems and small enough to still be fragile in ways a hundred-person company isn’t. That writing a database connector for a 1980s hierarchical database is a better education in data modeling than any course you’ll take.

The business card with six job titles was chaotic. The systems we shipped were not. That was the whole point.