CapexIQ

Know if it pays for itself, before you buy it.

Comment

How it all started

I think it began during my internship.

It was the consultancy’s first-ever turnkey project. A brownfield, Super Specialty Cardiology Unit, being opened in the suburbs, and luckily I got my hands on the project.

It was the Biomedical Equipment planning that had the first tinkling of CapexIQ. Back then, I used to call it simply the ROI Calculator. If you were to comb through the code on GitHub, you might still find remnants of it somewhere around in the initial planning documents.

Once we had sorted out the equipment that was to be needed for the project, I was asked to figure out when we would hit break-even, when would we get the returns on our investments, and so on. To be a little more honest, they basically asked me, “Figure out, when will we make our money back?” The fancy terms were merely my additions.

And so began the journey to figure out how to do so. The consultancy allowed me to connect with various veteran managers across the Indian healthcare sector. That gave me a serious glimpse into how the industry calculated ROI for their capital-intensive clinical investments.

The idea for them was very simple, or so I learned from my conversations with them and inspection of their Excel models. Each manager, especially veterans, had their own Excel models, some more advanced than others, some more traditional, ignoring inflation and depreciation, while some focused on NPV and IRR, but none were as comprehensive as they could be.

It wasn’t that these managers couldn’t figure out on their own how to include inflation, payer mix, or even adjust for seasonal changes. They could, but it wasn’t worth the time. Approximations could work, so they said.

As an intern, I usually had one or two tangents of projects, and a whole day to myself to take it all to perfection. And so I did.

I made the most ambitious Excel model that I could make, taking into account every little thing I could. Assisted by AIs, I must say my productivity was through the roof. Usually, you’d be stuck finding what you need in government standards, a dense 1,500-volume, split across 4 sections. But times are different; a needle in a haystack is nothing for models of today’s age.

And so there I was, a humble Excel titled ROI Calculator, beefed up to multiple pages, interlinked with formulas. I was very proud of it. And so was my supervisor. And hence the consultancy kept it, their own ROI Calculator.

But I wished to make it more accessible. After all, I wondered how many times hospitals may have cancelled some high-CAPEX purchase like CT or MRI, especially in my country where the doctor-to-population ratio is 1:811. Maybe if they had hands on a better tool to predict their chances, maybe some would dare? Would go ahead with a purchase and reduce the burden on India’s public health infrastructure.

With my discussions with managers, I realised there was no standard template they could use. Everyone had their own models, their own idea of what a discount rate should be. So there needed to be something standard, something that could be used as a foundation and adapted to their needs, something that reflected the current market condition and realistic assumptions reflecting the Indian market.

And so I made CapexIQ, a transparent, open-source, and reliable calculator that provides managers the flexibility to go as deep into building their clinical investment case as they want.

There was yet a small accessibility issue still, but more on that later.

The Building

I think when I started with the build of CapexIQ, I had a subscription to Claude, which was almost about to end. I used Claude Code to plan out my build. Using my Excel model as a base, we drafted out how the website would look, what variables we would use, we designed the dashboard, and used deep research agents to ground our assumptions in trusted sources.

Once that was done, I shifted to Codex.

I’d like to point out, in all of the building process, no frontier model was used. Since I could either afford Claude Pro or ChatGPT Plus, I primarily relied on GPT-5.5 Low and then Luna High-Max when it came out.

I was exceptionally blown away with Luna. At High or Max, it delivered substantial performance, could do parallel running tasks, without making an exceptional dent in my usage. That allowed me to push further with my building efforts.

I designed a new system, all thanks to Codex. I proudly call it “Cascading Parallelism.” Essentially, I’d start with a plan, which would be the one where I would spend a substantial amount of my time. Once that was done, I’d divide my plan into sections that can run in parallel. I would then instruct the parallel agents to cascade, to start another thread with a prompt that builds up on their work.

Suppose there are 6 stages, A to F.

And A and B can run in parallel, while C, D, E, and F relied on the work they did.

(Each of A to F are different agents, who each used subagents as they wished.)

