TowerSight: Turning a Legacy Tool into a Self-Serve SaaS Platform in Under 2 Months

Executive Summary

Ridgeline Engineering manages physical telecom infrastructure - the towers, shelters, cabinets, generators, fuel tanks, and power systems that live on hundreds of individual sites. Their existing web app was aging: functional in a narrow way, but hard to extend, not built to scale, and not something customers could ever operate on their own.

TowerSight is the replacement - a ground-up rebuild reframed around the one concept that actually mattered: the Site. In the new platform, a Site is the physical location, and everything else - one or more towers plus every other asset on the property - hangs off of it. On top of that model sits a full multi-tenant SaaS: organizations sign up, invite their own team, and manage their own infrastructure on their own terms, with role-based access control, audit logging, mapping, and one-click PDF/Excel reporting.

The entire effort - discovery, architecture, build, QA, and full data migration from the legacy system - reached production in under two months, delivered end to end by a single developer who also owned the scalability and security strategy.

<!-- Testimonial approved by Joel Deis (Ridgeline Engineering), 2026-07-15. -->

"Our old system did the job but it had hit a wall - we couldn't grow it, and we couldn't hand it to customers. Travis took the whole thing on himself, reframed it around how we actually think about our sites, and had a modern, self-service platform live in under two months with all of our data moved over. It's the difference between a tool we maintained and a product our clients can run themselves."

- Joel Deis, Owner, Ridgeline Engineering

The Challenge

The legacy rdgline.com application had served its purpose, but it carried the classic symptoms of a tool that outgrew its original design:

• Dated and hard to extend. Adding capability meant fighting the existing structure rather than building on it. Every new requirement increased the maintenance burden instead of reducing it.
• Not built to scale. The architecture assumed a small, fixed usage pattern. There was no clean path from "internal tool" to "product multiple organizations can use independently."
• No self-service. Customers couldn't sign up, manage their own users, or maintain their own data. Every change flowed back through Ridgeline, turning the team into a bottleneck.
• A weak core model. The data didn't revolve around the concept the business actually operates on - the Site. Towers and equipment existed, but the physical location that ties them together wasn't the organizing principle, which made the whole system harder to reason about and report on.

The mandate was not "patch the old app." It was: rebuild it as a real product - one Ridgeline could grow, secure, and put directly in customers' hands.

The Approach

1. Reframe everything around the Site

The single most important design decision was making the Site the core entity of the system. A Site is a physical property with a precise location (latitude/longitude, street address, even a stored 3D view reference). Every other asset is modeled as something that lives on a Site:

• Towers - one or more per site, each carrying its own equipment, feedlines, and equipment files
• Shelters, outdoor cabinets, and fences
• Generators and fuel tanks
• Grounding, site power, and data providers
• Documents and photos attached directly to the site record

This mirrors how the business actually thinks: you go to a place, and you manage everything at that place. Structuring the data this way made navigation intuitive, reporting straightforward, and the entire domain easier to extend - new asset types simply attach to the Site.

A Site record in TowerSight: one physical location, its exact coordinates, and every asset that lives on it - towers, buildings, generators, fuel tanks, documents, and photos - rolled up into a single view.

2. Build it as a true multi-tenant SaaS

To move from "internal tool" to "self-serve product," the platform was architected around Organizations as tenants. Each organization owns its own sites, users, and data, fully isolated from every other tenant. New customers can onboard themselves, invite their own team members, and administer their own accounts - no involvement from Ridgeline required.

This is the difference between shipping a single-tenant application and shipping a platform. Every record is scoped to an organization, and access is enforced at the data layer, not just the UI.

The Sites dashboard, scoped to the Ridgeline organization (see the tenant banner up top). Each tenant sees only its own sites, plotted on an interactive Leaflet / OpenStreetMap view.

3. Lock down access with 5-tier RBAC

Infrastructure data is sensitive, and different users need very different levels of access. TowerSight implements a five-level role system:

Every meaningful action is permission-gated, and sensitive events - including role changes - are written to an immutable audit trail.

4. Migrate the real data, not a demo

A rebuild is only useful if it goes live with the actual business data. The project included a complete data migration from the legacy system into the new Site-centric model - part of the under-two-months timeline, not an afterthought. Production launch meant real sites, real assets, and real history, ready to use on day one.

Technical Deep Dive

Architecture

┌──────────────────────────────────────────────────────────┐
│                      User Interface                       │
│      Next.js 15 (App Router) / React 19 / Tailwind CSS    │
│         Tablet-first, optimized for outdoor field use     │
├──────────────────────────────────────────────────────────┤
│                        API Layer                          │
│        Next.js API Routes  •  Zod validation on input     │
├───────────────────────────┬──────────────────────────────┤
│      Auth & Access         │        Business Logic        │
│  NextAuth.js  •  5-tier    │   Multi-tenant scoping       │
│  RBAC  •  bcrypt hashing   │   Audit logging  •  Reports  │
├───────────────────────────┴──────────────────────────────┤
│                        Data Layer                         │
│              Prisma ORM  •  PostgreSQL                     │
├──────────────────────────────────────────────────────────┤
│                     Services & Infra                      │
│        Cloudflare R2 • Resend • Docker • Railway         │
│         Leaflet + OpenStreetMap (interactive maps)        │
└──────────────────────────────────────────────────────────┘

