Building Scalable Infrastructure That Actually Serves the Business

When Daniel approached me about Tendr, he had a proof of concept but needed a technical co-founder to turn it into production infrastructure. The timing aligned with a strategic market shift I’d been watching closely: the EU doubling down on intra-European trade and public procurement in response to geopolitical tensions. Public procurement across Europe is fragmented and difficult to navigate, but regulatory digitisation and economic pressure created a clear opportunity. At Tendr, we’re building an AI-powered bid intelligence platform to help suppliers win more public contracts across jurisdictions. We’re currently in pilot with seven organisations, with our MVP beta launching in Q1 2026. The challenge is familiar: turning messy, unstructured data into actionable intelligence—this time in a market that’s actively transforming.

The jump from “it works” to “it scales” exposes three challenges most founders underestimate. First: cost becomes architecture. At EVERYANGLE, our early ML inference approach worked fine for demos. But at scale, it would have destroyed our unit economics. The solution wasn’t making things faster—it was redesigning systems to be 80–90% cheaper while maintaining the same SLA. We moved to batch processing and aggressive spot instance orchestration, designing for constant infrastructure turnover. A reliable system built on unreliable infrastructure. Second: observability is infrastructure. We were processing millions of events across 25+ microservices before we realised we couldn’t diagnose issues fast enough. Observability couldn’t be an afterthought. We embedded it into the architecture with ELK, Prometheus, Grafana, and custom metrics. This drastically reduced MTTR and let us detect problems before customers did. Third: team velocity is a technical problem. We reduced lead time from 19 days to 5—not through process theatre, but by improving developer experience. Reusable Terraform modules, CI/CD pipelines, automated testing, and pre-commit hooks meant engineers spent time delivering value instead of fighting infrastructure. Scaling requires rethinking the assumptions your early system was built on.

The decisions that shaped our trajectory fell into two camps: shortcuts that hurt us and investments that unlocked scale. What nearly broke us: We outsourced our business intelligence dashboards to an external vendor. It seemed efficient, but it became a bottleneck. Long lead times, inflexibility, and unreliable software damaged customer trust. The lesson was simple: you can’t outsource anything critical to the customer experience. What made scale possible: Our infrastructure evolution was messy but instructive—Python scripts, edge devices, manual EC2 provisioning, painful CloudFormation experiments. When we eventually moved to Terraform, managed services, ECS, and finally Kubernetes, it wasn’t premature optimisation. We knew exactly which problems we were solving. What won enterprise deals: Our commitment to a vendor-agnostic, multi-cloud architecture. Some retailers wouldn’t work with specific cloud providers. Others required strict data separation. Our flexibility removed deal-breaking objections before they surfaced. The technical cost was high, but the business value was undeniable.

It’s not about company size or revenue stage. It’s about feedback. From day one at EVERYANGLE, we treated CI/CD, basic security architecture, and monitoring as non-negotiables—not because they were sophisticated, but because they provided fast, deterministic feedback. We enforced test coverage not for compliance, but because testability forces better design. Over six years, this approach resulted in zero security incidents. Other things evolved when friction justified them. Infrastructure as Code came when manual changes became painful. SOC 2 preparation happened when security questionnaires slowed sales. The trap is premature optimisation—adopting trendy tools before the problem exists. Technology choices follow pain, not hype. The real minimum is simple: fast, reliable signals that tell you whether your system works and whether it’s secure.

Remote success isn’t about tools—it’s about system design. Cultural misunderstandings taught me to eliminate ambiguous yes/no questions. Instead of asking, “Can you deliver by Friday?”, I asked, “What are the biggest risks to Friday?” This shifted conversations from commitment theatre to problem-solving. We built asynchronous reliability through strict documentation, screen-recorded handovers, end-of-day updates, and a single source of truth. Meetings started with silent reading. Decisions weren’t real until documented. Work-life boundaries were enforced through architecture, not policy: 24-hour response SLAs, scheduled messaging across time zones, meeting-free opt-outs, and local public holidays. Recognition was specific and impact-driven. Authority was delegated, not outcomes.

The most elegant solution is often the one you don’t build. At EVERYANGLE, every feature passed three reality checks: Actionability, Trust & privacy, and Compute trade-offs. We killed technically impressive features that delivered no real-world value. Ambition belonged where it moved the needle, like reducing infrastructure costs by 80–90%, which directly improved margins. Fast feedback loops allowed us to move quickly without breaking things. Technical excellence mattered, but only when it served real outcomes.

Design systems—technical and human—that make the right behaviour the easiest behaviour. Most failures don’t come from lack of intelligence or effort. They come from systems that reward shortcuts, hide problems, or exhaust the people inside them. If your infrastructure, processes, and culture encourage clarity, feedback, and sustainable pace, good outcomes follow naturally. Build for learning, not perfection.