DEV Community: Richard Sandown

Remote Development Team Building Software for Remote Locations

Richard Sandown — Tue, 28 Oct 2025 19:55:17 +0000

The irony, challenges, and unexpected advantages of distributed developers building software for off-grid campgrounds

Our senior frontend developer was pair programming from a cabin in rural Vermont with spotty internet. Our backend lead was debugging API calls from a co-working space in Barcelona. Our designer was reviewing mockups from a coffee shop in Austin. And I was on a video call with all of them, sitting in my home office in Seattle, discussing how to optimize Camprs for campground managers in locations with even worse connectivity than our developer in Vermont.

The irony wasn't lost on us: we're a fully remote team building software specifically designed to work in remote locations where internet is unreliable, power is intermittent, and "going to the office" means walking across a campground.

This unusual situation—remote workers building for remote workers—has taught us valuable lessons about distributed development, offline-first architecture, and understanding users by living similar constraints. This post shares what we've learned about building Camprs as a remote team serving remote locations.

The Meta-Remote Challenge

Most remote development teams build software for users in cities with reliable infrastructure. We're building for campgrounds in places like:

National forests where cellular coverage is measured in bars, not megabits
Rural areas where "high-speed internet" means DSL if you're lucky
Seasonal operations that might lose power during storms
Properties spread across hundreds of acres where WiFi doesn't reach everywhere

This creates an unusual development dynamic: our team experiences connectivity challenges that pale in comparison to what our users face, but are still significant enough to inform our technical decisions.

Understanding Through Experience

When our Vermont-based developer's internet drops during a critical deployment, we're reminded viscerally why Camprs needs robust offline capabilities.

When our designer tries to upload mockups over a slow connection, we understand why image optimization isn't optional for campground software.

When pair programming over video becomes impossible due to bandwidth constraints, we appreciate why Camprs can't require constant connectivity for core functionality.

This shared experience of connectivity challenges—even if less severe than our users face—creates empathy that shapes our technical architecture.

Our Distributed Team Structure

Camprs is built by a team of seven developers spread across four time zones and three countries:

Frontend team:

Sarah (Vermont, EST) - React/TypeScript, mobile optimization
Marcus (Austin, CST) - UI/UX implementation, component library
Elena (Barcelona, CET) - Progressive Web App functionality, offline features

Backend team:

James (Seattle, PST) - API design, database architecture
Priya (Toronto, EST) - Integrations, third-party services
Alex (Portland, PST) - DevOps, infrastructure, performance

Design:

Jordan (Remote, various locations) - Product design, user research

This distribution isn't theoretical remote work where everyone's actually in the same city but works from home. We're genuinely distributed, which creates both challenges and advantages for building campground software.

Architectural Decisions Driven by Remote Reality

Our distributed team structure directly influences Camprs' technical architecture:

Offline-First by Necessity and Empathy

Building as a remote team with variable connectivity made offline-first architecture not just a user requirement but a personal necessity.

Service Worker implementation:

// Our service worker handles offline scenarios we've personally experienced
const CACHE_VERSION = 'camprs-v1.2.3';
const CORE_CACHE = [
  '/',
  '/schedule',
  '/bookings',
  '/staff',
  '/manifest.json',
  '/offline.html'
];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_VERSION).then((cache) => {
      // Aggressively cache core functionality
      // We know from experience what users need when offline
      return cache.addAll(CORE_CACHE);
    })
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    // Network first for API calls (fresher data when available)
    fetch(event.request)
      .then((response) => {
        // Clone response for cache storage
        const responseClone = response.clone();
        caches.open(CACHE_VERSION).then((cache) => {
          cache.put(event.request, responseClone);
        });
        return response;
      })
      .catch(() => {
        // Fall back to cache when network fails
        // This is the scenario we personally hit multiple times weekly
        return caches.match(event.request).then((cachedResponse) => {
          if (cachedResponse) {
            return cachedResponse;
          }
          // Return offline page as last resort
          return caches.match('/offline.html');
        });
      })
  );
});

This isn't theoretical offline support—it's based on real experiences of developers trying to work with unreliable connections.

Async Communication by Design

Remote teams communicate asynchronously by necessity. This directly influenced how we built Camprs:

Event-driven architecture:

// Changes propagate through events rather than requiring real-time sync
class BookingEventEmitter {
  constructor() {
    this.events = {};
    this.eventQueue = []; // Queue events when offline
  }

  emit(eventType, data) {
    // Try to send immediately if online
    if (navigator.onLine) {
      this.sendToServer(eventType, data);
    } else {
      // Queue for later if offline
      this.eventQueue.push({ eventType, data, timestamp: Date.now() });
      this.persistQueue(); // Save to IndexedDB
    }

    // Trigger local event handlers immediately
    if (this.events[eventType]) {
      this.events[eventType].forEach(callback => callback(data));
    }
  }

  async syncQueuedEvents() {
    // When connection returns, sync queued events
    while (this.eventQueue.length > 0 && navigator.onLine) {
      const event = this.eventQueue[0];
      try {
        await this.sendToServer(event.eventType, event.data);
        this.eventQueue.shift();
      } catch (error) {
        console.error('Failed to sync event', error);
        break; // Stop syncing if we hit an error
      }
    }
    this.persistQueue();
  }
}

This event-driven approach emerged from our team's experience working asynchronously across time zones. Messages don't require immediate responses; actions queue and process when possible.

Documentation as First-Class Concern

Remote teams live or die by documentation. This influenced how we document Camprs:

Comprehensive API documentation:

# OpenAPI spec for every endpoint
/api/bookings:
  post:
    summary: Create new booking
    description: |
      Creates a new campground booking. Can be called offline - booking
      will queue and process when connection returns.

      Offline behavior:
      - Returns 202 Accepted immediately
      - Queues booking for sync when online
      - Updates local state optimistically
      - Syncs with server when connection available

      Common issues:
      - Site availability checked against cached data when offline
      - Conflicts resolved server-side (first booking wins)
      - Failed bookings trigger notifications to campground manager
    parameters:
      - name: site_id
        required: true
        description: Campsite identifier
      - name: check_in
        required: true
        description: Check-in date (YYYY-MM-DD)
      - name: check_out
        required: true
        description: Check-out date (YYYY-MM-DD)

Every endpoint is documented with offline behavior explicitly described—because we've personally struggled with undocumented offline behavior in tools we use.

