If you don’t know what to do with your spare time, and you don’t have a solid business plan, the best thing you can do is work on an open-source project for free and give it to the world. I’ve tried to force half-baked businesses and they rarely pan out. Exposure and deliberate practice [link] will be a better use of your time.  For me, I developed the open-source pip module deploy-ml. Instead of worrying about trying to convince people to buy it, or partnerships, I got to focus on object orientated design, machine learning training, and deployment. Looking back at this module I should really restructure it, but finding people who want to contribute is never easy. Anyhow, this pip module got the attention of a Harvard associate, and before I knew it, I was flying out to Rwanda to help out in a health tech hackathon.

I do not imagine a vibrant med-tech scene. But before I moved to London, I was under the impression that the most cutting edge technology would be spun into clinical practice but super smart and enthusiastic professionals. The reality of London was so opposite it beat the socialist beliefs out of me and I ended up becoming a fan of the free market. So even though I was not expecting much I’ve been shocked before, luckily this time it was a pleasant shock. Rwanda is pretty forward-thinking. The roads are clean and well maintained, Uber is here, you can pay using your phone number with no need for a bank account, they’ve been delivering blood products via drone for the last three years, their hospital servers are running on Linux, they have an operational open-source approach to hospital software, and the busses are completely contactless for their payments. In short, I think the med-tech base in Rwanda is healthy. I’ll go through why this is the case.

There are two ways you can obtain software. You can buy it, and you can make it yourself. Buying it is quicker and easier, but it’s a seriously false economy. To demonstrate this let us look at WordPress. I’ve helped out multiple small startups in my spare time. After doing this for a few years I started to call WordPress the “honey trap”. Building a simple web app with users, login, and a few forms can be built with WordPress within a day. The morning, you’re quickly mapping out some basic logic for your website’s database. In the afternoon you can be adding content to your website, and telling people to use it. It’s a few hundred pounds to host for the year, and at the end of the day, you can be telling people on facebook to sign up to your website. You don’t have to pay for an expensive developer, and it’s super quick. Now I don’t hate WordPress. I use it for this blog. The thing is, all I’m going to do with this website is blog. I have no plans for anything else on this website. If I do I will code something for my problem. This is the key part, software is a tool for your business. Your software works to solve your business tasks. Your software is actually unique to your business. Now, if you’re a bakery, and all you want is a website to tell people your location, opening times, and menu, then yeah, use WordPress. But if software starts solving unique problems for your business, then if you don’t build it in house, it will bite you. I’ve lost count on how many startups contacted me because they built something using WordPress, and they want it to do something more unique for their business. Or they brought a platform cheaply with some outsourced developer and now they want to do more. The problem is that most of the time, they have to throw out their system, and build it again from scratch. They’re caught in a trap. They can’t progress, and they usually don’t have the money or time to fix their mess so they can progress.

The problem with WordPress is that it just doesn’t support the low-level approach for you to fine-tune your custom business logic into the platform. The problem with outsourcing is that the developer has no interest in your long term goals. They will code what you want as quickly as possible. They will usually have copy and paste scripts that they slightly alter because they don’t want to spend too much time on your project. If it scales badly, or if the code isn’t structured to your business model so it can’t be split into modules and deployed in other products, it has no bearing on the outsource developer. They need to get the product you paid for out as quickly as possible to the specs that you’re paying for now. And, again, these startups were stuck with dead black boxes that couldn’t scale, and would need a lot of work for them to progress to the next stop.

Now, building it in-house is more expensive and slower, initially. However, it has great advantages in the future. This is why companies will pay six-figure salaries to developers who understand the business and are good at software architecture. If they could get away with paying people less they would. The secret behind tech companies’ success is incremental increase. They start with modular chunks of code that solves one problem. They then test it, get feedback, make it more secure, make it more stable, smooth out the deployment process, and then push it into production. They then get feedback from users, and repeat the process. They then move to the most urgent addition to the platform. They design how this should into the platform, and then this is built. The same cycle of feedback and getting it stable and solving the problem exactly how you want is then applied to the new addition. This modular approach grows the company’s library. Then if they want to release another product, they can usually use a lot of the modular code they have already built. To show this let us have a hypothetical company.

They build an analytics platform where companies can track and see their budget spending. They build a database management module in its own repo. They then build an analytics module that can fuse with the database module as it’s generalized. Then a The API and login module is built in another repo. We’re not even at the project yet. Another repo is built for the logic of budget tracking software. It gets smoothed out and works. After that, it turns out that the majority of their customers are logistics companies. Because of this and feedback, they build another analytics product for logistics tracking. The database, API, and login module are instantly cloned into the new project and all they have to do is write the code specifically for the logistics product. Then devs refactor the database module, making it faster and more secure. Now both products benefit from this upgrade. Now you don’t need a Ph.D. in computer science to work out that if you don’t have an in-house dev team, your company will be completely smoked by companies that do. Hell, I even know that companies like John Lewis have in-house dev teams.

Now going to Rwanda, they are using and contributing to an open-source project called OpenMRS [link]. When I was at the presentations and demos I felt a stark contrast. In the NHS I was used to seeing a clueless manager tell people that they’ve paid an extortionate amount of money to a new private system. This private system has usually replaced completely another private system. In Rwanda, they were talking about their iterations. They worked with clinicians and slowly added new features. All the code can be accessed through their Github holding 213 repos [link]. The software can be downloaded for free, and it’s not backward. They are using cutting edge tech and frameworks like the distribution tool Docker [link to what docker is]. Now, does this mean it’s the best system in the world at the moment? No. But this is the way healthy software development happens. Facebook’s front-end React is open-source and free to download. Google’s AI system Tensorflow [link] is also completely open-source and free to download. If you’re interested in why they do this, here’s a good answer [link].

Do I think that the NHS is a complete mess in terms of tech? No, it kinda works and that’s an achievement. But in the long run, the NHS needs to seriously up its game in the open-source community. With the FHIR API protocol [link] small software projects can connect to other health tech platforms. Gov UK has deemed open-source tech in the NHS not to be a security risk [link]. For the future, a healthy, open-source code base needs grow and be implemented to solve low hanging fruit. There also has to be a culture shift in the NHS. Some of the most greedy, cut-throat entrepreneurs who hoard very mediocre tech have been NHS employees. In fact, the only people I’ve worked with who have refused to disclose their percentage whilst wanting to work with me or withhold the percentage of a sale when getting me to code a project have been NHS employees….. and I worked in financial tech. I’ve introduced financial tech devs to NHS employees in order to get a project off the ground only to see the financial tech dev walk away shaking their head in disbelief at the dishonesty and greed they would be working with.