Why I Build: Technology Because It Didn't Exist

For most of my career, I have built things because they did not exist.

Not because I wanted to be a builder. Not because I was fascinated by technology for its own sake. But because I encountered problems that mattered, and the tools to solve them did not yet exist.

The Problem Comes First

When I started working in prehospital medicine and critical care, I needed a way to teach point-of-care ultrasound to clinicians across countries and contexts. The textbooks were good. The protocols existed. But there was no platform that made this knowledge accessible to a paramedic in Bangladesh or a nurse in rural Uganda.

So, together with Erik Sloth and Thomas Fichtner Bendtsen, we built USabcd.org.

I did not know if we could. We had no formal training in building educational platforms. But we knew the problem intimately — we lived it every day. We knew exactly what clinicians needed, what they struggled with, and what would transform their capability to make better decisions.

That knowledge was more valuable than any technical certification. So we started with FileMaker. It worked. Clinicians could learn. Cases could be tracked. Progress was visible.

But then more people came. Thousands. Then tens of thousands. FileMaker had limits. We could see the edges of what was possible. The platform worked, but it had reached capacity. We needed something more scalable.

So we moved to WordPress and LearnDash. That solved the scale problem. Now 50,000+ users across 25+ countries could access the platform. It worked. It worked well.

But each platform had friction. Each had workarounds. Each required compromise between what we wanted to build and what the technology could easily do.

Then modern technology arrived. Next.js. Supabase. Vercel. Cloudflare. Claude.

Now we can do things we could not do before. Not because the old platforms were bad — they served us well. But because the new ones remove friction. They let us focus on the problem instead of fighting the technology.

Each evolution was never about chasing new tools. It was always about finding the right tool for the scale we had reached and the problems we were trying to solve.

Passion Follows Meaning

This is what people often get wrong about building. They think passion comes first — that you wake up excited about the technology and then figure out what to build with it.

But for me, it has always been reversed.

The goal was never the technology. The technology was always the means to reach the goal. When FileMaker stopped working at scale, I did not cling to it out of loyalty. We moved to WordPress because that was what the problem required. When WordPress could not do what we needed, we evolved again.

The passion comes from solving the problem, not from loving the tool.

It comes from watching clinicians use something you built and see their confidence grow. From knowing that decisions are being made better because of work you did. From understanding that somewhere, in a place you will never visit, someone is helping a patient more effectively because you solved a problem that existed.

That is what drives you to learn new technology. Not the technology itself, but what the technology makes possible.

The Evolution of Tools

For decades, I built with what was available. FileMaker was remarkable — it let me create systems that worked. WordPress and LearnDash gave me a way to build education at scale. Articulate and SCORM let me package learning for institutions. HTML, CSS, PHP — they got the job done.

But each tool had limits. Each was a workaround for what I actually wanted to do.

Then things changed.

Modern web frameworks like Next.js let me build with speed I never had before. Supabase gave me a database that works the way I think. Vercel made deployment instant. Cloudflare let me control infrastructure with clarity. And now AI has opened something I did not expect — a way to have a partner in the building process itself.

For the first time, the tools almost disappear. The friction almost vanishes. I can think about the problem, and the technology gets out of the way.

AI and Vibe-Coding

When I started working with AI for coding, I thought of it as a tool. A sophisticated code generator. A search engine for solutions.

But something shifted.

The more I worked with AI, the more I realized this was not hype. This was not chasing new technology for its own sake. This was a fundamental change in how I could think about problems.

Vibe-coding — that flowing state where you describe what you want, and the thinking happens in conversation — changed everything.

AI is not just faster — it is a conversation. It asks clarifying questions. It catches assumptions I made. It suggests approaches I had not considered. It forces me to think more clearly because I have to explain my thinking.

That is collaboration.

It is not replacement. I still make every decision. I still define the architecture. I still know the problem intimately. But I am no longer alone in the thinking. The machine and I are reasoning together.

Why I Continue

I could have stopped building years ago. I have built things that matter. I have proven I can do this. I could focus entirely on medicine, on mentorship, on writing.

But I have not stopped, and I know why.

It is because the problem does not stop. Knowledge still does not travel fast enough. Clinicians in resource-limited settings still lack decision-support. Training is still unequal. Learning is still constrained by geography.

And now I have better tools.

The old tools taught me how to think about problems. FileMaker, WordPress, HTML — they were years of learning what it means to build something that serves people. That experience did not disappear when I moved to modern frameworks. It got sharper.

Now I can ask bigger questions. I can tackle problems I could not have solved before. I can build systems that adapt and improve themselves using AI. I can move from one problem to the next without spending months on technical debt.

The Forge and the Tools

There is an irony in this.

The Shadow Forge is about quiet craft, precision, substance over visibility. But the modern tech stack — Next.js, AI, Supabase — these are not quiet. They are flashy and new and trendy.

Yet they serve the philosophy perfectly.

Because the point was never about the technology. The point was always about removing obstacles so that the actual work — the thinking, the design, the problem-solving — could happen. The old tools required so much ceremony just to get started. I spent weeks on scaffolding for every project.

Now I spend hours.

That means I can focus on the thing that matters: understanding the problem so deeply that the solution becomes obvious. Building with intention. Making something that lasts.

The new tools do not replace the philosophy. They enable it.

Moving Forward

I do not know what problems I will solve in the next decade. I know there are clinicians and educators who need things that do not yet exist. I know that knowledge is still unevenly distributed. I know that the gap between what is possible and what is accessible is still vast.

And I know that I have better tools now to close that gap.

Not because the tools are smarter than me. But because they are faster, clearer, and they let me think about the human problem instead of the technical burden.

Those people do not care about my tech stack. They care about whether the tool works. Whether it is fast. Whether it helps them.

I build because that matters.

And as long as that matters, I will keep learning. Keep improving. Keep building better versions of what came before.

Because the problem comes first.

The tools follow.

And the passion comes from seeing them serve something real.