The Crunchy Details

Let me walk you through how we actually build these applications. The process is deliberately straightforward, because infrastructure should enable development, not consume it.

Step one is setting up a prototype with two key components: a React SPA using react-router for client-side navigation, and a FastAPI backend for our Python code. Initially, we keep these together in a single container. Yes, having our FastAPI server handle static file serving isn't the most efficient setup - we'll eventually want nginx for that - but it gives us a crucial advantage: guaranteed synchronization between frontend and backend during early development. Our Dockerfile for this initial setup is refreshingly simple:

** INSERT DOCKERFILE **

With this foundation, we set up automated deployments on Render. This is where the magic happens for client collaboration.

Frontend: Single Page Application (React)

I previously mentioned using Next.js - and I still do! This very site is a hybrid app/pages router Next.js app. But I've found that for most of my clients, a Single Page Application (SPA) is a better fit.

First, the client's applications are often more interactive and dynamic than an e-commerce website. So the benefits of server-side rendering are less pronounced.

Secondly, and this may be more important for a consultancy, SPAs are easier to hand off to my clients. Most of my clients have a small team of developers who are more comfortable with backend development. An SPA has a cleaner separation between the frontend and backend. Are we looking at python code? That will always be running on the server, with access to internal resources. Are we looking at javascript code? That's running clientside. It's also easier to deploy - no need to worry about how to deploy Next.js's api routes.

Finally, and this is definitely personal preference, but libraries like tanstack query make it easy to manage complex data fetching on the client. Doing that serverside with Next.js can avoid data-fetching waterfalls (where client-side network calls bottleneck each other) but to my eye the complexity is not worth the tradeoff.

Backend: Python FastAPI

For biotech apps, you are mostly stuck with Python, at least somewhere. Companies like MantleBio leverage go for their backend, and presumably have microservices to handle the python-heavy workloads. My view is that the gains from having a "backend monolith" is worth the downside of having to write and maintain python code.

Given that, I've found FastAPI to be a great choice for building python backends. Especially for simpler applications or exploratory work, it's very easy to get started with. Django is a bit too heavy for my taste, but it is battle-tested and has a lot of features you might need out of the box.

Reaping the Benefits

These principles have proven their worth across multiple biotech projects. Take Tatta Bio, where we were developing novel user interfaces for their data analysis pipeline. The ability to deploy prototype features to preview URLs transformed their user testing process. Instead of scheduling synchronous feedback sessions, their scientists could experiment with new interfaces at their own pace, testing with real data in a production-like environment. The fast feedback loop meant we could iterate rapidly on their scientist's workflows.

Resync Bio presented a different challenge. They needed to demo their platform to a potential client, but with complete data isolation. Our architecture made this straightforward - we spun up a custom preview deployment that let their prospect upload and analyze proprietary data without worrying about multi-tenant complications. What could have been a complex infrastructure challenge became a simple deployment configuration. These aren't just technical wins - they're business wins. In biotech, where data sensitivity and scientific workflows are paramount, having an infrastructure that's both robust and flexible isn't a luxury. It's a requirement. By starting with a clear separation of concerns and a simple deployment model, we give teams room to grow without painting themselves into architectural corners.

The best part? This approach scales with your needs. When you do need to separate your frontend and backend deployments, the migration path is clear. When you need to add specialized computing resources for bioinformatics tasks, the integration points are obvious. You're never locked in - you're just starting from a pragmatic foundation.