Code documentation standards:

/**
 * Handles booking creation with offline support
 * 
 * @param {Object} bookingData - Booking details
 * @param {string} bookingData.siteId - Campsite ID
 * @param {Date} bookingData.checkIn - Check-in date
 * @param {Date} bookingData.checkOut - Check-out date
 * 
 * @returns {Promise<Booking>} Created booking
 * 
 * @offline Queues booking for later sync
 * @throws {ValidationError} If booking data invalid
 * @throws {ConflictError} If site unavailable (online only)
 * 
 * @example
 * // Basic booking creation
 * const booking = await createBooking({
 *   siteId: 'site-123',
 *   checkIn: new Date('2024-06-15'),
 *   checkOut: new Date('2024-06-17')
 * });
 * 
 * @example
 * // Handling offline scenario
 * try {
 *   const booking = await createBooking(bookingData);
 *   if (booking.status === 'queued') {
 *     showMessage('Booking saved. Will confirm when online.');
 *   }
 * } catch (error) {
 *   handleBookingError(error);
 * }
 */
async function createBooking(bookingData) {
  // Implementation
}

Detailed documentation isn't optional when you can't just tap someone on the shoulder to ask how something works.

Development Practices Shaped by Distribution

Our remote nature influenced specific development practices:

Async Code Reviews

Pull requests can't rely on real-time discussion. We've developed patterns for effective async reviews:

## Pull Request Template

### What This Changes
Clear description of what's changing and why

### Technical Approach
Explain key technical decisions, especially around offline handling

### Testing
- [ ] Tested offline functionality
- [ ] Tested on slow connection (throttled)
- [ ] Tested cross-browser (Chrome, Safari, Firefox)
- [ ] Tested on mobile devices

### Offline Behavior
Explicit description of how this works offline:
- What's cached?
- What queues for later sync?
- How are conflicts handled?

### Questions/Concerns
Things you're uncertain about or want specific feedback on

### Screenshots/Video
Visual context helps async reviewers

Reviewers can understand context without synchronous communication.

Timezone-Aware Development Flow

With team members in EST, CST, PST, and CET, we structure work to minimize timezone friction:

Handoff-oriented workflow:

Morning (PST):
- Seattle team reviews overnight work from Barcelona
- Portland deploys changes
- Code reviews for EST team members

Afternoon (PST):
- Overlap time with EST team (meetings if needed)
- Pair programming when beneficial
- Deploy features ready for testing

Evening (PST):
- Prepare handoff notes for Barcelona team
- Document any blockers
- Queue reviews for next morning

This creates a "follow-the-sun" development pattern where work progresses around the clock—similar to how Camprs needs to work for campgrounds operating across time zones.

Remote Pairing with Poor Connectivity

Traditional pair programming assumes good connectivity. We've adapted:

Async pairing through PRs:

## Pairing Session: Offline Booking Queue

@sarah starting the implementation. Approach:

1. IndexedDB for queue storage
2. Background sync API for processing
3. Conflict resolution on server side

Pushed initial implementation in commit abc123.

@marcus can you review the conflict resolution logic?
Specifically concerned about race conditions when
multiple devices sync simultaneously.

---

@marcus reviewed. Thoughts:

The race condition is real. Suggestion: add timestamp
and device_id to queued items. Server picks first by
timestamp, rejects duplicates.

See comments in code for specific suggestions.

---

@sarah implemented your suggestions in commit def456.
Added integration tests for race condition scenarios.

Ready for your final review before merge.

This async pairing lacks the immediacy of real-time collaboration but creates valuable documentation of decision-making.

Testing in Realistic Conditions

Our distributed team naturally tests in varied network conditions:

Chrome DevTools network throttling:

// Testing scenarios we personally encounter
const networkProfiles = {
  'Vermont DSL': {
    downloadThroughput: 1.5 * 1024 * 1024 / 8, // 1.5 Mbps
    uploadThroughput: 384 * 1024 / 8, // 384 Kbps
    latency: 150
  },
  'Rural Campground': {
    downloadThroughput: 512 * 1024 / 8, // 512 Kbps
    uploadThroughput: 128 * 1024 / 8, // 128 Kbps
    latency: 300
  },
  'Spotty Cellular': {
    downloadThroughput: 750 * 1024 / 8,
    uploadThroughput: 250 * 1024 / 8,
    latency: 200,
    // Simulate intermittent disconnections
    disconnectProbability: 0.15
  }
};

Team members regularly test Camprs under conditions similar to what they personally experience—and what campground managers face.

Advantages of Remote Team for Remote Software

Building remotely has unexpected advantages for our specific product:

We Experience Similar Constraints

When our designer works from cafes with variable WiFi, they understand why Camprs needs to handle connection drops gracefully.

When our developers work from home offices during power outages on battery, they appreciate why Camprs minimizes battery drain.

When our team does video calls on limited bandwidth, we're reminded why Camprs can't require constant streaming data.

Geographic Distribution Matches User Distribution

Our team spread across North America and Europe mirrors campground distribution. We're not building from a Silicon Valley bubble—we're distributed like our users.

Variable Schedules Match Seasonal Patterns

Remote work enables flexible schedules. Team members working at odd hours understand why campground managers need access to Camprs at 2 AM during emergencies or 6 AM before busy weekends.

Understanding Infrastructure Limitations

Living with infrastructure constraints that don't match urban tech worker experience helps us build with empathy for campground operators facing similar (or worse) constraints.

Challenges We Still Face

Remote development for remote locations isn't without difficulties:

Testing Truly Remote Scenarios

Even with throttling tools, we can't perfectly simulate:

Completely offline for days (like seasonal campgrounds closing for winter)
Intermittent power affecting device charging
Multiple devices syncing after long offline periods
Edge cases in truly remote locations

Our solution: Regular field visits to actual campgrounds to use Camprs in real conditions and gather feedback from users experiencing genuine remote scenarios.

Coordination Across Time Zones

With team members spanning 9 hours of time zones, finding overlap time for synchronous collaboration requires careful planning.

Our solution: Core overlap hours (1-3 PM PST / 4-6 PM EST / 10 PM-12 AM CET) for necessary meetings, with heavy reliance on async communication otherwise.

Cultural and Communication Differences

Remote teams amplify communication challenges. What's direct in one culture is rude in another. Text lacks tone and body language cues.

