Why I'm Building a Procurement Management App for Healthcare

I did not start thinking about procurement software because I wanted to build another dashboard.

I started thinking about it because, in my day job, I kept running into the same stressful reality: medicine shortages are never just numbers on a spreadsheet. They affect planning, communication, workload, and, ultimately, patient care.

When a medicine is in short supply, the problem rarely stays isolated. One shortage can trigger substitutions, urgent stakeholder updates, supplier follow-up, internal discussions, and a long trail of operational work just to keep things moving safely. The data may exist somewhere, but it is often spread across spreadsheets, email threads, local files, and individual knowledge held by the people trying to keep the system together.

That experience is the reason I am building this app.

I also wanted this first article to be personal. I am writing it as James, the founder, because I want people joining the waitlist to know there is a real person behind the product vision. Over time, as the company grows, more team members can contribute their own perspectives too, whether that is product, customer success, or marketing.

The Problem I Keep Seeing in Healthcare Procurement

Healthcare procurement is not just about ordering stock. It is about balancing availability, safety, timing, communication, and risk.

In practice, that means teams often need to answer questions like:

What is running low right now?
How many days of stock do we actually have left?
Which products are at risk because of supplier lead times?
Who has already been updated about the latest procurement status?
How do we make sure management and operational teams are looking at the same information?

These questions sound simple, but answering them quickly and consistently is hard when the process is fragmented.

In many teams, people are still doing heroic manual work to bridge the gaps:

manually compiling procurement updates
exporting data into spreadsheets
turning those updates into PDFs for distribution
emailing different stakeholder groups one by one
chasing context across multiple people and systems

That may work for a while, but it does not scale well, and it creates unnecessary operational risk.

Why I Am Making This App

I am making this app because I want procurement teams to have a clearer, calmer way to manage shortages, stock visibility, and stakeholder communication.

The goal is not to replace professional judgment. The goal is to support it with better visibility and better workflows.

At a high level, I want the app to help teams:

see inventory and procurement risk earlier
communicate updates more consistently
reduce manual reporting overhead
collaborate in a shared workspace instead of scattered files and messages

The starting point is healthcare because that is where I have felt the pain most directly. When medicines are affected by shortages or lead-time issues, the cost of confusion is high. Better tools can reduce friction, reduce avoidable delays, and help teams spend more time on decision-making instead of admin.

The Benefits I Want the App to Deliver

The app is being designed around a few practical benefits.

1. Better Visibility

Procurement teams need more than raw stock counts. They need context.

That is why I am focused on presenting inventory in a way that helps answer operational questions faster, including stock coverage, lead-time pressure, and where attention is needed first. The aim is to make the state of supply easier to understand at a glance.

2. Better Communication

One of the most repetitive parts of procurement work is distributing updates to stakeholders.

Instead of manually reformatting the same information for different people, one of the key features will be the ability to periodically distribute procurement updates to a mailing list of your choice, including CSV and PDF formats. Those reports will not just contain stock figures. They can also include the working details behind each item on watch, so stakeholders receive the operational context, not just the headline.

This matters in healthcare because procurement updates often need to reach multiple audiences, from operational leads to management teams, and consistency matters.

3. Better Collaboration

Procurement is rarely handled by one person in isolation.

Another core feature is the ability to add users into a shared workspace for management. Instead of relying on disconnected files or one person owning the latest version of the truth, teams can work from the same operational view.

That shared workspace model should make it easier to align procurement, operations, and leadership around the same information.

I also want teams to be able to leave comments against each product on watch. That includes notes for stakeholder management, risk assessment, decisions taken, and other context that usually gets lost across email threads or separate documents. Each comment should carry a timestamp, so the history of updates is clear and traceable.

When the app generates reports and sends updates to a mailing list, those item-level notes should be able to appear in the output as well. That way, recipients can see not only that a product is at risk, but also the latest comments, risk framing, and stakeholder context attached to it.

4. Less Manual Admin

A lot of procurement effort is spent packaging information rather than acting on it.

If the app can reduce the time spent compiling reports, formatting updates, and distributing them manually, then teams can spend more time on the work that actually needs human judgment: prioritisation, escalation, supplier coordination, and planning.

Why Healthcare Comes First

I am starting with healthcare because the environment is complex, high-stakes, and deeply operational.

If a procurement workflow is useful in healthcare, it has a strong chance of being useful elsewhere too. Healthcare forces clarity. It forces better thinking about shortages, accountability, communication, and shared visibility.

It is also an area where software should be especially respectful of how real work happens. I do not want to build a shiny tool that looks good in a demo but adds friction to an already difficult workflow. I want to build something genuinely practical.

The Longer-Term Vision Beyond Healthcare

Although healthcare is the starting point, I do not think the underlying problem is unique to healthcare.

Many industries deal with similar coordination issues:

aged care and community care
pharmacy and medical supply
manufacturing
hospitality and food supply
education and institutional purchasing
multi-site retail and distribution

In all of these environments, teams need a better way to track supply risk, share updates, and coordinate decisions.

My long-term vision is to build a procurement management platform that starts with a healthcare use case but can extend to other industries where inventory visibility and communication are critical. The exact workflows may vary, but the core need is the same: clearer procurement decisions, less fragmented reporting, and stronger operational alignment.

I Haven't Decided on the App Name Yet

I still have not locked in the app name.

For now, I am describing it plainly as a procurement management app because that is clear and honest. But I am open to better naming ideas, especially names that feel credible in healthcare while still being broad enough to support expansion into other industries later.

Some directions I am considering:

names that suggest clarity or visibility
names that imply supply continuity or flow
names that feel operational and trustworthy rather than gimmicky
names that can grow beyond a single niche

If you have suggestions, I would genuinely love to hear them.

If This Sounds Useful, Join the Waitlist

This app is being shaped by a real operational problem, not a hypothetical one.

If you work in healthcare procurement, inventory management, pharmacy operations, or any supply-sensitive environment, I would love to know whether this resonates with you. The waitlist will help me prioritise what to build first and validate where the strongest demand is.

If enough of the right people care about this problem, the chances of building something sustainable and genuinely useful at launch become much higher.

That is the goal: not just to launch an app, but to launch one that deserves to exist.