A multi-tenant SaaS platform, through the dot-com arc

The arc in five phases

1. Early days, 1999
2. The funded period, 2000
3. The first down period, 2001
4. The second down period, the fight for survival, ~2001 to 2003
5. Growing organically, and the exit, 2004 to 2006

Funding timeline from the public record

• Founded 1999 in California; HQ relocated to Oregon in 2004.
• The Series A in Nov 1999 brought seed backing from Arba Seed Investment Group, Western Investments Capital, and Marcus & Millichap.
• The Series B in May 2000 raised $17.5M, led by Arba Seed Investment Group, Amicus Capital, and Asset Management Company.
• The 2001 to 2004 rounds brought continued support from Sycamore Ventures, Sierra Ventures, and Amicus Capital, including a $6.7M round in Oct 2003.
• After my time: a $10M round in June 2007, roughly $44M to $47M in total venture capital, and the JLL acquisition in Dec 2015.
• Customers and partnerships: Sprint, Salesforce, Intuit; 300+ firms including FEMA support services, airport wheelchair dispatch, and multi-tenant residential, commercial, and new-home building management.

Phase 1: early days, 1999

To understand CorrigoNet you have to start with who built it. The founder, Rick Michaux, came out of Motorola, where he led the team behind early on-device app development, including T9 predictive messaging. The premise: give the service technicians who maintain REIT properties real mobile capability. On-device apps and T9 messaging would route a tech to a property, let them process service requests, order parts, and more.

The team reflected that mobile DNA: heavily Russian- and Ukrainian-born mobile developers, a handful of whom had moved into web app work. They had also brought in a Microsoft administrator from Deutsche Bank who built the initial architecture. Corrigo hired me as a developer.

The stack, as best I recall: a web front end in classic ASP and VBScript with dynamic JavaScript and XML data islands, business logic in COM components hosted in COM+ processes, and SQL Server behind it. That classic-ASP stack carried most of the run. Around 2002 to 2003, as C# and the maturing .NET framework arrived, the codebase moved onto C#/.NET.

Corrigo recruited me for one specific piece. Alex Feinman was working with a Dialogic telephony card and its C++ drivers under Windows, with the goal that a REIT tenant could call an 800 number, hear information about their work orders, and ask to be connected to a service agent. My job was to build the Java application the service agents used to add themselves to the available queue a call would be cross-connected to. The job also covered linking that app to the web front end. It launched from the browser, so the agent could see the tenant’s work orders, open a new one, and so on. It was a brief, very happy time. I was helping on the C++ and coding across Java, classic ASP in VBScript, dynamic JavaScript front ends, VB6 COM components, and SQL Server, all at once.

The company had a serious problem hiding in plain sight, an architecture that could not scale. The initial architecture was built on very expensive HP/Compaq clusters, two massive nodes with fiber-channel connections to a shared disk enclosure, roughly $450K each. And the application was designed so that every new customer needed their own cluster, running Microsoft Cluster Services with the web app and SQL together on the active node and the second node idle as failover. Great uptime, but it meant the company had to chase roughly $1M three-year contracts just to make a single deal pencil out.

To understand the business, I read the business plan. I had friends at eBay who were scaling their systems and had shared how they did it, so I spoke up and told the CTO, David Rainton, that the architecture was an ill fit for the business plan. He asked me to write it up. I did, factoring in that this was a Microsoft shop rather than the Java/Sun, BEA, or IBM/Oracle stacks that were the common path to scale at the time. I kept drifting into the “what and the why”; David told me to just give him the “what,” so I did. He liked it and asked me to present it to the whole engineering team. That became about 60 to 90 minutes of me presenting a new architecture, followed by roughly two and a half hours defending it, collegially but intensely, to a room of fired-up Russian and Ukrainian developers.

Phase 2: the funded period, 2000

The presentation held up. After the hour-plus of presenting and the long, collegial defense, Corrigo adopted the new architecture, I became the system architect and in practice the administrator too, and the company brought me on full-time. More to the point, the redesign is what made the next round of fundraising possible, the $17.5M Series B in May 2000. Here is what it actually was.

The web tier went stateless and load-balanced. Windows servers were less reliable then than they would later become, so instead of betting a customer’s uptime on one big box, the web application moved to a pool of low-cost servers behind a load balancer. Lose one and the rest carry on.

True multi-tenancy ran through a registry. Each customer got a dedicated database and a DNS entry. The only database a web server held a direct connection key for was a small registry that mapped each customer’s URL to that customer’s database DSN. A request came in, the web tier looked up the tenant in the registry, and from then on used the session-stored DSN for that customer’s queries. The upshot was that any web server could serve any number of customers in parallel. One pool, many tenants.