Our solution: Over-communicate context. Use video for sensitive discussions. Document communication norms explicitly. Build relationships through virtual social time.

Onboarding Remote Developers

Getting new team members up to speed without in-person shadowing requires extra effort.

Our solution: Comprehensive onboarding documentation, pair programming via screen sharing, regular check-ins during first month, buddy system for questions.

Tools That Enable Our Remote Team

Specific tools make our distributed development possible:

Communication

Slack: Async communication for most discussions

Channels organized by feature area
Expectations about response times
Important decisions documented in threads

Zoom: Synchronous communication when needed

Weekly all-hands
Pair programming sessions
Design reviews requiring discussion

Loom: Async video for complex explanations

Code walkthroughs
Bug reproductions
Feature demonstrations

Code Collaboration

GitHub: Central code repository

Comprehensive PR templates
Automated checks before merging
Integration with project management

Linear: Issue tracking and project management

Clear issue descriptions
Async updates on progress
Roadmap visibility

Notion: Documentation and knowledge sharing

Architecture decisions recorded
Onboarding documentation
Meeting notes archived

Development Environment

Docker: Consistent environments across machines

# Everyone runs the same development environment
FROM node:18-alpine

WORKDIR /app

# Install dependencies
COPY package*.json ./
RUN npm ci

# Copy application
COPY . .

# Expose port
EXPOSE 3000

CMD ["npm", "run", "dev"]

VS Code Live Share: Real-time collaboration when pair programming

Postman: Shared API collections for consistent testing

Building Features for Remote Users, Remotely

Specific Camprs features emerged from our remote development experience:

Offline-First Booking Management

Because we've all tried to book things with poor connections:

// Optimistic booking creation
async function createBookingOfflineFirst(bookingData) {
  // Create local booking immediately
  const localBooking = {
    ...bookingData,
    id: generateLocalId(),
    status: 'pending_sync',
    created_offline: !navigator.onLine,
    created_at: new Date().toISOString()
  };

  // Save to IndexedDB
  await saveToLocalDB('bookings', localBooking);

  // Update UI immediately
  updateUIOptimistically(localBooking);

  // Try to sync with server
  if (navigator.onLine) {
    try {
      const serverBooking = await syncBookingToServer(localBooking);
      await updateLocalDB('bookings', serverBooking);
      return serverBooking;
    } catch (error) {
      // Server sync failed, keep local version
      console.warn('Booking saved locally, will sync later');
      return localBooking;
    }
  }

  return localBooking;
}

Conflict Resolution UI

Because we've experienced sync conflicts in our own tools:

// Show users when conflicts occur and let them resolve
function showConflictResolution(localVersion, serverVersion) {
  return (
    <ConflictModal>
      <h2>This booking was modified while offline</h2>

      <ComparisonView>
        <Version label="Your Changes">
          <BookingDetails booking={localVersion} />
        </Version>

        <Version label="Current Version">
          <BookingDetails booking={serverVersion} />
        </Version>
      </ComparisonView>

      <Actions>
        <Button onClick={() => resolveConflict('keep_local')}>
          Keep My Changes
        </Button>
        <Button onClick={() => resolveConflict('keep_server')}>
          Use Current Version
        </Button>
        <Button onClick={() => resolveConflict('manual')}>
          Merge Manually
        </Button>
      </Actions>
    </ConflictModal>
  );
}

Sync Status Transparency

Because we hate when tools don't tell us what's happening:

// Always show sync status
function SyncIndicator({ syncStatus }) {
  const indicators = {
    synced: {
      icon: '✓',
      color: 'green',
      message: 'All changes synced'
    },
    syncing: {
      icon: '⟳',
      color: 'blue',
      message: 'Syncing changes...'
    },
    offline: {
      icon: '○',
      color: 'orange',
      message: 'Working offline - will sync when online'
    },
    error: {
      icon: '!',
      color: 'red',
      message: 'Sync error - tap to retry'
    }
  };

  const current = indicators[syncStatus];

  return (
    <StatusBadge color={current.color}>
      <Icon>{current.icon}</Icon>
      <Message>{current.message}</Message>
    </StatusBadge>
  );
}

Lessons for Other Remote Teams

If you're building software remotely—especially for users in remote locations—here's what we've learned:

Embrace Your Constraints as Features

The limitations your team faces (connectivity, timezone distribution, async communication) can inform better product decisions for users facing similar constraints.

Document Everything

Remote teams need documentation. So do remote users. The documentation you create for your team often translates directly into user documentation.

Test in Realistic Conditions

Simulate the conditions your users face. If they have poor connectivity, test with poor connectivity. If they go offline for days, test those scenarios.

Build Async-First

Whether for your team's workflow or your users' experience, async-first architecture creates resilience and flexibility.

Use Your Pain Points

When your tools frustrate you, that's a signal. If your video calls drop, your users' requests will drop. If your connection is slow, theirs is slower. Build solutions that would make your own experience better.

The Bottom Line

Being a remote team building software for remote locations creates interesting dynamics—we're distant from each other but close to our users' experience in unexpected ways.

The connectivity challenges we face as a distributed team inform how we build Camprs. The async communication patterns we've developed for our workflow translate into event-driven architecture. The documentation we create for ourselves becomes user documentation.

Most importantly, experiencing infrastructure limitations firsthand—even if less severe than our users face—creates empathy that shapes technical decisions. We're not building from theory about what remote locations need. We're building from experience with some of the same challenges.

The irony of remote developers building for remote locations isn't just amusing, it's a genuine advantage. Our distributed team is better positioned to serve distributed campgrounds than a co-located team in a well-connected urban office could ever be.

Sometimes the best qualification for solving a problem is experiencing a version of it yourself.

Building software remotely? Serving users in remote locations? We'd love to hear about your experiences, challenges, and solutions. Drop a comment or reach out, remote workers should stick together.

Building Domain Expertise: How Our Developers Became Camping Experts

Richard Sandown — Wed, 01 Oct 2025 21:04:07 +0000

Why understanding campgrounds matters more than understanding code—and how we built a team that knows both

"I don't understand why we need three different site types," Alex said, staring at the database schema we were designing. "Can't we just have one 'campsite' table and add attributes as needed?"

Alex was our lead backend developer—brilliant, experienced, and completely mystified by the complexity of campground operations. To him, a campsite was a campsite. Why did we need to distinguish between RV sites with full hookups, tent-only sites, and cabin rentals?

