Modlit thesis
Most academic code is written to get a paper out. What if it were written to get a product out?
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), raised money and navigated multi-disciplinary and engineering software as a creator and user for over 20 years. 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 is often single-use, not reusable, 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 setting them up for better collaboration with industrial partners and better chances of 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 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 authentication, billing, monitoring
- building a web page to showcase it
- 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.
Users are the proof
Without users you cannot build software. That’s why getting users early matters. As Paul Graham, YC’s founding partner, likes to say:
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 it 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.
That’s 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, 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.