Table of Contents
Software
iGEM Software Project – Mutation Labs
Overview
Mutation Labs is an application for the management as well as sharing and creation of primers for other iGEM teams. Instead of traditional spreadsheets and lists, Mutation Labs provides biologists with a structured and refined process for the R&D and integration of primers.
Design Goals
Our design goals were initially to provide a clean and intuitive CLI environment for iGEM teams to be able to work on primer designs. After the developement of the initial environment, which generated primers based on a reference and target node, we realised that the viewing of these generated primers weren’t intuitive. This mutation detection algorithm was created using the Levenshtein Distance algorithm.

| Figure 1 |
|---|
| The initial design of a mutation and primer detector in the terminal |
As a result, we decided to design a visual system and interface for generating these primers, but very soon we realised that the mutation detection itself, as well as the primers generated weren’t really reliable. In the face of these multitude of issues and edge cases, we decided to change tracks to target more of a consumer issues. We decided that we wanted to make an intuitive and shareable database for biologists to store their created primers as well validate them and organize all of their sequences.
This is where the idea for Mutation Labs arised.
System Architecture
Architecture-wise, I decided to choose the framework that I am most familiar with, that being Next.js with Tailwind CSS and Shadcn/ui. Due to the lesser scale of this project, I decided that my regular habits of using tRPC running on an Express.js with CORS configured for security reasons would be unecessary and would add uneeded complexities into the developement process.
In order to have secure database transactions, I used the built in Next.js API routing functionality, combined with NextAuth and Prisma for more convenient abstractions when it comes to user logins, and database read / writes. With this in mind, I created a few REST API routes for my frontend to interact with using the built in fetch function provided by JavaScript. This way, I could have a simple and clear way to interact with my backend REST APIs, sending data through formatted JSON.
| Figure 2 |
|---|
| The Next.js API Routes used |
Additonally, I also chose Prisma due to safety and scaling purposes. With Prisma, vunerabilities like SQL-injection become less of a significant worry and makes the overall risk of issues with the database be less catastrophic, wth all the layers of safety built on top of it. Additionally, the amazing TypeScript functionality provided by Prisma in the backend (Next.js API) helped a lot with the developer experience, and prevented the accidental bugs that would usually occur from invalid database transcations. Additionally, the Prisma schema and migration systems are really clean for bigger teams, and if one is considering scaling up in mind, Prisma would also be a good architecture.

| Figure 3 |
|---|
| Really clean DX for Prisma Schema |
For data storage, I chose to use PostgreSQL over other alternatives like SQLite due to the fact that for reading and writing in parallel, smaller database protocols like SQLite tend to have reliabilities. Since we are making a team shared platform, it was decided that PostgreSQL would be used due to its wide adoption, feature range, and tested performance.
UI/UX
For the user interface design, some performance and end-user considerations were made. Due to the fact that most engineers would lean towards desktop and laptop environments, we decided to use a vertically directed sidebar, for easier access and more descriptive labels for navigation items. For the app layout inside of the sidebar, we went with a less changing, and scrolling layout instead, so that when screen sizes change the items on the page wouldn’t rearrange themselves as much. This is an advantage from a desktop point of view as there would be less informational structure loss and scrolling isn’t really a big concern using a mouse.
| Figure 4 |
|---|
| The scrollable nature and vertical flow sidebar with long label names |
We also decided to use a Notion-inspired workspace structure for switching between teams, with a dropdown at the top left corner of the sidebar for switching and creating teams. This further makes the app design flexible as users can join as many teams as they would like.
| Figure 5 |
|---|
| Workspace switching functionality |
Workflow
Workflow wise, we formulated a few core concepts that we wanted the software to be able to achieve including the following:
- Storing of sequence data and the children sequences
- Storing of primers and their characteristics
- Creation of primers with context of the sequences (reference and mutated)
- Validation of primers through with full context displayed graphically
To do this, we came up with the following pages / features to do so.
Storing Sequences
To realise the functionality of storing sequences, I used the following interface for better organization and intuitiveness. All of the sequences can be edited after their creation and users can add mutation variants of reference sequences for easier access during testing when the user is validating or creating primers.
| Figure 6 |
|---|
| Sequence storing visualization |
Storing Primers
The storing primer is structured similarly, with the sequence and important statistics displayed. The GC content as well as other scores and metrics are stored in different columns of these primers.
| Figure 7 |
|---|
| Primer storing visualization |
Primer Creation
For primer creation UI, the user is able to first select a reference sequence. Then they are prompted to add mutated child sequences to view them in context. The user can then choose a primer of a certain length, and modify it based on the mutated areas.

| Figure 8 |
|---|
| Primer creation UI |
The user created primers can be shifted to the left, right, extended in the left and right direction.
| Figure 9 |
|---|
| Primer creation UI 2 |
| Figure 10 |
|---|
| Storing created primers |
Primer Validation
The validation step uses a similar process to the primer creation process, with the same inline editor. The difference is that when u move the primers, the base pairs no longer change and it is marked as mismatched when it doesn’t match the sequence it wants to bind.
| Figure 11 |
|---|
| Primer validation |
It will also mark it as invalid if it doesn’t meet certain criteria such as a base pair length minimum, and a certain GC composition standard.
| Figure 12 |
|---|
| Primer analysis |
Notably
The software also includes a team management interface, where users can be added, removed, and have their roles changed.
| Figure 13 |
|---|
| Team management |
Deployement
To deploy this software, one must first clone it using git.
git clone https://link-to-git-repository.com/software
Next, assuming that npm and node are both installed, one should install all required dependencies.
npm i
Finally, in order to have a proper connection to the database, it is required to put a DATABASE_URL in a .env file in the root directory (with package.json) to have secure read/write access to the PostgreSQL database.
The DATABASE_URL should follow the following format:
DATABASE_URL=postgres://{user}:{password}@{hostname}:{port}/{database-name}
Where the content in curly braces are your PostgreSQL credentials. To initially host a project like this, I would recommend using Supabase for project deployment as it is really easy to create and free to use at the beginning.