Six months later, after Alex had spent two weeks working at an actual campground during their busy season, he rewrote that entire section of our codebase.

"I had no idea," he told me. "The differences aren't just technical specifications, they're completely different products with different pricing, different customer expectations, different operational requirements. Our original design would have been a disaster."

This transformation, from developer who codes to developer who understands, is at the heart of building valuable software for any industry. But it's particularly crucial when building tools for domains as specific and nuanced as outdoor recreation.

The Knowledge Gap Problem

Most software developers have never operated a campground, managed an adventure tourism business, or worked in outdoor hospitality. This creates a fundamental challenge: how do you build excellent tools for a domain you don't understand?

The traditional approach is to rely on product managers or domain experts to bridge this gap. Developers focus on code while others handle the "business logic" and translate requirements into technical specifications.

This approach works adequately for simple problems. But it breaks down when building complex, domain-specific software where dozens of small decisions—data structures, workflow designs, interface choices—all require deep understanding of how the business actually operates.

The Specification Problem

Written specifications, no matter how detailed, can't capture the tacit knowledge that campground operators carry. They know instinctively how booking patterns change with weather forecasts, how site assignment affects operational efficiency, and why certain combinations of activities can't be scheduled together.

This knowledge is difficult to articulate and often only becomes apparent when you're actually doing the work.

The Lost in Translation Challenge

When non-technical domain experts communicate with non-domain-expert developers, information gets lost. The campground operator explains a problem in their language, the product manager translates it into requirements, and the developer implements their interpretation of those requirements.

By the time the feature ships, it often solves a different problem than the one the operator actually had.

The Iteration Cost

When developers don't understand the domain, iteration cycles are expensive. Build a feature based on specifications, show it to users, discover it doesn't match their needs, redesign, rebuild, repeat. Each cycle takes weeks or months.

The Immersion Approach

We took a different approach with Camprs: we decided our developers needed to become camping domain experts themselves.

Mandatory Campground Rotations

Every developer on our team spends at least two days working at a partner campground during their first six months with the company. Not observing, actually working. Checking in guests, answering questions, handling reservations, dealing with the chaos of peak season operations.

This isn't a token gesture. Developers work real shifts, including early mornings and busy weekends. They experience the pressure of long check-in lines, the complexity of managing site assignments when half the guests arrive early and others arrive late, and the constant interruptions that make it hard to complete any single task.

The learning is immediate and visceral. Our developers return from these rotations with notebooks full of observations, frustrations about our own software, and ideas for improvements we'd never have considered from the office.

The Things You Can't Learn from Requirements Documents

When Sarah, one of our frontend developers, spent time at a family campground in Vermont, she learned things that changed how she approached interface design:

The phone interruption reality: She discovered that campground staff are interrupted constantly. Any workflow that requires maintaining context across multiple screens is essentially unusable because staff get pulled away every few minutes.

This insight led to a complete redesign of our check-in process, breaking it into small, completable chunks that could be interrupted and resumed without losing progress.

The spatial thinking pattern: She noticed that experienced staff think spatially about the campground. They don't remember site numbers, they remember locations. "The site near the big oak tree" or "the RV spot by the playground."

This observation inspired us to make our visual site map the primary interface rather than a supplementary feature, fundamentally changing how users interact with Camprs.

The weather dependency: Nearly every operational decision campground staff make is influenced by weather. Are sites muddy? Is it too hot for tent campers? Will rain drive people to covered activities?

We realized weather integration wasn't a nice-to-have feature—it needed to be woven throughout the entire system.

Working Alongside the Customers

The immersion creates something more valuable than just knowledge, it creates empathy. When you've personally dealt with a frustrated guest whose reservation got lost, or struggled to figure out which sites are actually available, you build software differently.

You care more about edge cases because you've experienced them. You think harder about error messages because you've been the one trying to understand them while three families wait impatiently in line. You prioritize differently because you understand which features actually matter in the moment.

Building Domain Expertise into the Development Process

Beyond the initial immersion, we've built domain learning into our ongoing development process.

Customer Advisory Board

We maintain an advisory board of campground operators who meet with our development team monthly. These aren't formal presentations, they're working sessions where we show half-built features and get immediate feedback.

The key is that developers present directly rather than filtering feedback through product managers. This creates direct communication channels between the people building the software and the people using it.

Support Rotation

Every developer spends one week per quarter doing customer support. They handle incoming questions, troubleshoot problems, and talk directly with users who are frustrated or confused.

This practice, borrowed from other product companies, is invaluable for maintaining domain expertise. You quickly learn which features are confusing, which workflows don't match how people actually work, and which problems keep recurring.

Field Testing Requirements

Before we build major features, we send developers to campgrounds to observe and validate the problem we're trying to solve. This often reveals that the feature request we received describes a symptom rather than the underlying problem.

A request for "better reporting on site occupancy" might actually stem from a need to optimize cleaning crew scheduling. Building the requested report wouldn't solve the real problem, but understanding the underlying need leads to a better solution.

Industry Event Attendance

We encourage developers to attend campground industry conferences and trade shows. Not manning a booth or doing sales—just attending sessions, talking to operators, and understanding industry trends and challenges.

These events provide context about the broader business environment our customers operate in: regulatory changes, competitive pressures, economic conditions, and evolving customer expectations.

The Technical Benefits of Domain Expertise

Domain expertise isn't just about building the right features, it fundamentally improves the technical quality of the software.

Better Data Modeling

Developers who understand campground operations build better database schemas because they understand the relationships and constraints that aren't obvious from outside the domain.

For example, understanding that some campgrounds assign specific sites at booking while others assign site types (and allocate specific sites at check-in) is crucial to database design. Getting this wrong makes the system rigid and unable to accommodate different operational models.

Smarter Architecture Decisions

Domain expertise helps developers make better architectural choices. Understanding seasonal traffic patterns influences caching strategies. Knowing that campgrounds often have poor internet connectivity affects decisions about which operations can be cloud-based versus local.

These aren't decisions that can be made purely from technical considerations, they require understanding how the system will actually be used.

More Effective Testing

Developers who understand the domain write better tests because they know which edge cases matter. They can anticipate the unusual but important scenarios that cause real-world problems.

