You can't just follow the latest e-commerce playbook.

Fundamentally, a serverless architecture assumes your endpoints are small, fast, and stateless. Biotech applications are rarely so well behaved.

One of Nitro Bio's first clients was Sphinx Bio, a data platform that helps integrate wet lab and computational teams. When I first started building their web application, I did what any hip web developer in 2023 would do - I reached for Next.js and Vercel. For the first two weeks, frontend development sailed along, bouyed by full-stack type checking, preview deployments, and immaculate Lighthouse scores. The next sprint was a bit choppier. In addition to the basic auth/CRUD endpoints we were building in typescript, we also had to set up some python endpoints so we could interface with bioinformatics libraries. To Vercel's credit, we could colocate our python endpoints in the same codebase and they more-or-less worked!

But by the third sprint we ran into more fundamental incompatibilities between bioinformatics software and a serverless-first approach. Fundamentally, a serverless architecture assumes your endpoints are small, fast, and stateless. Biotech applications are rarely so well behaved.

NCBI's BLAST is a classic example - a foundational tool that lets you search for similar DNA/AA sequences in a database. But BLAST was built for bioinformaticians, who generally run BLAST on an ad-hoc basis on their local machines or on directly managed remote servers. Even when run on big iron, BLAST may take several minutes to run depending on the query size and search space. The program itself is approximately 200MB, and it needs to write relatively large database files to disk before running.

If you try to wedge this into a serverless architecture, you'll be stepping on a lot of rakes: strict timeout limits, memory constraints, and the lack of a persistent file system. You can try (expensive) bandaids for these issues - but you're ameliorating the natural weaknesses of the architecture and not enjoying its strengths.

So does building a biotech application mean you have to give up Vercel's amazing developer experience and suffer the indignities of the AWS console? Mercifully, we can have our cake and eat it too.

Infrastructure: Render.com

If I have the choice, I use Render.com to build my client's web applications. Years later my clients are still happy with that choice!

The key feature Vercel provided, perhaps especially vital for a consultancy, was Preview Environments. They transformed how we work with clients. Since every pull request creates its own deployment, we can run experiments, share progress, and get feedback quickly and asynchronously. No more scheduling screen-sharing sessions just to show a small change. Clients can experiment with new features on their own time, share links with their team, and give rapid feedback.

This immediate visibility has another, less obvious benefit: it builds momentum. There's something powerful about a client being able to see their application rapidly evolve over time. Days (sometimes just hours!) after I talk through an idea with a client I send them a link to a prototype. Even if it's just a landing page with placeholder text, it shows them that their project is real, deployable, and progressing.

Render has great support for preview environments, spinning up a dedicated VM for each pull request. You lose the power of horizontal scaling that a serverless architecture provides, but you are no longer fighting against your own architecture when you build biotech applications. Plus, you can always scale vertically.

So if I have the choice, I use Render.com to build my client's web applications. Years later my clients are still happy with that choice!

---

So, to wrap up: I've found that a modern architecture for biotech web applications is to use Render.com for infrastructure, as it marries an excellent dev experience with a VM-based architecture that fits the assumptions of bioinformatics utilities. In the next post (coming next week!) I'll walk through exactly how I set up a three tier web application on render.