Research software

// The problem

A university's core facilities book microscopes, sequencers and cytometers on paper sheets and shared calendars, and the facility manager spends days each month building recharge invoices by hand.

// What we would build

A booking system where researchers sign in with their university account, book only the instruments they are trained on, and are billed by the hour to the right grant account, with recharges posted to your finance system and outside users paying by card.

// What is in it

// Stack

• Next.js
• PostgreSQL
• SAML and OpenID Connect
• Stripe
• DigitalOcean Toronto

// The problem

A research office tracks every grant in an Excel workbook full of macros written by someone who retired, and principal investigators find out they are overspent when the finance office refuses a purchase.

// What we would build

We move every grant, budget line and commitment out of the old workbook, check it with your research finance team, and rebuild it as a web app fed from your finance system each night, so each investigator sees their own grants, spend and commitments, and the office sees them all.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Excel import
• Metabase
• DigitalOcean Toronto

// The problem

A university's research ethics office receives applications as Word files by email, tracks them in an old FileMaker database, and spends hours each week telling applicants where their file stands.

// What we would build

Workflow software for ethics applications: online forms built from your board's own templates, routing to reviewers, versions and comments kept together, and a status page applicants can check. An assistant on an open-source model, served for you in Canada, checks an application against your board's own checklist for missing sections. It never gives ethics advice; decisions stay with your board.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Open-source LLM
• FileMaker import
• DigitalOcean Toronto

// The problem

A university's research data team asks every project for a data management plan, then has no way to see where the data actually lives, who owns it, or when it may be deleted.

// What we would build

An internal hub that joins your storage, institutional repository, ORCID, grants system and HPC accounts through their published APIs, so every dataset has an owner, a project, a storage location and a retention date, and deposits to the repository start from the same record. We check each system's API before we quote.

// What is in it

// Stack

• Node.js
• PostgreSQL
• OpenAPI
• ORCID API
• Dataverse API
• DigitalOcean Toronto

// The problem

A research institute pays for cluster time and three cloud accounts out of one budget, and no lab or grant can see what its own work costs until the year-end bill arrives.

// What we would build

Dashboards that read your HPC scheduler's accounting and your cloud providers' billing exports, tag every job and resource to a group and a grant, and show each lab its spend against budget. We host and look after it, with alerts when a group's spend jumps.

// What is in it

// Stack

• Python
• PostgreSQL
• Slurm accounting
• Cloud billing exports
• Grafana
• DigitalOcean Toronto

// The problem

A research institute's groups each built their own website years ago, half of them are out of date, and prospective students and partners abroad cannot read them in their own language.

// What we would build

A designed set of research group websites on one platform, each group editing its own people, projects and publications, in the languages you choose, with an assistant that answers visitors from the sites' own pages and hands anything about admissions or partnerships to a person.

// What is in it

// Stack

• Next.js
• Headless CMS
• Claude API
• ORCID API
• DigitalOcean Toronto

// The problem

Researchers move between three universities' labs and shared facilities, and each institution keeps its own spreadsheet of safety training, so people repeat courses or work in labs their training does not cover.

// What we would build

A training records app for each institution, with expiry reminders and checks at booking, and each completed course written to a private permissioned ledger that every institution runs a node of, so a partner can confirm someone's training without asking for a spreadsheet. A shared database run by one institution often does this job; the ledger helps when no single institution should hold the record.

// What is in it

// Stack

• Next.js
• Hyperledger Besu (private, permissioned)
• PostgreSQL
• DigitalOcean Toronto