Modlit Thesis

Most academic code is written to get a paper out. What if it were written to get a product out?

The best research software is written like a product—not just like code.

I write and work under the name Modlit and would rather not use my real name in public yet. I am a Physicist by training and have worked in software, academia, started companies (backed by Y Combinator (YC)), raised money and navigated through multi-disciplinary and engineering software as a creator and user for over 20 yrs.

I still wear both hats as a scientist and software developer and it's a fun mix.

Why academic code stays in the drawer

From what I’ve seen over the years, the main reason academics write code is to solve a specific problem and get a paper out. It's often collaborative, sometimes receives input from research software engineers (RSEs) at university departments—but it often is single-use, not re-usable, not well documented, not scalable and not designed with the user or usability in mind. It may not even be in version control and will quickly become out of date, unrunnable and forgotten as the academics move position, graduate or simply run out of time to maintain it. Think of the script that only runs on your machine, or the tool that vanished when the postdoc left.

Sound familiar? I've been there too. It's a well known phenomenon and the picture is changing over time as engineers and scientists pick up basic good practices and chat with their peers in companies and computer science departments.

However, practicalities and practices aside, the mindset needed for writing software with the intention of creating a product or even a business is very different from the mindset for research and publication. It doesn't have to be—and in fact shouldn't be. The best and most impactful research projects have adopted the

write software, don't just write code

approach and it pays dividends for their careers and citations as well as sets them up for better collaboration with industrial partners and better chances for success with spinouts and minimum viable products (MVPs) created from their projects.

Where Modlit fits

With modern AI—creating a full stack app is now orders of magnitude simpler for the scientifically minded budding entrepreneur. AI is less capable at coming up with the fundamental algorithms and this is where the opportunity in this space arises. There are still benefits to interacting with a human software developer though early doors, and this is where Modlit comes in. Hello 👋 As well as writing code I help by

• breaking down the tasks

• planning the architecture

• listening to the requirements

• building the user stories

• defining the MVP

• selecting the tech stack

• advising on the deployment

• adding in user authentication, billing, monitoring

• building a web-page to showcase it and even

• helping with pitch decks

A fully fledged MVP-building partner like a fractional CTO at your disposal who can quickly get to grips with your science or engineering domain and understand your requirements with the skills to build at lightning speed. So you can focus on the science while the product gets built.

Without users you cannot build software. Users are the proof. That's why getting users early matters. As Paul Graham , YC's founding partner, likes to say,

Build something people want

Often the best place to start is building something for yourself to solve a problem. Most academics already do this on a daily basis. If that problem is shared by others there may be a market for solving this problem at scale. Getting users early is the smartest thing you can do—to validate your hypothesis, test your software and help you iterate and improve fast.

Making something 100 people love is better than making something 1000 people like

is another Grahamism. And it's true. If you can get users and you solve a really hard pain point for them, they will love you for it and become loyal and tell their friends and colleagues. Now you have the start of a business. This is called product–market fit (PMF), and attaining it as quickly as possible should be the aim of every startup. Getting there without users and an MVP they can interact with is much harder and slower, and it takes skills that not many scientists and engineers possess (or at least not at first).

I've shipped products from research, raised rounds, and now I offer my services to you, dear reader.

If this resonates, I'd love to help you turn your research into software people use.

Please get in touch—tell me about your project or book a call. I'd love to hear from you.

hello@modlit.io