I Move Fast On Infrastructure And Slow On Architecture.

I move fast on infrastructure and slow on architecture.

That's the whole ballgame.

Ten years ago, if you built the "right" way, you burned weeks of runway before writing a single line of customer-facing code. So founders optimized for speed at all costs, promising to clean it up later.

But later is expensive. Later is when the VC is watching, and customers are yelling.

Today, the commodities (auth, storage, email, deployments, monitoring) are effectively free in both time and money. Because AI and managed services let me set them up in hours, I'm not trading speed for quality anymore.

I'm trading speed for flexibility.

Take the infrastructure layer itself. Spinning up a container on Cloud Run or AWS Fargate takes minutes, not weeks. These services scale from zero to thousands of concurrent instances based on real traffic. S3 handles exabytes of static assets without breaking a sweat. Drop a managed PostgreSQL instance behind it with connection pooling enabled, and this stack realistically handles millions of daily active users out of the box, as long as you keep your app stateless. The physical scaling problem is solved. It's the logical data relationships that still keep me up at night.

Here's where I actually slowed down on my last MVP:

I was building an AI customer support widget that businesses can train on their docs and drop onto their website in minutes.

Auth, file uploads for training documents, and the widget embed script generation? Done in a morning. Clerk and S3, never thought about them again.

The background job to chunk and embed documents when a business updates their knowledge base? Inngest. Set it up in an afternoon.

But I spent days designing how the knowledge base should represent customer information.

PDFs are messy. Tables, images, scanned docs, and layouts all parse differently. FAQs have a different structure than product manuals. Policies have version histories. A 500-page technical reference needs a completely different representation than a two-paragraph return policy. And when a customer uploads version 2 of a document, do you rebuild the entire index or just re-embed the affected documents and update the index? That choice dictates your update latency and consistency model for every customer going forward.

That decision cascaded into everything else. Evaluation became critical. How do you measure retrieval quality against real customer behavior instead of synthetic examples? Without a reproducible benchmark, every improvement is just a guess.

Document lifecycle forced me to think about synchronization. How do you avoid stale chunks when a document is deleted or revised mid-day? Multi-tenancy had to be correct on day one. Metadata isolation and access control during retrieval aren't optional in a SaaS product. There is no "fix it later" for leaking one customer's data to another.

Retrieval quality is bounded by what you indexed. Teams spend months on prompt tuning and model selection. The knowledge base gets a fraction of that attention. But you cannot fix a poorly structured corpus with a better retrieval pipeline.

By the time a user asks a question, most of the important engineering decisions have already been made.

Now, about the dollars.

Yes, managed services cost more than raw VMs at hyper-scale. Fargate and RDS carry a 15-20% premium over self-managed boxes. But here's the math that actually matters: at the MVP stage, say up to 10,000 active users, that premium is roughly $100/month extra. The cost of a single engineer spending one week maintaining their own Kubernetes cluster or handling Postgres failover is $6,000 to $12,000 in burned runway. You aren't saving money by avoiding managed services; you're spending $10k to save $100. At this stage, the tradeoff isn't cost; it's leverage. Pay the coffee bill to keep your team sprinting on product differentiation.

The new rule I follow now:

If a service has a free tier and a well-documented SDK, I treat it as rented scaffolding. I don't care if I replace it.

If a decision touches how data relates to other data, or how business rules are enforced across the system, I treat that like load-bearing concrete. Because that's what actually costs me a rebuild.

The final takeaway for founders:

Stop asking, "Will this scale to a million users?"
Start asking, "If we pivot our pricing model, add a new data source, or change our go-to-market strategy, does this decision make that easy or hard?"

Build the foundation assuming the product will change.

Because it will.

But thanks to 2026 economics, the parts that don't need to change (login, storage, email) can be rock-solid from day one without sacrificing a single day of shipping speed. That's not over-engineering. That's just not being stupid with your leverage.