Testing booking logic is different when you know that guests frequently change arrival dates, that some campgrounds allow split stays across multiple sites, and that weather events often trigger cascading cancellations and rebookings.

Intuitive API Design

When developers understand the domain deeply, they design APIs that match how the domain actually works rather than imposing abstract technical structures.

Our API endpoints and data structures reflect campground operations—bookings, sites, activities, guests, rather than generic database operations. This makes the API more intuitive for anyone who understands camping but also ensures it supports the workflows that matter.

The Challenges of Building Domain Expertise

Creating a team of developer-camping-experts isn't without challenges and costs.

Time Investment

Sending developers to work at campgrounds for days takes them away from coding. Supporting customers takes time away from building features. The time investment is significant and ongoing.

We've decided this investment is worthwhile, but it does slow our development velocity in the short term. The tradeoff is that we build the right things and build them better, which we believe is more valuable than building faster.

Hiring Implications

Not every developer wants to spend time working at a campground. Some people got into software specifically to avoid customer-facing work or physical environments.

This has narrowed our hiring pool. We look for developers who are curious about the domain, comfortable with customer interaction, and open to experiences outside typical software development.

Maintaining Expertise as We Scale

As the team grows, maintaining consistent domain expertise becomes more challenging. We can't send every new hire to work at campgrounds indefinitely.

We're developing complementary approaches—better documentation of domain knowledge, recorded customer sessions, detailed case studies of common scenarios—but nothing fully replaces direct experience.

Balancing Depth and Breadth

There's a risk of developers becoming so focused on camping operations that they lose perspective on broader software engineering principles and emerging technologies.

We balance this by encouraging developers to stay connected with the broader tech community, attend general software conferences, and work on diverse technical challenges beyond just camping-specific features.

Unexpected Benefits

Building deep domain expertise has created benefits we didn't anticipate:

Better Customer Relationships

When developers talk to customers about features or problems, the conversations are fundamentally different. Customers sense that developers understand their business, which builds trust and leads to more productive discussions.

Campground operators are more willing to try experimental features or tolerate temporary rough edges when they trust that the development team understands their needs.

Improved Problem Diagnosis

When customers report bugs or confusing behavior, developers with domain expertise can often diagnose the real issue faster because they understand the context in which the problem occurred.

A report of "sites showing as available when they shouldn't" could stem from dozens of technical causes. A developer who understands campground operations can ask better diagnostic questions and identify the root cause more quickly.

Product Vision Clarity

Domain expertise helps the entire team maintain a shared vision of what we're building and why. Decisions about priorities and tradeoffs become easier when everyone understands how customers actually use the software.

This shared understanding reduces internal debates and helps us move more decisively.

Lessons for Other Technical Teams

The experience of building domain expertise into our development process offers lessons applicable beyond campground software:

Domain Expertise Can't Be Outsourced

You can't fully outsource domain understanding to product managers or customer success teams. Developers make dozens of decisions daily that benefit from domain knowledge, and waiting for specifications or approvals for every decision is impractical.

Firsthand Experience Beats Documentation

No amount of documentation, user stories, or requirements specifications can replace firsthand experience with the work your software supports. If you're building tools for teachers, spend time teaching. If you're building tools for healthcare, spend time in clinical settings.

Investment in Understanding Pays Long-Term Dividends

The time spent building domain expertise seems expensive in the short term but pays off through better decisions, fewer mistakes, and stronger customer relationships over time.

Domain Experts Make Better Technical Decisions

Technical decisions—architecture, data modeling, interface design—are often fundamentally domain decisions in disguise. Developers with domain expertise make these decisions more effectively.

The Ongoing Journey

Building domain expertise isn't a one-time project—it's an ongoing commitment. The camping industry evolves, customer needs change, and new team members join who need to build understanding.

We continue to iterate on how we build and maintain domain expertise. Some approaches work better than others. Some developers thrive with direct customer interaction while others prefer different learning methods.

What remains constant is the conviction that understanding camping operations deeply makes us better at building software for campgrounds. The code matters, but understanding what the code needs to do—and why—matters more.

Conclusion: Developers Who Understand

Alex, the developer who couldn't understand why we needed different site types, now occasionally gives talks at camping industry conferences about technology. He's become genuinely knowledgeable about campground operations, not just the software we build.

When he talks to potential customers, he doesn't lead with features or technical capabilities. He talks about understanding the challenges of managing a seasonal business, handling the complexity of different accommodation types, and building software that works with how campgrounds actually operate.

The transformation from developer to domain expert doesn't happen overnight. It requires deliberate investment, ongoing learning, and genuine curiosity about the industry you're serving.

But the result is software that works better, customers who trust you more, and a team that takes genuine pride in solving real problems for real people.

The best developers we've hired aren't necessarily the ones with the most impressive technical credentials. They're the ones who get excited about learning how campgrounds work, who ask thoughtful questions about operational challenges, and who care about building something truly useful rather than just technically interesting.

Building Camprs has taught us that domain expertise isn't separate from technical expertise, it's a crucial component of it. Understanding camping operations makes us better developers, just as understanding software development makes our customers better campground operators.

The goal isn't to turn developers into campground operators or vice versa. It's to build enough mutual understanding that we can work together effectively, combining deep technical knowledge with deep domain knowledge to create something neither group could build alone.

That's when software becomes truly valuable—when it's built by people who understand both the technology and the work it's meant to support.

How does your team build domain expertise? Whether you're building software for a specific industry or working in a domain that depends on technology, I'd love to hear how you bridge the knowledge gap between technical and domain expertise.

Weather API Integration: Building Reliable Outdoor Activity Management

Richard Sandown — Thu, 25 Sep 2025 00:48:47 +0000

At 3:47 AM on a Tuesday in July, our monitoring system detected severe thunderstorm warnings for the Colorado Rockies. Within minutes, Camprs automatically:

Cancelled 23 high-altitude hiking tours scheduled for that morning
Moved 8 whitewater rafting trips to a safer section of river
Sent SMS notifications to 156 affected guests with rebooking options
Alerted 12 activity guides about schedule changes
Updated availability calendars to prevent new dangerous bookings

All before the first lightning strike.

This wasn't magic—it was the culmination of 18 months building weather intelligence into outdoor activity management. Here's how we architected a system that keeps adventurers safe while keeping operators profitable, and the lessons we learned about integrating weather data at scale.

The Life-or-Death Stakes of Weather in Outdoor Recreation