So:

A —> C —> D —> F

B —> F

This approach allowed me to stop becoming a copy-and-paste tool, starting and inspecting agents’ work. I couldn’t have achieved this level of orchestration in Claude Code. And I am very happy with this way of building. It makes me spend time where I need to spend it, planning, and I can then come back hours later when all of it is done.

This also helps my managerial sense, for this allows me to maximise the output I receive per agent hour.

I created a small system while I used Claude (which I later found was more ubiquitous than I had earlier anticipated). Agents would read intro, a brief Markdown file that introduced them to the project, made them aware of where the project spec was located, where the directory was located, instructed them to write in 'handoff.md' once they were done, and maintain an issue tracker. The spec list would have all the information related to work phases, so all I had to do was start an agent, and the rest of the context was always available for them. However, this was crude and still required me to intervene after every agent was done. This was simplified tenfold when I moved to Codex. The orchestration between agents was seamless.

I did learn that as long as your planning is immaculate, the bugs you encounter later on do decrease quite a bit. As long as you have an idea as to how each bit of your software should act, and you can plan it out, agents have no issue executing your vision.

And all of this by lower-end models running for a very usage-conscious user.

The Accessibility Issue and WebMCP

I sent out the early version of CapexIQ to all the managers I had earlier connected with and requested them to try it out, either on one of their previous cases or a new one if they had.

Some did get back to me, praising how easy it was. They especially loved that they could export their data in a well-formatted Excel. I am glad they did. I was proud of that feature, and I knew how much it means to managers to have their Excels neatly embedded with formulas. A sentiment I wholeheartedly agree with.

They did mention they could never dig deeper again. Payer mix, life cycle, was often untouched by them.

It was a problem. I was thinking of converting CapexIQ into a plugin or maybe building a semantic extractor where they could just upload their PDFs and my algorithm could do its best to extract useful data from it, but none of it would be perfect.

And then I came across the WebMCP challenge on X. The prizes may be enticing, but for me, this would solve the accessibility issue that I was facing!

I went on to inspect what it meant, had a conversation with my agents as to how compatible it would be and how we could integrate it with CapexIQ.

And oh, how happy I was to see how it could make using the product so much easier for my target audience.

It wasn’t that the managers could not fill the form. It was maybe a little more than that. Form filling is one thing; during work, there are so many things an operations manager has to go through. Maybe they wouldn’t bother with it, or maybe, as one pointed out to me, “We are not finance guys, we don’t know how to assume so many different variables.”

For me then, WebMCP acts as a solution to my clientele. I tried my best to make CapexIQ as accessible as I could. Every variable has a tooltip attached to guide users as to what it means, how to fill it, and where to find its source.

But I guess it becomes tedious to go through HIS (Hospital Information System) for every other variable.

And so, WebMCP solved all of that. We tried giving messy hospital data PDFs, vendor quotations, and some approximations to our agents and asked them to fill CapexIQ for us. We asked them to let us know if they could not fill something, and we’d talk through it and mutually come to a well-educated conclusion, something closer to reality.

Oh, and how well it worked. I was so happy. It was a solution to a rather complex issue. Agents could extract information from the PDFs, they had the hospital context, they could suggest values that the managers would agree with, and boom, there we have it, a much more comprehensive analysis of a capital investment that earlier would have required a lot of time and, depending on the complexity one was targeting, maybe some heads crashing across some walls! And now all you need is some messy unstructured data, your wits, and that’s it! A CAPEX analysis worth crores brought down to a simple conversation. One could use GPT Live models, and that would actually be getting it done while having a literal conversation.

Before I get carried away, yes, the technology is still experimental, and the broader population still might not access it. Most of my managers probably won’t know how to enable feature flags in Chrome or use ChatGPT app’s inbuilt browser.

But that won’t stay that way forever, and I can’t wait for the day when this tech becomes much more accessible, for it could solve countless problems that we don’t even quite know exist, let alone solve them.

Built With

Share this project:

Updates

Submission history