The stack, and why

Security by design

Security wasn't a phase at the end - it was part of the architecture:

• Role-based authorization enforced across the application, backed by the five-tier UserRole model
• Input validation with Zod schemas on API routes
• Password hashing with bcrypt
• Audit logging of sensitive actions (including role changes) via a dedicated audit trail
• Session and login monitoring, including tracking of session activity and failed login attempts
• Tenant isolation, so one organization can never reach another's data

Domain depth in practice: adding a tower captures engineering-grade detail - height, type, loading percentage, structural analysis and inspection dates - all tied back to its parent Site.

Quality gates

The project shipped with an automated test foundation - Jest for unit/component coverage and Playwright for end-to-end browser testing - so QA wasn't a manual afterthought but a repeatable safety net that traveled with the codebase.

Results & Impact

The headline outcome: Ridgeline went from maintaining a tool to owning a product - one their customers can operate independently, and one built to grow rather than to be replaced again in a few years.

Lessons Learned

1. Get the core entity right and everything downstream gets easier.
Choosing the Site as the aggregate root wasn't a cosmetic choice - it shaped the data model, the navigation, the permissions, and the reports. When the central concept matches how the business actually thinks, complexity drops across the entire system.

2. Multi-tenancy is a decision to make on day one, not a feature to bolt on.
Tenant isolation touches the schema, the queries, and every authorization check. Designing for Organization from the first migration is what made self-serve possible without a painful rewrite later.

3. Migration is part of "done."
A rebuild that can't ingest the real data isn't finished - it's a demo. Treating full data migration as a first-class deliverable inside the timeline is what allowed a genuine production cutover in under two months.

4. A single owner can move fast without cutting corners - if the process is disciplined.
Solo delivery meant no coordination overhead, but it only works with real engineering discipline: type safety, input validation, automated tests, audit logging, and security baked in from the start rather than patched in at the end.

Frequently Asked Questions

Q: What is TowerSight?

A: TowerSight is a multi-tenant SaaS platform for managing physical telecom infrastructure. It organizes everything around the Site - a physical location - and tracks the towers, shelters, cabinets, generators, fuel tanks, power systems, and other assets that live on it. Organizations sign up, manage their own users and data, map their sites, and generate PDF/Excel reports.

Q: Why rebuild the legacy app instead of upgrading it?

A: The legacy application was hard to extend, wasn't built to scale, and couldn't be offered to customers as a self-service product. Its data also didn't revolve around the Site, which is the concept the business actually operates on. A focused rebuild on a modern, Site-centric, multi-tenant architecture was faster to a durable result than repeatedly patching a design that had hit its limits.

Q: How was a full rebuild and data migration completed in under two months?

A: Disciplined scope and end-to-end ownership. A single developer handled discovery, architecture, build, QA, and migration without coordination overhead, while relying on a modern stack (Next.js, TypeScript, Prisma, PostgreSQL) and an automated test suite to move quickly without sacrificing quality. Data migration was treated as part of the deliverable, not a separate project, so launch meant real data on day one.

Q: What makes TowerSight a true SaaS platform rather than just a web app?

A: Multi-tenancy. Each organization is an isolated tenant that owns its own sites, users, and data, with self-serve signup and team invitations. Combined with five-tier role-based access control and per-tenant data isolation, that's what separates a product customers can run themselves from an internal tool.

Q: How is sensitive infrastructure data kept secure?

A: Security is built into the architecture: five-tier role-based access control, tenant isolation enforced at the data layer, Zod input validation, bcrypt password hashing, session and failed-login monitoring, and an immutable audit trail that records sensitive actions such as role changes.

Q: What technology is TowerSight built on?

A: Next.js 15 and React 19 with TypeScript on the front end and in the API layer, PostgreSQL with the Prisma ORM for data, NextAuth.js for authentication, Leaflet with OpenStreetMap for mapping, Cloudflare R2 for media, Resend for email, and jsPDF/xlsx for reporting - deployed with Docker on Railway and covered by Jest and Playwright test suites.

Q: Can this approach work for other operations-heavy businesses?

A: Yes. Any business that manages many physical or logical assets tied to a central entity - locations, properties, equipment, accounts - can benefit from the same pattern: identify the true core entity, model everything around it, and build multi-tenant, role-secured, self-serve access on top.

Have a Legacy Tool That Needs to Become a Product?

TowerSight is proof that an aging internal application can become a modern, secure, self-serve SaaS platform - designed, built, migrated, and shipped end to end, fast.

Start a conversation about your project →

This case study documents the design and development of TowerSight for Ridgeline Engineering. For questions or to discuss a similar rebuild, contact Travis Sutphin.