Landscape

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.

Screenshot 2025-10-07 at 8.12.50 PM

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.

Screenshot 2025-10-07 at 8.33.21 PM
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.

Screenshot 2025-10-07 at 8.38.15 PM

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.

Screenshot 2025-10-07 at 8.37.04 PM
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.

Screenshot 2025-10-07 at 8.47.50 PM
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:

  1. Storing of sequence data and the children sequences
  2. Storing of primers and their characteristics
  3. Creation of primers with context of the sequences (reference and mutated)
  4. 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.

Screenshot 2025-10-07 at 9.27.35 PM
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.

Screenshot 2025-10-07 at 9.30.27 PM
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.

Screenshot 2025-10-07 at 9.40.32 PM

Figure 8
Primer creation UI
Screenshot 2025-10-07 at 9.42.45 PM

The user created primers can be shifted to the left, right, extended in the left and right direction.

Figure 9
Primer creation UI 2
Screenshot 2025-10-07 at 9.43.25 PM
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.

Screenshot 2025-10-07 at 9.44.53 PM
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.

Screenshot 2025-10-07 at 9.46.29 PM
Figure 12
Primer analysis

Notably

The software also includes a team management interface, where users can be added, removed, and have their roles changed.

Screenshot 2025-10-07 at 9.47.22 PM
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.