Unlike restaurant reservations or hotel bookings, outdoor activity management carries genuine safety risks. A missed weather warning doesn't just mean disappointed customers—it can mean rescue operations, lawsuits, or worse.

The Challenge: Weather Data is Messy, Inconsistent, and Complex

Before diving into our architecture, it's crucial to understand why weather integration is particularly challenging for software developers.

Problem 1: API Inconsistency

Different weather services provide data in wildly different formats, update frequencies, and accuracy levels:

// OpenWeatherMap format
{
  "weather": [{"main": "Rain", "description": "light rain"}],
  "main": {"temp": 298.48, "humidity": 64},
  "wind": {"speed": 0.62, "deg": 349}
}

// WeatherAPI.com format  
{
  "current": {
    "condition": {"text": "Light rain"},
    "temp_f": 77.5,
    "humidity": 64,
    "wind_mph": 1.4,
    "wind_dir": "NNW"
  }
}

// National Weather Service format
{
  "properties": {
    "temperature": {"value": 25.82},
    "relativeHumidity": {"value": 64},
    "windSpeed": {"value": 1.02},
    "textDescription": "Light Rain"
  }
}

Problem 2: Temporal Complexity

Outdoor activities have different weather sensitivity windows:

Rock climbing: Needs 6-hour precipitation forecast
Multi-day backpacking: Requires 5-7 day detailed forecasts
Water activities: Depends on both current conditions and upstream weather
High-altitude activities: Elevation-specific microclimates matter

Problem 3: Geographic Precision

A campground might offer activities across a 50-mile radius with dramatically different weather conditions:

// Same timestamp, different locations 10 miles apart
const valleyWeather = { temp: 75, condition: "sunny", windSpeed: 5 };
const summitWeather = { temp: 42, condition: "snow", windSpeed: 25 };

Problem 4: Safety vs. Business Tension

Weather systems must balance competing priorities:

Safety: Cancel anything potentially dangerous
Revenue: Minimize unnecessary cancellations
Customer experience: Provide clear, timely communication
Staff efficiency: Automate routine decisions, escalate edge cases

Our Weather Integration Architecture

After evaluating 12 different weather APIs and building several prototypes, here's the architecture we settled on:

Multi-Provider Weather Aggregation

Rather than relying on a single weather service, we built a consensus system:

// weather-service/src/aggregator.js
class WeatherAggregator {
  constructor() {
    this.providers = [
      new OpenWeatherMapProvider(),
      new WeatherAPIProvider(), 
      new NationalWeatherServiceProvider(),
      new DarkSkyProvider() // RIP, but we still have legacy data
    ];
  }

  async getConsensusWeather(lat, lon, timestamp) {
    const promises = this.providers.map(provider => 
      provider.getForecast(lat, lon, timestamp).catch(err => null)
    );

    const results = await Promise.all(promises);
    const validResults = results.filter(r => r !== null);

    if (validResults.length < 2) {
      throw new Error('Insufficient weather data sources available');
    }

    return this.calculateConsensus(validResults);
  }

  calculateConsensus(forecasts) {
    // Weight different providers based on historical accuracy
    const weights = {
      'openweather': 0.3,
      'weatherapi': 0.25,  
      'nws': 0.35,
      'darksky': 0.1
    };

    return {
      temperature: this.weightedAverage(forecasts, 'temperature', weights),
      precipitation: this.maxValue(forecasts, 'precipitation'), // Conservative
      windSpeed: this.weightedAverage(forecasts, 'windSpeed', weights),
      conditions: this.mostCommonCondition(forecasts, weights)
    };
  }
}

Activity-Specific Weather Rules Engine

Different activities have different weather thresholds. We built a configurable rules engine:

// activity-rules/hiking.js
export const hikingRules = {
  name: 'High Altitude Hiking',
  riskFactors: [
    {
      condition: 'thunderstorm',
      action: 'CANCEL',
      reason: 'Lightning risk above treeline',
      leadTime: 2 // hours
    },
    {
      condition: 'windSpeed > 40', // mph
      elevation: '> 10000', // feet
      action: 'CANCEL',
      reason: 'Dangerous wind conditions at altitude'
    },
    {
      condition: 'temperature < 32 && precipitation > 0',
      action: 'MODIFY',
      modification: 'require_winter_gear',
      reason: 'Freezing precipitation expected'
    },
    {
      condition: 'visibility < 0.25', // miles
      action: 'CANCEL', 
      reason: 'Unsafe visibility conditions'
    }
  ],

  warningThresholds: [
    {
      condition: 'precipitation > 0.1 && precipitation < 0.5',
      action: 'WARN',
      message: 'Light rain expected. Waterproof gear recommended.'
    }
  ]
};

Real-Time Decision Making Pipeline

Our system processes weather updates every 10 minutes and makes decisions in near real-time:

// decision-engine/src/processor.js
class WeatherDecisionProcessor {
  async processWeatherUpdate(weatherData) {
    const affectedActivities = await this.findAffectedActivities(weatherData);

    for (const activity of affectedActivities) {
      const rules = await this.getActivityRules(activity.type);
      const decision = await this.evaluateRules(weatherData, rules, activity);

      switch (decision.action) {
        case 'CANCEL':
          await this.cancelActivity(activity, decision.reason);
          await this.notifyStakeholders(activity, decision);
          break;

        case 'MODIFY':
          await this.modifyActivity(activity, decision.modification);
          await this.notifyStakeholders(activity, decision);
          break;

        case 'WARN':
          await this.sendWeatherWarning(activity, decision.message);
          break;
      }

      await this.logDecision(activity, decision, weatherData);
    }
  }

  async findAffectedActivities(weatherData) {
    // Find all activities in the next 48 hours within affected geographic areas
    const timeWindow = {
      start: new Date(),
      end: new Date(Date.now() + 48 * 60 * 60 * 1000)
    };

    return Activity.findInTimeAndLocation(
      timeWindow,
      weatherData.affectedAreas
    );
  }
}

Geographic Weather Zones

We divided service areas into weather zones for more precise monitoring:

// geographic/zones.js
const coloradoZones = [
  {
    id: 'front_range_low',
    name: 'Front Range (5000-8000ft)',
    boundaries: {
      north: 40.5776,
      south: 39.7392,
      east: -104.8906,
      west: -105.2211
    },
    elevationRange: [5000, 8000],
    weatherStations: ['KDEN', 'KBDU', 'KGJT'],
    riskProfile: 'moderate'
  },
  {
    id: 'high_country',
    name: 'High Country (10000ft+)', 
    boundaries: {
      north: 40.0776,
      south: 39.0392,
      east: -105.8906,
      west: -106.8211
    },
    elevationRange: [10000, 14500],
    weatherStations: ['KASE', 'KVAIL'],
    riskProfile: 'extreme',
    specialConsiderations: [
      'Afternoon thunderstorms common June-August',
      'Rapid temperature changes',
      'Wind exposure significant above treeline'
    ]
  }
];

Handling Edge Cases: The Devil in the Details

Real-world weather integration reveals countless edge cases. Here are the trickiest ones we've encountered:

Edge Case 1: Conflicting Provider Data

// What do you do when providers disagree?
const weatherConflict = {
  openweather: { condition: 'sunny', precipitation: 0 },
  nws: { condition: 'thunderstorms', precipitation: 0.8 },
  weatherapi: { condition: 'partly_cloudy', precipitation: 0.1 }
};

// Our solution: Conservative bias with human escalation
if (this.hasHighVariance(forecasts)) {
  await this.escalateToHuman(activity, forecasts);
  return this.mostConservativeDecision(forecasts);
}

Edge Case 2: Rapid Weather Changes

Mountain weather can change in minutes. We built change-detection algorithms:

class WeatherChangeDetector {
  detectRapidChanges(currentForecast, previousForecast) {
    const changes = [];

    // Temperature change > 20°F in < 2 hours
    if (Math.abs(currentForecast.temp - previousForecast.temp) > 20) {
      changes.push({
        type: 'RAPID_TEMP_CHANGE',
        severity: 'HIGH',
        action: 'REVIEW_ACTIVITIES'
      });
    }

    // Precipitation probability jump > 50% 
    const precipChange = currentForecast.precipitationProbability - 
                        previousForecast.precipitationProbability;
    if (precipChange > 0.5) {
      changes.push({
        type: 'PRECIPITATION_SPIKE',
        severity: 'MEDIUM', 
        action: 'ISSUE_WARNINGS'
      });
    }

    return changes;
  }
}

Edge Case 3: API Rate Limiting and Failures

Weather APIs have strict rate limits. We built a sophisticated caching and fallback system:

class WeatherDataManager {
  constructor() {
    this.cache = new Redis();
    this.rateLimiter = new RateLimiter();
    this.circuitBreaker = new CircuitBreaker();
  }

  async getWeatherData(lat, lon, timestamp) {
    const cacheKey = `weather:${lat}:${lon}:${timestamp}`;

    // Try cache first (5 minute TTL for current, longer for forecasts)
    let cached = await this.cache.get(cacheKey);
    if (cached && !this.isStale(cached, timestamp)) {
      return JSON.parse(cached);
    }

    // Rate limiting check
    if (!await this.rateLimiter.canMakeRequest()) {
      if (cached) return JSON.parse(cached); // Return stale data
      throw new Error('Rate limited and no cached data available');
    }

    // Circuit breaker pattern for failed APIs
    try {
      const data = await this.circuitBreaker.execute(() => 
        this.fetchFromProvider(lat, lon, timestamp)
      );

      await this.cache.setex(cacheKey, this.getTTL(timestamp), JSON.stringify(data));
      return data;
    } catch (error) {
      if (cached) {
        console.warn('API failed, returning stale cached data', error);
        return JSON.parse(cached);
      }
      throw error;
    }
  }
}

Performance Optimization: Handling Scale

Processing weather data for thousands of activities creates performance challenges:

Batch Processing Strategy

Instead of individual API calls, we batch requests geographically:

class WeatherBatchProcessor {
  async processBatch(activities) {
    // Group activities by geographic proximity (5-mile radius)
    const geoClusters = this.clusterByLocation(activities, 5);

    // Batch API calls for each cluster
    const weatherPromises = geoClusters.map(cluster => 
      this.getWeatherForCluster(cluster)
    );

    const weatherResults = await Promise.all(weatherPromises);

    // Apply weather data to all activities in each cluster
    return this.distributeWeatherToActivities(geoClusters, weatherResults);
  }

  clusterByLocation(activities, radiusMiles) {
    // Implementation of geographic clustering algorithm
    // Groups activities within radiusMiles of each other
    return geoCluster(activities, radiusMiles);
  }
}

Database Optimization for Weather Queries

Weather data creates massive datasets. Our indexing strategy:

-- Composite index for geographic and temporal queries
CREATE INDEX idx_weather_location_time ON weather_data 
(latitude, longitude, forecast_time);

-- Partial index for active weather alerts only
CREATE INDEX idx_active_weather_alerts ON weather_alerts (location_id, alert_type) 
WHERE expires_at > NOW();

-- Materialized view for frequently accessed weather summaries
CREATE MATERIALIZED VIEW daily_weather_summary AS
SELECT 
  location_id,
  date_trunc('day', forecast_time) as forecast_date,
  avg(temperature) as avg_temp,
  max(precipitation_probability) as max_precip_prob,
  array_agg(DISTINCT condition) as conditions
FROM weather_data 
GROUP BY location_id, forecast_date;

-- Refresh strategy for materialized view
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_weather_summary;

The Human Element: When to Override Automation

Even sophisticated weather systems need human oversight. We built escalation triggers:

const humanEscalationTriggers = [
  {
    condition: 'High variance between weather providers (>30% disagreement)',
    escalateTo: 'weather_specialist',
    urgency: 'medium'
  },
  {
    condition: 'Extreme weather warning affecting >100 guests', 
    escalateTo: 'operations_manager',
    urgency: 'high'
  },
  {
    condition: 'First-time weather pattern for location',
    escalateTo: 'safety_coordinator', 
    urgency: 'low'
  },
  {
    condition: 'System confidence <70% on cancellation decision',
    escalateTo: 'activity_coordinator',
    urgency: 'medium'
  }
];

Testing Weather Systems: Simulating Nature's Chaos

Testing weather-dependent systems requires creative approaches:

Historical Weather Replay