Releases promoted in place across three environments. I ran nine servers in three groups of three. Each group ran a version of the app: QA held the newest release under test, staging held the version going live next, and production ran the live app. The clever part was the rotation. At a release, the current staging environment became the new production. We upgraded the customer databases and pointed their DNS entries at the new group, with no redeploy to the servers. Once every production customer had moved over, the old QA group became staging, and the freed-up old production became the new QA. So the exact hosts and build you QA’d on became staging, and the staging environment customers had been beta-testing became production. The environment rotated forward on itself.

Next came database versioning, handled as code. I created and promoted a model for managing every customer database. The rules were simple even where the implementation was not. A database holds two kinds of objects. Non-data objects are views, stored procedures, and so on; data objects are tables, and tables are either persistence or lookup. Any change to a table went into a numbered script, and each database tracked which scripts it had already run in a table of its own. An upgrade followed a fixed sequence: back up the database, drop all the non-data objects, create any new tables, run the conversion scripts that database had not yet run, repopulate the lookup tables, then rebuild the indexes, relationships, views, and stored procedures. A version release therefore held the web and COM+ middleware files plus a complete, scripted snapshot of the database structure, the lookup data, and the ordered table-change scripts.

The payoffs followed from that order. Because upgrades were ordered and repeatable, any customer could move from their current version to any later one, even skipping releases. I also wrote a tool that anonymized a database, stripping emails and the like. That let us clone a customer’s database, anonymize the copy, upgrade it, and attach it to staging to give that customer a live preview of upcoming features on their own data. Upgrades could run on each customer’s own schedule. And we could now remodel the most expensive thing in the old world, the per-customer cluster, into a single active-active cluster that split the load and eliminated the idle failover node entirely.

The net effect was that the platform could scale without adding hardware, sell to a customer of any size, give customers some control over their upgrade path and a real preview of what was coming, and still deliver resiliency and high-quality, staged validation. As the architect and the administrator, I built the tooling that made it run: the database-version package emission and verification, the server build-out, and the load-balancer, firewall, and DNS practices. That is what opened the door to the next phase of fundraising.

Then came the promotion, and a go-live I will never forget. In 1999, ahead of the production go-live, Corrigo made me Director of Technology Operations and gave me the budget to hire. Around the same stretch it brought in Nicholas Menaker as CTO, and I moved under him. I brought on two or three people, mainly to manage the servers and run the build, deploy, and upgrade pipeline I had designed.

The first production go-live on the new architecture carried the whole company. The date was immutable, and the $17.5M round was contingent on it. I coached the team and the org through the production cutover. On Sunday, Corrigo reached a stable, launch-ready state. The funding followed. It is the cleanest illustration I have of what that era felt like.

Phase 3: the first down period, 2001

With the round closed, Corrigo hired like mad. Sales expanded under David Popler, product management stood up under Greg Roufa, and we brought on advisors, QA, more engineers, and my own ops team. This was peak dot-com Silicon Valley. Everyone was getting funded, hiring was insane, and the operating mindset was pure “if you build it, they will come.” Corrigo hired whoever it could.

On the infrastructure side I kept scaling us out. We took on a lease with HP/Compaq, I built a new production environment while keeping the old group as QA in our own building, and we moved into Globix as our datacenter. Sales and staffing kept climbing.

Then the burn caught up with us and pushed Corrigo toward another raise, right as two things went wrong. VCs started tightening their belts as the market turned, and the process itself turned ugly: one firm ran deep due diligence on us and then funded a competitor instead. Funding went from hard to nearly impossible, even as we kept adding customers and growing revenue.

There was an irony in it. The competitor was cash-rich but thin on product and customers; we were the opposite, revenue- and customer-rich but short on cash, and they came around to explore a merger. It did not come together. With revenue growth no longer enough to outrun the burn and venture money all but gone, Corrigo moved into layoffs, kept trying to raise and sell without much success, and cut again.

Somewhere in that stretch the Code Red worm hit, and it taught me the management lesson that stuck. I had built a server-hardening practice, documented it, and trained my team on it: I hardened the first server, my staff did the next while I reviewed and confirmed, and I told them to roll it across the whole fleet, both our locally hosted environment and production. They finished the local side but not production, and on the day Code Red tore through the internet, that gap bit us. I grabbed a staffer, drove to our Santa Clara datacenter, dropped the network to cut off internet access, and went server to server cleaning the infection and hardening each host by hand. We were back online, clean, within about two hours of the infection starting, while much of the internet was still drowning in the traffic. The lesson has never left me: delegating a control is not the same as confirming it landed. It is the lived origin of a rule I still say out loud, that a control nobody tests is a belief. From then on I verified completion, not just assignment.

