Why We Rebuilt Our Website on Cloudflare

At Tailwind Resource Group, we advise federal agencies and enterprises on complex infrastructure decisions every day. So when it came time to rethink our own web presence, we held ourselves to the same standard: evaluate the problem honestly, choose the right architecture, and build it properly.

Our previous site ran on HubSpot. It worked — but as an engineering-led firm, we found ourselves constrained by a platform designed primarily for marketing automation. We needed something that reflected how we actually think about infrastructure: resilient, performant, secure, and built to grow.

Reliability at the Edge

Cloudflare operates one of the largest global networks in the world, spanning more than 300 cities across 100+ countries. By building on Workers, Pages, and D1, our site doesn't depend on a single origin server or region. Content is served from the edge location nearest each visitor, and the underlying platform handles failover automatically. For a company that helps clients design high-availability architectures, it matters that our own site reflects that same principle.

Performance by Design

We chose Astro as our frontend framework because it generates static HTML with zero JavaScript by default — pages load fast because there's simply less to download and parse. Combined with Cloudflare's global CDN, our pages reach visitors in milliseconds regardless of geography. Payload CMS runs on Workers at the edge, so even our content management layer benefits from the same distributed architecture. The result is a site that feels instant, not because we over-optimized, but because we chose the right tools.

Security as a Foundation

Security isn't a feature we bolt on — it's foundational to everything we do at Tailwind. Cloudflare's platform provides DDoS mitigation, Web Application Firewall, and TLS termination at the edge before traffic ever reaches our application. Payload CMS gives us fine-grained access control over every API endpoint and content operation. Static site generation eliminates entire categories of server-side vulnerabilities. As a team that holds PCNSE, F5-CTS, and CCNP certifications and partners with Palo Alto Networks, CrowdStrike, and Okta, we apply the same security-first thinking to our own infrastructure that we bring to our clients.

Vendor Diversity and Strategic Choice

We partner with Cloudflare, F5, Palo Alto Networks, Okta, and CrowdStrike — not because we're locked into any single vendor, but because we believe in choosing the right tool for each problem. Rebuilding on Cloudflare wasn't a default decision; it was a deliberate architectural choice. Their developer platform offered the best combination of edge compute, storage, and CDN for this particular workload. That same discipline — evaluating options honestly and recommending what actually fits — is what our clients expect from us.

Built for What Comes Next

This architecture isn't just solving today's problem. Cloudflare Workers gives us a serverless compute layer we can extend as needs evolve — whether that's adding authenticated client portals, integrating with contract vehicle databases, or building interactive tools for our federal customers. The monorepo structure and modern toolchain mean our team can ship changes quickly without accumulating technical debt. We designed this platform to grow with the business, not constrain it.

Practice What You Preach

There's a credibility gap when a technology services firm runs its own site on a platform it would never recommend to clients. We closed that gap. This migration is our first published case study — a real-world example of assessing requirements, designing an architecture, implementing it on modern infrastructure, and delivering measurable results. The cost savings alone were significant, but more importantly, we now run on infrastructure we're proud to stand behind.

If you're evaluating a similar move — whether it's modernizing a legacy web platform, adopting edge computing, or rethinking your cloud strategy — we'd welcome the conversation. This is exactly the kind of problem we solve.

// Interface definition
interface User {
  id: number;
  name: string;
  email: string;
  isActive: boolean;
}

// Enum example
enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE",
  Pending = "PENDING"
}

// Generic function
function filterByStatus<T extends { status: Status }>(
  items: T[],
  status: Status
): T[] {
  return items.filter(item => item.status === status);
}

// Class with methods
class UserManager {
  private users: User[] = [];

  constructor(initialUsers: User[] = []) {
    this.users = initialUsers;
  }

  addUser(user: User): void {
    if (this.validateEmail(user.email)) {
      this.users.push(user);
    }
  }

  getUserById(id: number): User | undefined {
    return this.users.find(u => u.id === id);
  }

  private validateEmail(email: string): boolean {
    return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  }

  async fetchUserData(userId: number): Promise<User | null> {
    try {
      const response = await fetch(`/api/users/${userId}`);
      if (!response.ok) throw new Error('Failed to fetch');
      return await response.json();
    } catch (error) {
      console.error('Error:', error);
      return null;
    }
  }
}

// Async/await usage
const manager = new UserManager();

const testUser: User = {
  id: 1,
  name: "John Doe",
  email: "john@example.com",
  isActive: true
};

manager.addUser(testUser);

// Template literals
const greeting = `Hello, ${testUser.name}!`;
console.log(greeting);

This is a big deal

It really is, so is this: