Rebuilding SmartCrowding 2.0 for Norwegian Healthcare

A case study on SmartCrowding 2.0

SmartCrowding is patient flow management software for hospitals. It gives hospital staff a real-time view of how full each ward is and where the bottlenecks are forming, so they can act before the emergency department or ICU runs out of capacity. The first version had been running at Stavanger University Hospital since 2015. By 2024 it was dated and hard to maintain. I led the rebuild that became version 2.0, which now runs in 20+ Norwegian hospitals and is expanding to the UK.

I'm 18 now. Most of this work happened between 16 and 17.

I was hired in Bangladesh as a social media manager for the CEO of Metanoia, a tech consultancy partnered with SmartCrowding. My job was to make him a thought leader on LinkedIn. We got close quickly. I kept giving him opinions on stuff that wasn't really my job, but he appreciated my insights on the product. At some point he told me I should be doing PM work and moved me there.

SmartCrowding 1.0 was Metanoia's main product. It was also its biggest problem.

The UI looked like it hadn't been updated since around 2010. Lots of low-contrast green. The closest comparison I can give is the Windows 7 task manager. No offence to Windows 7, but the visual style just resembled its task manager, which is, dated.

The dashboard threw a wall of charts and numbers at the screen with very little explanation, which was a real problem because the people opening the app were nurses and clinicians. The important features sat three menus deep. Installing it at a new hospital meant running a training program for nursing staff on top of an already complex installation process. The costs were heavy.

The codebase was worse than the UI. The original developers still owned chunks of the cloud infrastructure. A lot of the libraries we depended on weren't licensed to us. There were no comments, almost no structure, and large sections of code copy-pasted from the dev shop's older unrelated projects. You could ship small bug fixes. Anything bigger started getting messy.

It worked just well enough to keep selling. The gap between it and modern software kept widening though, and that was starting to matter.

Me and the Metanoia CEO soon realized we needed to start on a complete overhaul. But it would be expensive and very difficult to explain to non-technical higher-ups. We arranged a board meeting and I built a deck. It was a Teams call. I was in Bangladesh, the board was in Norway. They didn't know my age. I think the CEO of Metanoia just didn't see a reason to bring it up. I am sort of grateful for that because it was an insecurity for me.

I walked them through the technical wall and tried to translate it for the non-technical investors. The analogy I remember using was something like: imagine your car can only drive to specific places, so every time you want a new destination, you have to buy another car. Wouldn't it be cheaper in the long run to buy one car that goes everywhere, even if it costs more upfront?

The part I felt best about was the deal structure. The way it normally worked, Akkomplish (the Indian dev team building the product) would bill us for the engineering work upfront, and we'd then bill SmartCrowding to cover it plus a margin. So SmartCrowding paid us, and we paid Akkomplish. Before the board meeting, I went to Akkomplish and restructured that arrangement. Instead of charging upfront, we'd build the MVP first. If SmartCrowding accepted it, they'd pay us for the project, and Akkomplish would take 40% of that bill. If SmartCrowding rejected the MVP, nobody paid anyone and we walked away. Akkomplish was taking on the risk in exchange for a bigger share of the upside.

That meant I could go to the board and ask them to greenlight a full rebuild at zero upfront cost. If they didn't like the MVP, they owed us nothing. There wasn't really a version where they lost.

They said yes. I'm still not sure how much of that was the deck and how much was the deal, but the deal was the part I felt good about.

The dev team at Akkomplish was a junior group. Good raw skills, but they were early in their careers and hadn't built much product instinct yet. I have seen this to be pretty common for engineers in South Asia, where you're hired to execute someone else's spec, not to think about the user. Most of my job became being the layer they didn't have.

I used AI to speed up spec writing, which I think I started doing earlier than most people in this space. The specs themselves weren't one-line tickets. They were full documents covering edge cases, expected behavior, failure states, who the user was, and what they were actually trying to do. The team didn't have to guess. They built what I made very clear.

The requirements came from a few different places. Hospital user feedback came through my boss, who handled that side because I don't speak Norwegian. The board and C-suite would also send requests directly to my boss. Me and my boss would sit down to collect everything, figure out what mattered for the current sprint, and turn it into specs.

I ran daily standups and bi-weekly sprint planning. I QA'd everything before it shipped, which meant I was the last layer between the team and the customer. Most surprises got caught in private rather than in production.

The UX designer on the team was technically excellent. He could turn anything into clean wireframes, but he didn't always know what should go on them. I'd describe the screen, what the user should be able to do, what it should feel like, and he'd design it. Then the team would write the code. We covered each other's gaps. I'd have struggled without them.

About halfway through 2.0, my boss got excited and started sketching out a 3.0 with a bunch of new features. He wanted to pile them on before 2.0 was finished. Our culture leaned toward overdelivering, which I liked, but this was overdelivering a bit too much. The board was also very excited about it.

I went to him and the board together. I made the case that we needed to finish 2.0 first, and that the 3.0 features could be a real conversation once 2.0 was live and we knew what was actually working. We re-anchored and kept building.

SmartCrowding 2.0 launched. Hospitals adopted it. The UK government got interested and we started the NHS compliance work for a UK rollout. The original CEO retired on the back of the launch, which I took as a quiet compliment. A new CEO came in, tried to replace our team with an in-house build, and couldn't replicate what we'd done. We're still on the product.

I don't want to call that a personal vindication. The new CEO had reasonable instincts. Trying to bring it in-house is what most companies in his position would try. But the work turned out to be hard enough to copy that they came back to us.

The version of the story where I made every right call is wrong. The team chemistry worked out in a way I didn't fully engineer. The UX designer was a gift. My boss trusted a 16-year-old with a board pitch, which most CEOs wouldn't do. The product had years of validated value from Stavanger before I touched it, so the question of whether anyone wanted it was already answered.

What I'll claim is being the connecting layer. The engineers had skills but needed direction. My boss had vision and a lot of ideas going at once that needed sorting. The designer could execute on anything if you pointed him at the right thing, and didn't have a strong view of what the right thing was. The hospitals had real domain knowledge that wasn't going to translate itself into product without someone in the middle.

I'll have to get better at my skills as I do more projects. For now, the product is in 20+ hospitals and running, and I'm going to keep collecting more data points so I can keep evolving.