Phase 4: the second down period, the fight for survival, ~2001 to 2003

By the down years Corrigo was out of money, trying to resist further layoffs. It was dire, and survival meant getting creative. So I hatched a plan and ran it.

It started with a favor economy. A former Globix staffer had moved over to the 200 Paul datacenter in San Francisco, so I brokered an introduction between him and my friends at eBay, and in exchange eBay gave us one rack in their datacenter for three years at no cost. I moved our local QA stack onto it, our pre-lease gear of custom-built servers, an HP cluster, and the firewall and load-balancer networking, and brought it online. Then I migrated our customers over to that rack and the legacy equipment, which freed up everything sitting at Globix.

Next came the hard part. I drove to Globix and removed our gear. I borrowed a second rack at 200 Paul, rebuilt the full production environment on the HP gear there, and moved the customers back onto it. My old friend Alex Feinman and I spent part of that stretch at 200 Paul making ethernet cables by hand. Once the customers were back on the HP production gear, I pulled the legacy gear back to HQ and freed up that rack too. Then we negotiated a buyout of the HP lease so we could keep the hardware outright. That bought Corrigo real breathing room.

It was not enough on its own. We kept shrinking, from more than 150 people down to roughly 12. And then a ray of hope: in December, Corrigo closed a deal with a firm in Indiana, with one catch. They wanted to self-host. So I built a CLI, menu-driven system for deploy and update and a way to package and share upgrades, essentially an on-premises distribution of the platform. In a cold January, likely 2002, I flew out, worked with their IT to stand CorrigoNet up on their own systems, and then walked the customer through review and sign-off that we had delivered, which triggered a check for $453K and change.

I put that check in my wallet, flew back to California late on a Friday, and the next morning drove to a Silicon Valley Bank office to meet a man who had come in just to meet me. I handed him the check. That is what kept Corrigo out of bankruptcy and able to make payroll.

In that same survival stretch, Corrigo took on running the call center for several of its customers. We didn’t actually have a call center, so we became one. All staff rotated through shifts acting as agents, taking customer calls and filing work orders, managed through a round-robin FIFO queue. To make the duty more bearable, I built a small pop-up tool: you set the phone number a call should transfer to, and it tracked where you sat in the agent queue. When you were next up and a call came in, it played an audio alert of your choosing. It was an early-warning system. You could be heads-down on your real work and still get a heads-up the instant a call was about to land on you. People were grateful for it, and Tad Neeley, now an investor, was among them. A tiny piece of software, but a lasting lesson: a little engineering empathy for your own team goes a long way.

Phase 5: growing organically, and the exit, 2004 to 2006

The recovery was revenue-led: steady, customer-driven growth rather than another sugar-high raise. Corrigo expanded and stood up a new office in Wilsonville, Oregon, and we moved off the survival-era hardware onto modern equipment. For me this phase was a run of great learning-by-doing on the infrastructure side: moving into the 365 Main datacenter, getting our own IP block, setting up BGP peering, VPN, VoIP, and more. I did most of it myself, with the occasional help of Andre Gironda, one of my best friends, who had come out of eBay.

By 2002 and 2003 the business was back to steady, sales- and product-led growth, with some staff growth, and my scope widened: I took over IT as well, so I now owned the Exchange servers, Active Directory, and the rest of the internal stack on top of production operations. Another funding round came in, and with it the expansion and the new office in Wilsonville, Oregon.

Two datacenter chapters defined the infrastructure work. First, 200 Paul had a rough run. A cooling system on a lower floor blew a gasket and dumped tens of thousands of gallons of coolant. The building was a converted department-store warehouse with porous concrete, so the flood drained down through the floors and took the power with it. We stayed online because half our floor still had power, so I kept us up by running an extension cord. Scrappy, but it worked.

Then came the planned move to 365 Main in downtown San Francisco, and the networking build-out that was, honestly, the most fun of the whole run. At 365 Main we got live feeds straight from the ISPs. On Andre’s advice we went all in on Cisco and acquired a modular Catalyst chassis with redundant supervisors, used as our switch, firewall, and load balancer in one. A site-to-site VPN tied together the Mountain View and Wilsonville offices. We reorganized Exchange so the primary lived in San Francisco with a local edge in each office, and deployed QoS that worked better than expected once we gave the admin network top priority. I acquired our own /24 IP block and an ASN and set up our own BGP peering, became expert on Cisco gear, and rolled Cisco VoIP telephony out to every office. The actual move to San Francisco happened over a single weekend.