// Test system against historical weather events
class WeatherReplayTester {
  async testHistoricalEvent(eventId, activities) {
    const historicalWeather = await this.getHistoricalWeatherData(eventId);
    const testActivities = this.createTestActivities(activities);

    // Replay the weather event minute by minute
    for (const weatherSnapshot of historicalWeather) {
      await this.processWeatherUpdate(weatherSnapshot);
      await this.assertCorrectDecisions(weatherSnapshot, testActivities);
    }
  }

  // Test against known severe weather events
  async testSevereWeatherScenarios() {
    const scenarios = [
      'Hurricane Sandy 2012',
      'Colorado Floods 2013', 
      'Derecho Iowa 2020',
      'Texas Freeze 2021'
    ];

    for (const scenario of scenarios) {
      await this.testHistoricalEvent(scenario, this.getTestActivities());
    }
  }
}

Chaos Engineering for Weather APIs

class WeatherChaosTest {
  async runChaosScenarios() {
    // Simulate partial provider failures
    await this.simulateProviderFailures([
      { provider: 'openweather', failureRate: 0.3, duration: '2h' },
      { provider: 'weatherapi', failureRate: 0.8, duration: '30m' }
    ]);

    // Inject rate limiting
    await this.simulateRateLimiting('nws', { requestsPerHour: 50 });

    // Test with corrupt weather data
    await this.injectCorruptData({
      temperature: 'not_a_number',
      precipitation: -5, // Impossible value
      windSpeed: null
    });
  }
}

Customer Communication: The User Experience of Weather

Weather decisions mean nothing without clear communication:

Multi-Channel Notification System

class WeatherNotificationService {
  async notifyWeatherDecision(activity, decision) {
    const notification = this.buildNotification(activity, decision);

    // Send via multiple channels based on urgency
    if (decision.urgency === 'HIGH') {
      await Promise.all([
        this.sendSMS(activity.guests, notification.sms),
        this.sendEmail(activity.guests, notification.email),
        this.sendPushNotification(activity.guests, notification.push),
        this.callActivityGuides(activity.guides, notification.voice)
      ]);
    } else {
      await this.sendEmail(activity.guests, notification.email);
      await this.updateBookingPortal(activity, notification.portal);
    }
  }

  buildNotification(activity, decision) {
    return {
      sms: this.buildSMSMessage(activity, decision),
      email: this.buildEmailMessage(activity, decision),
      push: this.buildPushMessage(activity, decision),
      voice: this.buildVoiceScript(activity, decision),
      portal: this.buildPortalUpdate(activity, decision)
    };
  }
}

Weather-Aware Rebooking

When activities are cancelled, our system automatically suggests alternatives:

async findRebookingOptions(cancelledActivity, reason) {
  const alternatives = [];

  // Same activity, different time/location
  const timeAlternatives = await this.findSafeTimeSlots(
    cancelledActivity.type,
    cancelledActivity.date,
    72 // hours window
  );

  // Different activities, same time
  const activityAlternatives = await this.findIndoorAlternatives(
    cancelledActivity.date,
    cancelledActivity.duration
  );

  // Weather-specific suggestions
  if (reason.includes('rain')) {
    alternatives.push(...await this.findCoveredActivities());
  }

  if (reason.includes('wind')) {
    alternatives.push(...await this.findWindProtectedActivities());
  }

  return this.rankAlternativesByPreference(alternatives, cancelledActivity.guests);
}

Lessons Learned: What We'd Do Differently

After 18 months of weather integration, here's what surprised us:

1. Weather Accuracy Varies Dramatically by Region

Mountain weather is genuinely harder to predict than plains weather. Our Colorado accuracy rates are 15-20% lower than our Texas rates, even using the same providers and algorithms.

Solution: Region-specific confidence thresholds and escalation rules.

2. Customers Prefer Conservative Cancellations

We initially tried to minimize cancellations to maximize revenue. Customer feedback revealed they'd rather have a cancelled hiking trip than a miserable, potentially dangerous experience.

Result: We shifted toward more conservative decision-making and saw customer satisfaction scores increase.

3. Staff Training is Critical

The best weather system is worthless if staff don't understand when to override it or how to explain decisions to guests.

Solution: Monthly weather training sessions and decision-tree flowcharts for staff.

4. Historical Data is Gold

Our most valuable feature turned out to be showing guests historical weather patterns: "September in Colorado averages 2 afternoon thunderstorms per week, typically lasting 45 minutes."

Future Evolution: Where Weather Integration is Heading

Hyperlocal Weather Monitoring

Integrating IoT weather stations at activity locations for real-time, precise conditions:

// Integration with on-site weather stations
class HyperlocalWeatherIntegration {
  async getLocationSpecificWeather(activityLocation) {
    const nearbyStations = await this.findNearbyStations(activityLocation, 2); // 2 mile radius
    const stationData = await Promise.all(
      nearbyStations.map(station => station.getCurrentConditions())
    );

    // Blend station data with API forecasts
    return this.blendLocalAndForecastData(stationData, activityLocation);
  }
}

Machine Learning for Activity-Specific Predictions

Using historical activity outcomes to improve weather decision accuracy:

// ML model for predicting activity success based on weather
class ActivityWeatherMLPredictor {
  async trainModel(historicalData) {
    // Features: weather conditions, activity type, guest demographics, time of year
    // Target: activity completion rate, guest satisfaction, safety incidents

    const model = await this.buildTensorFlowModel(historicalData);
    return model;
  }

  async predictActivityOutcome(weatherConditions, activity) {
    const features = this.extractFeatures(weatherConditions, activity);
    const prediction = await this.model.predict(features);

    return {
      completionProbability: prediction.completion,
      satisfactionScore: prediction.satisfaction, 
      riskLevel: prediction.risk
    };
  }
}

Conclusion: Weather as a Competitive Advantage

Building reliable weather integration for outdoor activities taught us that weather data isn't just about safety—it's about creating superior customer experiences and operational efficiency.

Campgrounds and activity providers using weather-aware systems see:

reduction in weather-related cancellations through better timing
improvement in customer satisfaction with weather communication
increase in rebooking rates when cancellations are necessary
reduction in weather-related safety incidents

The key insight: weather integration isn't about perfect prediction—it's about better decision-making with imperfect information.

For developers building outdoor recreation software, weather integration is complex but essential. The techniques we've shared—multi-provider aggregation, activity-specific rules engines, geographic zones, and human escalation—provide a foundation for weather-aware systems.

The outdoors will always be unpredictable. Our job is to help people engage with that unpredictability safely and joyfully.