# Sigmund Says...
> Nearly 3 decades of building software and systems. Over 1,000 customers served. Over 600 projects completed. These are my stories. In the Denver/Northern Colorado area? Let's work together.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### Find Me
URL: https://www.sigmundsays.software/find-me/
Last updated: 2026-01-28T18:04:19.000Z
Here are the places you can find me and my work. Wherever you are, I'd love to connect, and I'd love even more to talk about software with you. 

### LinkedIn

[https://www.linkedin.com/in/patrickmquinn/](https://www.linkedin.com/in/patrickmquinn/?ref=sigmundsays.software)

### X (formerly Twitter)

[https://x.com/IamSigmund](https://x.com/IamSigmund?ref=sigmundsays.software)

### Reddit

[https://www.reddit.com/user/i-am-sigmund/](https://www.reddit.com/user/i-am-sigmund/?ref=sigmundsays.software)

### CloudSee Drive

The SaaS product I'm currently building with my team @ Webapper.  
[https://www.cloudseedrive.com/](https://www.cloudseedrive.com/?ref=sigmundsays.software)

Or, if you'd like to dive right in and starting using CloudSee.  
[https://drive.cloudsee.cloud/](https://drive.cloudsee.cloud/?ref=sigmundsays.software)

### Webapper Services

My small but mighty little software company, founded in 2001.  
[https://www.webapper.com/](https://www.webapper.com/?ref=sigmundsays.software)
### My Name
URL: https://www.sigmundsays.software/my-name/
Last updated: 2026-03-11T23:27:03.000Z
It's 1999\. After deciding, in 1997, that I did not, in fact, want to be a clinical psychologist, I needed to figure out a new direction for my professional life. 

I spent 2 years learning network and systems administration, and worked in a couple of jobs in that area of computing from '97 to '99\. Then I discovered programming. It was love at first site. (This was the late '90s, after all, so Internet programming was all the rage. Thus, the pun.)

I interviewed with fresh ground software, in downtown Los Angeles. The 2 co-founders looked at me—I, in my wanna-be-psychologist double-breasted suit, they in their shorts and t-shirts and flip flops (I was totally jealous!)—and said, "You seem smart and hard-working. Your education is useless to us, but here, read these programming books, change your clothes, and then you're hired."

"Oh, and, everyone here has nicknames, so from now on, your name is Sigmund." 

---

This is the short version. The longer version is [here](https://www.sigmundsays.software/sigmunds-origin-story/).
### Not AI
URL: https://www.sigmundsays.software/not-ai/
Last updated: 2026-03-10T20:12:59.000Z
I'm drowning in AI all day, every day (including weekends). I'm trying to convert my company to an AI-native operation as quickly as humanly possible (#irony). 

But not here. On this blog, I make this solemn promise to you, my cherished reader:

> 100% of the content here is written by me, Sigmund. I mean 100%--every word, phrase, paragraph, pun, joke, punctuation mark. All of it. 

AI is the most exciting thing I've encountered in my career, and I've seen a lot. But this space will remain 100% Quinn-telligence, for better or worse. (What more proof do you need that I wrote that? Not even the worst AI hallucination would result in a joke that bad!) 

I think for a long time, then I write. I still use a dictionary every day. No AI proofing, revising, refining, etc. Only what...Sigmund Says.
## Posts
### We've Worked With...Everyone
URL: https://www.sigmundsays.software/weve-worked-with-everyone/
Last updated: 2026-09-15T20:47:09.000Z
We've Worked With...Everyone.

One of our superpowers as a small, boutique technology firm is our experience. It's not just that the braintrust I've surrounded myself with has upwards of a century of combined experience in software, and the business of software. But I've always made sure we're putting that experience to work. Hard. 

In fact, I was somewhat surprised by it, when I finally stepped back and reflected on just how much work we'd done. I mean, I had lived it, so I was aware of it over the years. But when I started actually counting our customers and completed projects, well, I hope you'll agree–it's a lot!

As [I've written about before](https://www.sigmundsays.software/webappers-origin-story/), we started our first projects in 2001, even before we'd incorporated. Since then, we've delivered software products and services (and often the systems to run them as well) to over 1,000 different organizations. See what I mean? Who does that in a small firm? And keep in mind, we've never had more than a dozen or so full-time staff. (We're currently at 11, as of this writing.)

Some context: Starting in 2004, we began selling our [SeeFusion product](https://www.seefusion.com/?ref=sigmundsays.software), and that was selling like hotcakes. About 800 companies trusted our software on their live (production) systems. And customers could purchase the software online, and self-install, so that meant we gained customers even while we were sleeping. 

But as I've described before, I wanted us to be builders, always creating or fixing software and systems, which means...consulting engagements. We've solved problems for just under 300 different organizations.

But the point of this story isn't so much the quantity, it's the quality, which is the part I'm really proud of (beyond being proud of our team for the obviously herculean effort of doing all that work, consistently, for a quarter century). I'm not kidding when I say we've worked with...seemingly...almost...*everyone*. 

Mom and pop shops, multinational corporations, universities, the US federal government, city and sate governments, banks (big and small), healthcare companies (mostly big; which is interesting), SaaS companies, non-profits, numerous auto industry firms and brands, sports, niche e-commerce–the list goes on. 

Like I've said before, I know you're not supposed to fall in love with your results too much, or you'll get complacent. But dammit, I'm gonna say it–I'm really proud of all that good work. In fact, I'm showing that pride by making it into something of a game. Ever play that game Six Degrees of Kevin Bacon? The one that demonstrates how seemingly everyone in Hollywood history is within 6 degrees of having worked with Kevin? Well, head over to [Six Degrees of Sigmund](https://sixdegrees.sigmundsays.software/?ref=sigmundsays.software), and search by your industry, or just search the whole list, and see if perhaps we've worked with *you* before.

Sigmund, signing off. Thanks for listening.
### Six Feet of Cheese
URL: https://www.sigmundsays.software/six-feet-of-cheese/
Last updated: 2026-08-25T19:28:37.000Z
Six Feet of Cheese

We've had some big wins. Out of the more than 1,000 companies we've served, many of my favorites have been very small firms, sometimes even sole proprietors. And I'm keenly aware that the wins we got for the small fries were probably proportionately more valuable to them than the wins we got our big customers. (Affordable custom software development, better uptime for their small-but-mighty systems, etc.)

Many of the big wins for big companies have been exhilarating, too. But the most memorable projects were the ones that started small and got big. For example, the credit union that got acquired by a mega bank (in part because of the revenue-generating software we built for them). 

And sometimes, big wins came in the form of keeping systems online (which almost always means more revenue—downtime is expensive!). One time, we were onsite with a major retailer, whose critical systems were slow and crashing all the time. Very high stakes engagement—they established a "war room" (conference room), there were messages and alerts flying in all directions 24/7\. The CEO himself was intimately involved in the project. Etc. One morning, our co-founder gets an explosion of text messages at like 6am. "The system is down, and peak business hours are starting! 911! 911!" So Mike logs into a monitoring dashboard we'd created, and replies to the CEO—"What are you seeing? Who reported the system down?" 

Turns out, the system was fine. Purring like a kitten, really. Before we got there, their monitoring dashboards looked (and sounded!) like an EKG machine attached to someone having a heart attack. Chaos—nothing but systems that were stressed or down entirely. We'd tuned the systems so well (and fixed their broken monitoring setup; a common problem in high-traffic systems) that the monitoring dashboard now looked like a healthy, sleeping patient. The CEO had suffered from those heart attack dashboards for so long, he didn't even know what healthy looked like. 

I know you're waiting for the punch line to this post's title, so let's get into it. One of my all-time favorite projects started with a small grocery industry consulting firm out of Chicago. Here's the problem they solved: The grocery industry is brutally unforgiving. Grocery stores have NET margins of like 3% (if they're well-run, that is), and they turn over their inventory *dozens* of times per year. Profits come from optimized shelf space. For *all* of the products in the store. Here's the punch line: If you have 6 feet of cheese on the shelf, you're profitable. If you have 7, you lose money on cheese. If you have 5, you missed out on sales. 

The answer was in the data, but those answers were locked away in the crappy software that grocers used (along with banks, car dealers, and countless others we saw and fixed over the years). So our client extracted that data, made sense of it, and sold it back to the grocers. They started by burning spreadsheets on CDs and *mailing* them to customers! (Just like Netflix, before streaming; this was the 1990s after all.) Then they found us. We turned those spreadsheets into a beautiful SaaS product, had a great 10-year run, and then they got bought by major data analytics firm Inmar. 

We loved that project so much, we actually considered renaming the company Six Feet of Cheese. (Or starting a rock bank.) And Jackie, if you're reading this, you are missed! I hope you're doing well. Let's catch up again soon!

I am Sigmund. Thanks so much for listening.
### Speed 2.0 vs. Speed 1.0 (or, AI vs. Agile)
URL: https://www.sigmundsays.software/speed-2-0-vs-speed-1-0-or-ai-vs-agile/
Last updated: 2026-08-25T17:02:04.000Z
Speed 2.0 vs. Speed 1.0 (or, AI vs. Agile)

For the record, I'm pretty fast. At football camp in college, I had the 3rd fastest time in the 40-yard dash on the entire team. In baseball, I loved stealing bases, or taking extra bases when the defense wasn't expecting it.

So it's no surprise that when it came to shipping software in my career, I wanted us to be fast. In the early days, you did this by being focused (including making sure you had good specs before starting), and using the best tooling and tactics available—code completion tools (which were janky to start, but got better fast (see what I did there?), re-use via well-organized snippets and libraries, etc.

Then fast became a culture. The Agile Manifesto came out in 2002, the year after Mike and I started Webapper. This was the crystallization of a long trend towards speed and efficiency. Agile birthed continuous integration and continuous deployment, and a whole host of other tools and processes that made software delivery speedier, especially compared to the past.

We made ourselves agile. Even as a tiny company, we hired agile experts in those early years, to make sure we were doing it well (notice I didn't say "right," which is a common mistake in agile). We were doing DevOps before it even had a name. Every 2 weeks (sometimes faster), we were shipping software—crafted, tested, delivered, done. We won projects because we were faster. We kept clients for longer because we were faster.

AI is different. It's not even accurate to call it Speed 1.0 (Agile) vs. Speed 2.0 (AI). Early in our own AI transformation, we were delivering at Speed 3.0 (3X faster). 5X-10X is entirely realistic, if you know what you're doing. And this ISN'T due to having a bunch of "10X" engineers on your team (which I'm not, by the way). It's because AI systems actually build software that fast. We're now somewhere in the 3X to 5X range, and we're not slowing down until something breaks (and it will; that's a feature, not a bug; it's part of the process). Then we'll just add some guardrails and even better AI orchestration, but we're not slowing down.

It's exhausting. I feel it. I know you feel it. Pretty much everyone who's deep into AI tech is talking about it. We've got a whole new vocabulary growing up around the problem—"[AI Brain Fry](https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry?ref=sigmundsays.software)," [AI decision fatigue](https://stackoverflow.blog/2026/05/21/coding-agents-are-giving-everyone-decision-fatigue/?ref=sigmundsays.software), etc. This last one is the one I personally experience the most. We are able to generate so much more progress, and faster, and across so many areas of operations in parallel, that the bigger challenge for us now is building enough AI to be able to handle all the information (including code!) that AI generates for us, but while still keeping our humans in the loop. 

And as Andre Agassi once said (as told to him by a coach who changed the trajectory of his career)—"Get yourself tired. There are good things waiting for you on the other side of tired." I'll be honest—I'm a little tired. But the speed is thrilling, and especially given that our quality hasn't suffered. There are good things waiting for us on the other side of "AI tired."

This is Sigmund, and thanks for listening.
### How to (Fail to) Convert From Services to SaaS
URL: https://www.sigmundsays.software/how-to-fail-to-convert-from-services-to-saas/
Last updated: 2026-08-25T16:49:10.000Z
How to (Fail to) Convert From Services to SaaS

Starting in January of 2020, I began to take company strategy more seriously, instead of secondarily. I hired my first boss in my software career as my COO (and effectively a consigliere of sorts), brought on a silent partner as an investor, and together we laid out a 5-year plan. It had a few different parallel strategies in it (which itself is a yellow flag, at least), one of which was a spectacularly fun crypto strategy, which failed (not spectacularly, but fully; I'll share those gory details another time), but the one I want to talk about today was the most ambitious—converting the company from being a service provider to being a SaaS product company. 

I'm not a famous person in software—exactly the opposite, really—but I've been fortunate to rub elbows with some legends. One of my favorites is Joel Spolsky. He was one of the co-founders of my favorite software conference (BoS—[Business of Software](https://businessofsoftware.org/?ref=sigmundsays.software)), which I've attend annually since 2008, so in addition to reading a ton of his work over the years, I've gotten to hear him speak live a few times, which means I've gotten to chat with him a bit at the always-present cocktail hour. One year, I asked him if he had any plans to offering consulting services via his software product company, Fog Creek Software (whose products we used). He answered, without hesitation, "Services don't scale."

Now he tells me! I'm kidding, of course. I'd heard this before, and after delivering services for the first decade or so of my career, I was viscerally aware of how relatively laborious it was to trade time for money. But it's all I knew, so it's all I did.

But something about hearing this from Joel always stuck with me. I was a little slow to make certain decisions, so I sat with this for a while. Not too long—just about 10 years or so—but by the late 2010s, as I was remodeling my company from top to bottom, I was more and more ready to take on the challenge of converting us to a SaaS company. My partners were on board, so after 2 years of crypto shenanigans from 2022 to 2024, we got serious about SaaS. 

Normally, you create a product to solve a problem, and then sell it to others. We sort of did this, but not quite. As I've written about before, in modernizing the company, I'd given the team an assignment to build a product, but more as an exercise in building, rather than because we'd identified a problem that needed solving. However, I did have one strategic eye on the future, so I picked an assignment in an area of the Internet I knew was full of problems—cloud storage. Specifically, I asked the team to build a tool to manage Amazon's S3 offering (Simple Storage Service). 

Even the first version was a great success, especially for a self-funded internal project at a small, bootstrapped company. It was a simple product to start, but the design was top-notch, so we knew we could build a lot of functionality upon that strong foundation. 

Estimates are that there are multiple zettabytes of stuff in S3\. I was convinced that customers would pay money to manage all of that elegantly (for the record, we refuse to build software and systems any other way), so we launched the first version in the AWS Marketplace (the "app store" for Amazon's cloud) in 2024\. We knew the product needed enhancements beyond the basic first version, so we created a roadmap and got down to the real work of making it an enterprise-grade piece of software.

We built all the stuff you'd need—security (e.g., SSO), speed (our "[Fast Buckets](https://www.cloudseedrive.com/features-fast-buckets/?ref=sigmundsays.software)" release can search hundreds of millions or even billions of files in seconds), size (need to upload a 30 TB file? [No problem](https://www.cloudseedrive.com/features-large-files/?ref=sigmundsays.software)...), organization (our [Tag Explorer](https://www.cloudseedrive.com/features-tag-explorer/?ref=sigmundsays.software) is unparalleled, as is our [Advanced Search](https://www.cloudseedrive.com/features-advanced-search-filters/?ref=sigmundsays.software) feature). We've even added [natural language processing and some simple AI features](https://www.cloudseedrive.com/features-nlp/?ref=sigmundsays.software), so you can "talk to your files." As I'm writing this, we just shipped some of the most advanced security available for a SaaS product, and we're next working on allowing you to connect the product to your favorite AI (due to ship in the summer of 2026). 

There's a rule of thumb that you're not supposed to fall in love with your own product, because it can cloud your objectivity (see what I did there?). I think I'm still pretty objective about the product's strengths and weaknesses, but I will say this—[I am proud of CloudSee Drive (finally!)](https://www.sigmundsays.software/im-proud-of-cloudsee-drive-finally/). We try to hold ourselves to the highest possible standards, even for a tiny company, so it took a while for me to get to this point. But it's really excellent sofware. 

But wait...this is supposed to be a story about converting from services to SaaS, so what about, you know, *SALES*! How is this fabulous technical feat selling? 

Timing is everything, as they say, and I'm not going to beat around the bush—this is terrible time to be selling a new SaaS product. We've been reading the markets for over a year now, and the unavoidable truth is that SaaS is dying. The "-ing" is important—approximately 100% of "X is dead" arguments are wrong because they don't acknowledge it's a *process*, not an on/off switch. More specifically, certain kinds of SaaS dying *FAST*—especially products early in a lifecycle, without the moats of an established customer base, long history of customer data, or the other advantages of incumbents. Even these aren't guarantees against a slow death—just look at the stock prices of large, public SaaS companies. It looks like another dot com bubble burst. The software industry is priced lower than the S&P 500 for the first time...ever. As Jason Lemkin summarized, as of 2026, investors would rather own...*ANYTHING ELSE*, other than software companies. 

So our so-called "failure" to convert to a SaaS company is sort of like failing to be born in a better neighborhood. Not much you can do about it, other than fight your way out, and move on. Which is exactly what we've done. And our SaaS building has given us some of the strongest muscles of any project we've worked on over the years. This makes us very much ready for the AI fight that's waiting for all of us. Bring it!

Post script: We're still selling. (Knowing when to quit is part art, part science.) Just re-allocating staff, and re-prioritizing our roadmap. We've been on a parallel strategy for over a year now, and our SaaS product and our AI-native transformation have been mutually beneficial to each other. While SaaS is dying, the strengths developed from a strong product development cadence will be critical in the AI era. We're excited. 

I am Sigmund. Thanks for your time.
### I'm Proud of CloudSee Drive (Finally!)
URL: https://www.sigmundsays.software/im-proud-of-cloudsee-drive-finally/
Last updated: 2026-08-02T20:36:36.000Z
I'm Proud of CloudSee Drive (Finally!)

LinkedIn co-founder Reid Hoffman famously said, "If you're not embarrassed by the first version of your product, you took too long to ship." I'm a perfectionist by nature, so this was always difficult for me to embrace in my software career. Combine perfectionism with impostor syndrome (which I've learned afflicts about 100% of people who work in software), and you have a potentially serious problem—you'll be slow to ship, which is the kiss of death in this field. 

But once I learned from the best engineers I've worked with that you have to ship, I mostly embraced Reid's idea. I actually fused that idea together with a related notion from one of my all-time favorite and most talented fellow developers: "Just because you're not paranoid, that doesn't mean someone is *not* out to get you." Or, paraphrase the great software developer Michael Jordan, "The great ones are always a little paranoid."

In short, stay paranoid, and that will keep quality high. And then ship constantly. 

Bringing this back to our flagship SaaS product, CloudSee Drive, the addressable market for it is orders of magnitude larger than any market we had targeted in the past. And we were dealing with immense complexity. It's an S3 management tool (Amazon's oldest cloud system, for storing...everything). Estimates are that there are multiple *zettabytes* of data in S3\. (I'll wait while you look up how large that is; I had to look it up too.) In other words, lots of problems to solve. *Hard* problems. 

As we built, we then faced the inevitable pushback from potential customers—"It doesn't do X." "I need it to do Y." But we're really good at roadmapping a product, so we prioritized the good feedback, and kept building. A big, year-long push starting in late 2024 resulted in an objectively impressive feature set—enterprise-grade security (always priority 0 for us), a parallel processing engine to handle massive scale (ever try to search for something amongst 500 million files?), really elegant organizing features (best damn tag management interface you've ever seen!), the ability to "talk to your files" (a natural language search feature), yet more enterprise-grade security layered on, and even the ability to connect your favorite AI to our product (because, duh). 

All this from a small-but-mighty team (11 people total delivered all that), inside a bootstrapped company, and all done while still juggling other priorities ([our attempted services-to-SaaS conversion](https://www.sigmundsays.software/how-to-fail-to-convert-from-services-to-saas/)). 

I'm really proud of what we built. And maybe it'll even sell. That's a different topic. I've read countless obituaries of even really great tech that didn't sell, for a variety of reasons. (Most recent obit I read was the [documentary "General Magic,"](https://www.youtube.com/watch?v=JQymn5flcek&ref=sigmundsays.software) about the tech innovations that preceded the smartphone revolution; and "failed" miserably. Check it out if you haven't yet.) Bottom line (pun), building and selling are two separate-but-related things, and they don't always go together. I'm (finally!) proud of what we built. It's excellent software and systems. 

I'm Sigmund. Thanks for listening.
### The Re-Everything of My Software Company
URL: https://www.sigmundsays.software/the-re-everything-of-my-software-company/
Last updated: 2026-08-02T20:29:24.000Z
The Re-Everything of My Software Company

After 15 years and hundreds of successful projects, I nonetheless could tell something wasn’t right. At first, I just thought I was bored. As I said, we’d had a ton of success, solved tons of problems, and even invented some cool things along the way. But as I thought more about it, I realized what was bothering me was more urgent—my instincts were telling me that the tech world was changing, and we had to change with it, or else our survival as a small business would be threatened. Plus, we’d be bored, and who wants to be bored? Not me. 

This was one of those Blockbuster Video moments. We had to accept the fact that was got us to where we were at this point—around 2017 or so—was *not* going to yield the same success over the *next* 15 years. We had to overhaul something that seemed to be working just fine. Back to the Blockbuster Video analogy—we had to stop investing in video stores and physical rentals, and start investing in something new and dramatically different (but better). It felt insane, but it brought back an adrenaline rush I’d be missing for a while, and that by itself told me my instincts were probably worth following. Plus I’d seen what happened to companies like Blockbuster, who failed to adapt—they didn’t make it, even with eye-popping money, and time, to get it right. We were a few bucks shy of Blockbuster’s wealth, so I figured we had to be smart, and hustle. Plus, that adrenaline rush. Game on. 

Over the next 2-3 years, we:

- Re-staffed.
- Re-tooled.
- Re-trained.
- Re-packaged (and re-priced).
- Re-positioned.

Here’s more detail about each big change: 

## **Re-Staffing**

This was by far the biggest, most complicated, and most important change we made. In the first 15 years of Webapper’s operations, I’d gotten almost daily emails from offshoring firms, offering access to hundreds of talented, low-priced engineers. I deleted every single one of those. Up to that point, we’d hired only the senior-most US software and systems engineers we could find, and billed them to customers at accordingly premium prices. It “worked,” but this necessarily limited the kinds of customers we could work, and for how long. That is, only the kind that could afford those big budgets.

Then, in 2017, as I was grappling with this sense that we needed to change, I had a unique opportunity to test out the use of offshore developers. An industry colleague of mine had founded an outsourcing company in Vietnam. He was smart and talented, so I decided to try out his service. I’ll cut right to the chase—it was awful in all the stereotypical ways that a lot of offshoring had come to be known. Communication gaps (missed or misunderstood requirements, etc.), delays or missed deadlines, sometimes due to poor coordination across time zones, or due to the aforementioned communication problems, culture mismatch (lack of connection to the assigned staff, which was a deeper problem than mere language barriers or other communication gaps), etc. Even at the deep discounts we were getting, it just wasn’t worth it. So we canceled that contract after the first year. 

Then serendipity struck. A developer named Steven sent me a cold email from his personal email address. He’d worked at the outsourcing company we’d just fired, but he’d quit because he wasn’t happy. He hadn’t been assigned to us, but said he’d heard good things about us from his co-workers. +1 for treating developers well, which didn’t seem to be part of the culture of that outsourcing firm. He was writing to say he was looking for work, and would be willing to work for us directly if we were interested. I wrote back and said, “Well, we also quit, and also because we weren’t happy! Let’s talk!” 

Steven and I clicked virtually right away. I gave him a programming assignment, and he finished it early, and actually built two versions of what I’d asked for, and told me to pick the one I liked best. This was basically the software equivalent of love at first sight. I immediately hired him full-time. After blowing our minds during his first month of employment, I asked the obvious question—do you know any other talented engineers? He recommended Ann, and we hired her immediately too. And things grew from there. 

So just like that, in the span of a few months, we’d established our own office in Ho Chi Minh City, Vietnam, with our directly-employed team. This last part—directly employed—made all the difference in the world, but I’ll write more later about how we created a culture that resulted in a tightly-integrated, high-performing team that was separated by…a lot. Time, distance, culture, language, etc.

## **Re-Tooling**

Now that we had a growing team in Vietnam, to supplement our existing team in the US (we kept senior technical talent, and management, in the US), we still had to address the fact that we specialized in a lot of aging technology. Aging programming languages, software architectures, infrastructure (hosting environments), etc. I gave the team an assignment: Build a real-world application, but only using the latest and greatest tech—modern programming languages, application structure, infrastructure, etc. I was especially interested in cloud-native system design, as we’d been expanding our capabilities in this area since 2012, so one specific requirement was—no servers allowed! Microservices only. The result was the most impressive product we’d ever built, which I’ll write about separately, because [I’m (finally!) proud of it](https://www.sigmundsays.software/im-proud-of-cloudsee-drive-finally/). 

## **Re-Training**

Since we were demanding a lot of change from our team, we had to provide as much training as was necessary to make sure everyone had the knowledge and support needed to stay cutting-edge, but with a lot of new tools and technology. Each person essentially had an unlimited training budget, limited only by the amount of time one could devote to training (while still delivering for our customers, obviously). We loaded up on the typical industry indicator of training—certifications. But more importantly, the new team was solving new problems for new customers, and quickly. Success!

## **Re-Packaging**

The hybrid staffing model allowed us to change how we packaged our services. With a discounted, blended bill rate, we could provide hundreds of hours of services each month to our customers, but at much more affordable prices than we used to charge. We slashed our prices by about 60%. It worked. We consistently signed up new customers for this new retained services model, and it was a game changer for our customers. We were able to do in-depth work, over long periods of time (years vs. weeks or months in the past), and the results spoke for themselves. We even converted existing customers from the old pricing model to the new one. 

## **Re-Positioning**

All of these changes allowed us to position ourselves as partners, instead of consultants. Instead of parachuting in and solving a bunch of problems quickly (and expansively!), we could come on board for long periods of time, to get bigger and better things done for our customers, at much more affordable prices. We were no longer a good date. We were marriage material now. 

Done! Or so we thought. All this transformation allowed us to “product-ize” our revenue, getting off the revenue roller coaster of one-off SOWs (I’ve executed over 600 of them!), which in turn allowed us to focus on more strategic, long-term planning. The most important strategy we would soon tackle was [converting our company from a service provider to a SaaS product company](https://www.sigmundsays.software/how-to-fail-to-convert-from-services-to-saas/). 

And what’s better than one total and complete company overhaul? Two, of course. And the second within just a few years of the first. Good times! That’s right—just as we’d settled into what I thought would be a comfortable 15 to 20 years of additional successes for this next generation of my company, AI changed…everything. Again. Stay tuned for that story. 

Thanks so much for your time. I am Sigmund.
### Webapper's Origin Story
URL: https://www.sigmundsays.software/webappers-origin-story/
Last updated: 2026-06-18T19:33:00.000Z
Webapper's Origin Story

What better time to start a new business than when the economy is cratering? And what better industry to start one in than the hardest-hit industry in the downturn? That's what was going on at the time of Webapper's birth in 2001, but my co-founder and I just didn't care. We wanted to do the work we loved, but just as importantly, we wanted to do it the WAY we loved to work. In other words, we wanted to control our working conditions, as much as you can in a small business.

As I described in the post about [how I got into software development](https://www.sigmundsays.software/sigmunds-origin-story/), I moved pretty quickly through a variety of software jobs early in my career, all of which were pretty demanding. It was a classic situation where work you love doesn’t feel like work. After the first 2-3 years, I was ready to go out on my own. (I’d been pretty entrepreneurial all along. Remind me to tell you about Renaissance Window Cleaning some day.) 

As is often the case when starting a business, serendipity was at play. A colleague of mine from working at Allaire/Macromedia—a Brit named Mike Brunt—also lived in Southern California at the time. We’d both been laid off around the same time, and he helped me secure a Lead Architect role at Sempra Energy where he’d landed a contract—the perfect “day job” foundation from which to take the leap and break out on our own. 

So Webapper was born. The name reflected the niche we wanted to focus on—web application software and systems. (It also meant “Web App ER,” as in emergency room, although that meaning only came into being later, as we began specializing in emergency troubleshooting services for large, complex Internet systems and software.)

That first year, we got a sizable contract with Ernst & Young, continuing to do the same work we'd been doing for Allaire/Macromedia. That was enough evidence for us—the market still needed these web application engineering services. We developed a full suite of offerings focused on large-scale, Java-based web application systems. It took a few years, but by 2004, Mike and I had put ourselves on a salary, and quit our "real" jobs.

As we grew, I wanted to make sure we were builders, and not just stereotypical consultants, so we also worked to bring in application developments projects. Sigmund did a lot of programming in those early days! By 2006, I was ready to hire a Lead Architect to take over that role from me. I remember feeling surprised, at the time, that we were big enough to need to *hire* a Lead Architect, to run a development practice area within our company. And we had *practice areas*, just like law firms! It was exhilarating. 

Backing up a bit in the timeline of the story, one of the most important developments in the history of Webapper happened in 2004\. The very best software engineer I’d met up to that point in my career (still easily one of the top 3 I’ve *ever* worked with), named Daryl, came to me with a product idea. It was brilliant, but like most early product ideas, it needed some noodling. We originally thought it was a JDBC connection monitor (sorry, can’t avoid using nerd language entirely). As we vibed about it, the idea morphed into a full-blown application server monitoring tool. 

This was a nascent niche in the market at that time. At a tech conference one year, I gave a talk entitled "Application Server Analytics," which was the name I'd given to this new product category, which was a nerdier cousin to Web analytics tools like Webtrends, Urchin, and all the rest. We created a tool called SeeFusion, which allowed you to "See" inside your servers (ColdFusion servers, specifically; thus the hybrid name). This was an important-enough development in our company history that I want to write about it separately, but for now suffice it to say it was a big deal for us. We were selling thousands of copies of this product to the biggest companies in the world. 

Back to 2006 now. Another great developer whom I knew of, but didn’t actually know personally, purchased our SeeFusion tool, and was using it on a project, and needed some support. Back then, I provided almost 100% of the tech support for that tool, which is to say I replied to tech support emails all day and night, helping developers and systems administrators solve their server performance problems. Nat had written a great software book or two that I’d read, and he ran a really great little software shop of his own that I’d also heard of. He sent in a tech support email really late at night and says something like, “Wow, I can’t believe I’m getting tech support from YOU!” I replied almost immediately, but I was sitting there thinking “I can’t believe Nat is using our product, and I’m talking to HIM!” Your basic professional bromance.

Since we were both developer-owners, we had that in common, but as our conversations continued, we quickly realized we *really* thought alike about a lot of things. Within just a few months, it was pretty obvious we wanted to work together. So Webapper bought Nat’s firm, which was really an acqui-hire of Nat, and a merging of his customers with ours. (We later hired his former business partner, too, a very talented, and very tall, developer named Erik, who had a great run with us as a Senior Architect.)

Nat took charge of our sitting development team, and built and staffed an agile software practice that cranked out dozens and dozens of really excellent (and complicated!) systems. 

We had all the pieces of the puzzle, in my view. A team that could build software, and also tune it/fix it/scale it/host it. We had high-demand, targeted consulting offerings that delivered unmatched results quickly (our sales calls for these were often around 30 minutes before closing the deals). Or, we could be hired long-term to build great software and systems. And even though the term SaaS wasn’t widely used yet, we had a software product that helped avoid downtime, which over time would introduce us to over 800 customers, some of which were among the biggest companies on the planet. 

So that’s how it all started. Reflecting on all of this as I write about it, it seems more like 30 or 40 years ago, given how much has happened since then, and how much is happening still, as I write this in 2026\. Heck, by the time I share the rest, we might not even be named Webapper any longer!

Thanks for listening. I am Sigmund.
### Sigmund's Origin Story
URL: https://www.sigmundsays.software/sigmunds-origin-story/
Last updated: 2026-06-11T23:12:39.000Z
Sigmund's Origin Story

So who is this Sigmund character, *really*? I mean, beyond [how I got my nickname](https://www.sigmundsays.software/my-name/), who am I, and how did I get here? The short version is that I'm the fusion of an academically-trained social scientist, and a professionally-trained software and systems architect. The longer version is below. 

I had put a *lot* of work into becoming a psychologist. Ten years, in fact, going all the way back to the age of 12\. When my future peers in the software industry were hacking away at that age with the Basic programming language on Commodore 64 computers, I was reading [*Psycho-Cybernetics*](https://www.amazon.com/Psycho-Cybernetics-Updated-Expanded-Maxwell-Maltz/dp/0399176136?ref=sigmundsays.software), by Dr. Maxwell Maltz. As you can guess from the name of his magnum opus, his work attempted to combine concepts from cybernetics (communication- and control-systems), servomechanisms (feedback-driven force multipliers), and psychology. 

In short, it was a book about software, but I certainly didn't know that at the time.

I'd never been obsessed with anything until I stumbled upon psychology. I'd had the usual desires to become the usual things when I grew up—cop (3 generations in my family), baseball player (I made it as far as Division III in college), etc. But nothing that captivated me. 

After Maltz, I soon came upon Dr. Nathaniel Branden, who would also end up influencing my direction in life, in perhaps unintended ways. Dr. Branden was part psychologist, and part philosopher, and also a bit of an anti-establishment rebel. I consumed all of his work multiple times. I even faked my way into a retreat for practicing clinical psychologists, when I was only a sophomore in college, just so I could meet him. 

During this time period—my mid- to late-teenage years—it was all psychology, all the time. I got a job as a room assistant with a company that provided a kind of group therapy session, just so I could listen to all those cases. I read clinical notes and case studies. As I moved into my undergraduate years at The University of Chicago, I switched from autodidact to formal student of academic psychology. The path was laid out. I’d complete my B.A in Psychology, then proceed to the PhD in Clinical Psychology—the top degree in the field. 

That’s when it all started to unravel. 

During my college years, I’d begun to doubt the “hardness” of the “science” of psychology. I’d already been influenced by the likes of Dr. Branden, who was, as I mentioned above, a pretty anti-establishment guy. Digging deeper, I read authors like Dr. Thomas Szasz (*The Myth of Mental Illness*). Over time, I lost confidence in the field, eventually coming to the conclusion that the “treatments” of professional psychology might actually do more harm than good. With that mindset, there was no way I was putting in 5+ years to become Dr. Quinn. 

I pivoted to a Master’s degree in history and law, which mostly confirmed that I didn’t want to pursue psychology professionally. 

So what next? I wasn’t one of those psych majors who couldn’t handle math. I loved math and science. Even tutored others in those subjects. I figured either computing or finance would be a good fit, although I knew very little about either. I noted that the tech world seemed more free-wheeling. Very much come-as-you-are. And the finance world seemed pretty hierarchical, and starchy. The former matched my personality; the latter made me itch just thinking about it.

In the late 1990s, as the dot com bubble was filling, you could get a job just as quickly as you could learn various technologies. I was starting from square one, and I‘m still not ashamed to say it—I bought the book *Networking for Dummies*, to get started learning the world of computing. Then, *Windows NT Networking for Dummies*. Then, *Operating System Concepts*. Then, an A+ Certification manual, and onward from there. (Though I hadn’t studied computer science in school, I certainly knew how to conduct serious academic study.)

![](https://storage.ghost.io/c/0f/b5/0fb5a9c4-6af6-4ab8-ab43-eb10d2ae1bbc/content/images/2026/03/IMG_0281.jpeg)

This was the edition I had. Time to get seriously nerdy about this computer stuff. 

From 1997 to 1999, I had a couple of jobs as a Systems Administrator / Network Administrator, including one at a children’s hospital in Los Angeles. All of this foundational network and systems experience would prove extremely useful when I discovered software development. Almost the instant that I saw the power you had at your fingertips as a software developer, I was hooked. Once again, I started at square one—*HTML for Dummies*. Then a book about Delphi programming. Then a series of Java books (and servlets, and JSP, and all the rest). 

It was just like my early psychology days again. I consumed everything I could about programming. I got my first job as a junior programmer analyst at a Los Angeles software company named fresh ground software in 1999 ([the guys who gave me my nickname](https://www.sigmundsays.software/my-name/)). The next year, I got recruited by a big public software company, where me and a team of about 40 field engineers traveled the world working on some of the biggest web applications around. The next year, I got a big contract as the lead developer heading up a team of mainframe/Cobol programmers building a web application for Sempra Energy, a huge utility conglomerate in Southern California. 

After a few years of being hardened by working so many talented mentors and co-workers, I was ready. Sigmund, “the software social scientist,” went out on his own, and hasn’t looked back since.

I’m Sigmund, and thanks for listening.
### Hello. I am Sigmund.
URL: https://www.sigmundsays.software/hello-i-am-sigmund/
Last updated: 2026-06-18T18:44:23.000Z
Hello. I am Sigmund.

Hello. I'm Patrick, [aka Sigmund](https://www.sigmundsays.software/my-name/). I've been at this software game for a while now, since 1999 (and working in IT since 1997). I've written a lot, but mostly for my customers. Long, tedious technical docs—specs, reports, etc. I used to blog regularly, back in the early days of Webapper, my software company that I co-founded in 2001\. I also had a few technical publications here and there, but I think most of that stuff is in the dust-bin of Internet history. 

(I've written some non-software stuff too, like my Master's thesis ("Shout at the Devil: A Conversation with Leviathan - An analysis of child welfare work in America"), or a popular version I wrote for a magazine ("[Child Abuse by the State](https://drive.google.com/file/d/1BAqbYiveGgdNBugADSUjsm%5FymvvS6K2k/view?usp=sharing&ref=sigmundsays.software)"), or a [book about cancer](https://youdidwhatbook.cobblestone-publishing.com/?ref=sigmundsays.software) I wrote with my wife. But those are all for a different blog!)

I've been through a lot with my team. Lots of "eras"--the original dot com mania, the Rich Internet Application craze, the smartphone/mobile revolution, the cloud, crypto, and now, of course...AI. I think this last one is bigger than all the previous ones combined, but that's a story for another day. 

We've also been through lots of transformation at Webapper. Not the abstract kind you read about in a report from a consulting firm. The real kind. We've gone from old-fashioned, monolith, server-based applications, to the cloud and cloud-native software and systems. Along the way, we swapped out programming languages, architectures, business plans, business models, team members, etc. Again, not for fun or frills, but out of necessity, to make sure we stayed current, and sharp. 

The past 5-10 years have been especially demanding. Oh, did I mention we're also trying to pivot from services to SaaS? Through this stretch, I got kind of quiet, and really stopped writing publicly at all. That's changing now, as I emerge from this metamorphosis, rub my eyes, and try to figure out what happened. 

I'll share my notes here. 

I am Sigmund, and thanks for listening.