All of that ran on very few hands: one IT manager in Wilsonville, Kathryn Leuenberger, and my admin and network partner Andre Gironda. He comes back later in the story. Managing a manager was new and rewarding. Kathryn turned out to be very clever, and when we could not afford more headcount she set up an internship pipeline with a local technical college. For stretches it was mostly just the two of us, and eventually I picked up a staffer who had been hired as a coder but was underperforming.

The site visits and customer troubleshooting produced the best war stories. One customer wanted a private link from outside our firewall into their environment, mis-configured their peering, and ended up trying to route their entire company’s internet traffic over that single T1 to us. On a visit to a customer headquarters to chase performance complaints, I found strange traffic on a flat 10 Mbps network with a full /16 and diagnosed an active malware infection on their own network. Another time a customer was convinced our application was slow; I put a packet sniffer on our datacenter switch, saw heavy retransmissions, and told them their own internet link was saturated. They investigated, traced it to one senior employee’s heavy non-work browsing, addressed it, and their performance recovered. One small aside on how early I started. My Network Solutions handle was PV300, issued when the registry was tiny.

The exit came in 2006. The 2003 raise did its job. From 2003 through 2005 Corrigo grew on that money, sales- and product-led, and for a while it felt like the company had finally found solid ground. But around 2005 there was another layoff, and the familiar pattern started to show through again, the sense that the company was tightening and heading into another wind-down rather than climbing. By 2006 I had been there seven years, had built and rebuilt the infrastructure through two downturns, and I looked at where I sat and did not see a meaningful path forward, no real room left to grow or to be promoted into something bigger. I was not excited to ride another contraction. So in 2006 I left, and, as I tend to do, I quit with nothing lined up. It was the right call even without a safety net. I had gotten everything I was going to get out of that chapter, and I was ready for the next problem.

People

• Rick Michaux, founder; ex-Motorola, where he led early on-device app development including T9.
• David Rainton, CTO; asked for and championed the re-architecture write-up and presentation.
• Alex Feinman, developer on the Dialogic telephony integration, with C++ drivers under Windows; later made ethernet cables by hand with me during the 200 Paul rebuild.
• Kathryn Leuenberger, IT manager in Wilsonville; very sharp, built an internship pipeline with a local technical college when we couldn’t afford headcount. linkedin.com/in/kathrynl
• Andre Gironda, admin and network partner, ex-eBay; one of my best friends; advised the all-Cisco 365 Main build-out.
• Nicholas Menaker, CTO after David Rainton. I reported to him for the rest of my time at Corrigo.
• David Popler, led sales expansion.
• Greg Roufa, stood up product management.

Tech & craft

Stateless web applications; redundant, load-balanced Microsoft IIS/SQL and Netscape/Java/Oracle; integrated and automated build and release management. Signature pieces I designed and built: a tenant-registry multi-tenant architecture mapping URL to database DSN; a self-rotating QA/staging/production environment-promotion pipeline across nine servers; scripted, repeatable database versioning with per-database run tracking; a database anonymizer for safe previews; and a move from per-customer failover clusters to a shared active-active cluster. Reported outcomes from the era: 99.95%+ service delivery and greater than 90% hosting profitability.

Throughline

Corrigo is where I learned to read a business before touching its architecture, and then to build systems that fit the business rather than the other way around. I walked in as a developer, read the business plan, and saw that the elegant, expensive per-customer cluster model could never match the SaaS economics the company was actually selling against. So I designed the multi-tenant, self-rotating, scripted-and-versioned platform that let Corrigo sell to a customer of any size, and that re-architecture is what made the $17.5M round possible. Then I got to operate it through the full dot-com arc: funding and a hiring frenzy, two downturns, a genuine fight for survival where I physically moved the company’s hardware across datacenters and carried a $453K check to the bank to keep payroll alive, and finally organic growth to profitability with a BGP-peered, Cisco-everything datacenter I mostly built by hand. The rule that came out of it, that a control nobody tests is a belief, still governs how I run engineering and security. Seven years took me from contract coder to Director of Technology Operations, and taught me that the most valuable thing an engineer can do is understand why the business needs what it needs, and then make the infrastructure quietly, relentlessly deliver it.

Funding sources: pitchbook.com/profiles/company/13229-74; seedtable.com/exits/corrigo-a-jll-company; oregonlive.com, for the 2007 round; dealroom.co/companies/corrigo.